This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Reproduced in build 200710030000. To reproduce the bug: - create BPEL Synchronous Sample application; - uninstall SOA plugin; - restart IDE; - open SynchronousSample.bpel from SynchronousSample project in editor; - select Assign activity. BPEL Mapper is shown. The mappings can be edited.
Alexey, could you please add comments into the issue with the reason why it should be filed it against "auc/dev"?
As I could understand from the description the basic plugin manager functionality doesn't work. If user removes module from NB it shouldn't work. Probably some properties in SOA plugin aren't set correctly but again basic functionality of plugin manager seems to work incorrectly.
Okay, in such case let's ask Jirka Rechtacek about this.
Fixed together with issue 117332.
Still reproducible in build 200710100000.
ca, are you sure that you did uninstall BPEL plugin which is provider of BPEL functionality? If you uninstall BPEL, all BPEL support will go away. If you uninstalled all tree plugins in SOA category, all content of soa1 cluster is removed. It's the best proof it's working. If did you assumed that uninstallation of SOA only should force removing BPEL and Composite Application as well, it would be fired as another problem to soa.
alexeyyarmolenko assures that SOA plugin contains Mapper functionality for both BPEL and XSLT. Therefore, if SOA Plugin is removed, the mapper shouldn't work. But it does.
I insist it's works correctly. Try to take a clean Java SE IDE. 1) Install SOA (SOA only, its dependencies doesn't force install BPEL) 2) SOA is added into project types 3) Uninstall SOA => all SOA modules disappeared. Then I try BPEL 1) Install BPEL (its dependencies doesn't force install SOA) 2) BPEL is added into project types 3) Uninstall BPEL => all BPEL modules disappeared. Autoupdate infrastructure cannot do more then it. If you would like to declare more dependencies between these components, you should declare them, e.g. declare BPEL dependency on SOA. Anyway, it should be tracked as another issue.
The problem appears for me as following: -Invoke "Tools->Plugins" menu item -Switch to "Installed" tab -Mark a checkbox next to SOA plugin -Click Uninstall -Go thru uninstall wizard, Select "Restart IDE now" After restart i see following: -Modules, contained in soa plugin(for example org.netbeans.modules.soa.mapper) appears as loaded in IDE console window at startup -SOA plugin is NOT LISTED under "Installed" tab in plugins dialog -All functionality, based on modules from SOA plugin is still working Another thing which surprised me: Once im trying to uninstall SOA plugin, im NOT warned that BPEL plugin modules may also become disabled because they depends on modules in BPEL plugin. Im getting such warning when im trying to remove, for example, XML plugin.
Thanks, Alexey
Explanation: There are two visible modules(AutoUpdate-Show-In-Client="true") in Plugin Manager that we are focused in: - SOA -> org.netbeans.modules.soa.kit - BPEL -> org.netbeans.modules.bpel.kit In addition there exists module org.netbeans.modules.soa.mapper, which isn't visible in Plugin Manager(because AutoUpdate-Show-In-Client="false"). Both visible modules SOA, BPEL depend on org.netbeans.modules.soa.mapper(for this dependency are responsible developers working on SOA and BPEL). Plugin Manager just reflects this dependency and cannot uninstall org.netbeans.modules.soa.mapper if there exist at least one installed module that needs it. So, lets imagine that you have installed both modules SOA, BPEL and then you uninstall exactly one of them (let's say SOA) via Plugin Manager, then org.netbeans.modules.soa.mapper cannot be uninstalled because the second one (BPEL) still needs it. After uninstalling both SOA, BPEL then also org.netbeans.modules.soa.mapper should disappear. I think, that Jirka is right that Plugin Manager behaves correctly exactly according the description above. If not please comment and reopen. If you have problems how to define dependencies, please feel free to ask Jirka for help.
So, the problem is that bpel.kit does not depend directly on soa.kit, while modules inside category, represented by bpel.kit have dependencies on modules from soa.kit category. Fix: Checking in project.xml; /cvs/enterprise/bpel/kit/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3
Fix: Checking in project.xml; /cvs/enterprise/bpel/kit/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3
Verified in build 200711020000.