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.
We have several applications that are built on the NetBeans platform. We would like to share a few modules between them, or to build slightly different configurations of each one (like a "lite" version, for example). This is currently very difficult in NetBeans because the suite must know about the modules, each module must know about the suite and it's difficult to manage configurations where the suites/modules are spread throughout different CVS modules, different CVS repositories and even different source control systems. Rudolf Balada described an approach for installing NBM files into a platform or application at build time: http://blogs.sun.com/Chreston/entry/building_product_on_top_of This works, but seems like kind of a hack because it's calling a GUI component inside of Ant to do the updates. It should be possible to do this in a more reliable way; e.g. I should just be able to call something like NbmInstaller.addModule(platformPath, nbmFilePath) at build time. I have simplified his script and removed a lot of the hardcoded values in Rudolf's script. I will attach it momentarily.
Created attachment 55223 [details] NBM installation build file
Unpacking NBMs built in one place into another platform is a poor way to solve the original use case, which would probably be better managed by having a single suite containing all the desired modules - you can use simple property overrides (i.e. "configurations") to build variant products. The Maven support for NBM packaging does really work this way; in that case everything is essentially automated, and e.g. sources for dependencies are found automatically.
Are there any future plans for such things such as modules in multiple suites and projects. Is the Maven support going to be the way of the future for NB and Platform/RCP development? I'm very curious because over at platformx we are trying to start working on some ideas, and if there are things in the works for how to work with modules in multiple projects or maybe some documents underway which make these things easier or more understandable then maybe that is the way we need to go versus worrying about the issue. Currently what we do is build another platform which includes the entire IDE of who ever is building platformx, so they have all the platformx modules and the the IDE in an environment which they may use for development. Thus, this would be the platform the project would depend on versus the IDE or they could use make a couple changes and use it as the platform and IDE all in one with the extra modules from platformx. With chaining and clusters and the different mechanisms I know there are issues with refactoring across those boundaries which I have seen on the dev@openide list from time to time. We are interested in making developing using the platform easier, and we are working on some 3rd party modules for RCP developers which we use ourselves, so anything we can do to help here, or locate anything to push us in the right direction would be helpful to know about. Thanks.
For the case of platformx, the approach of producing a single platform containing the union of a regular IDE with the platformx.nb.org modules makes sense. In such a case, you would just set sources for the platform in NB Platform Mgr to have two entries: one for nb.org sources, one for the platformx suite. Similarly for Javadoc. There should be no issues with Find Usages, refactoring, etc. if you have the source associations set up correctly. There was one report in this area I am aware of which was resolved when the reporter correctly configured his IDE according to the instructions in harness/README. Maven support for NB module development is available already but is still under fairly active development, so it is hard to say yet whether this will be the recommended approach in the long run. There are a lot of details to consider.
*** Issue 141416 has been marked as a duplicate of this issue. ***
*** Issue 17243 has been marked as a duplicate of this issue. ***
Reassigning to the new "autoupdate/*" owner dlipin.
Evaluation at possible solution is available at http://wiki.netbeans.org/PlatformAppCLIModulesManager
It is Richard who needs to comment on this, as he is implementing a different approach that is not NBM-centric, though it would need some simple NBM import facility. Using autoupdate.services just to unpack some ZIP files seems like overkill to me.
I'm a little confused by "programmatic installation" and don't know if I understood the intend of this issue correctly, but I think in a suite project Properties->Sources->Add should support to add NBMs. The "programmatic" part should be done under the hood by an Ant task.
The link is broken: http://blogs.sun.com/Chreston/entry/building_product_on_top_of
puce: The original intent of the issue was to support the addition of modules in NBM format into an existing platform, particularly through the build process. Rudolf Balada's blog (which does appear to be missing the linked page) described how to do this by setting some system properties and running a GUI class in the platform to do the installation. While it worked, it could probably be described as a hack. Since there is no supported way to do this, I filed this RFE to request one. The inability (or at least difficulty) of sharing modules between suites is viewed by many as one of the big drawbacks of the platform. But there is a lot of work planned for API Support in 7.0: http://wiki.netbeans.org/EnhancedConfigurationOfNBRCPProjects
I've discussed this issue with my manager and though support for installing/updating NBMs from Platform Manager has been considered for 7.0, it's been decided that we won't modify autoupdate to do this as current changes in harness (already mentioned http://wiki.netbeans.org/EnhancedConfigurationOfNBRCPProjects) should solve many of original use cases. For the rest we'll try to simplify running autoupdate from updated platform itself (I suppose that's what the blog described). > Using autoupdate.services just to unpack some ZIP files seems like overkill to me. It is IMHO easy updating where autoupdate would be beneficial, not installing new NBMs.
There is an Ant task to install NBMs in the NB 6.9 harness. *** This bug has been marked as a duplicate of bug 174846 ***