Bug 125522 - Support programmatic installation of NBMs into platform
Support programmatic installation of NBMs into platform
Status: RESOLVED DUPLICATE of bug 174846
Product: platform
Classification: Unclassified
Component: Autoupdate
6.x
All All
: P2 with 2 votes (vote)
: TBD
Assigned To: dlipin
issues@platform
:
: 17243 141416 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-17 23:24 UTC by tomwheeler
Modified: 2010-01-22 15:50 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
NBM installation build file (6.27 KB, text/xml)
2008-01-17 23:25 UTC, tomwheeler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tomwheeler 2008-01-17 23:24:40 UTC
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.
Comment 1 tomwheeler 2008-01-17 23:25:21 UTC
Created attachment 55223 [details]
NBM installation build file
Comment 2 Jesse Glick 2008-09-23 19:27:57 UTC
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.
Comment 3 _ wadechandler 2008-09-24 15:34:31 UTC
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.
Comment 4 Jesse Glick 2008-09-24 16:23:37 UTC
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.
Comment 5 Jiri Rechtacek 2008-10-17 06:54:06 UTC
*** Issue 141416 has been marked as a duplicate of this issue. ***
Comment 6 Jiri Rechtacek 2008-10-17 08:52:33 UTC
*** Issue 17243 has been marked as a duplicate of this issue. ***
Comment 7 Antonin Nebuzelsky 2008-11-14 15:32:31 UTC
Reassigning to the new "autoupdate/*" owner dlipin.
Comment 8 Jiri Rechtacek 2008-11-25 12:17:10 UTC
Evaluation at possible solution is available at http://wiki.netbeans.org/PlatformAppCLIModulesManager
Comment 9 Jesse Glick 2008-11-25 16:21:32 UTC
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.
Comment 10 puce 2008-12-01 15:48:28 UTC
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.
Comment 11 puce 2008-12-01 15:50:03 UTC
The link is broken:
http://blogs.sun.com/Chreston/entry/building_product_on_top_of
Comment 12 tomwheeler 2008-12-01 17:17:12 UTC
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
Comment 13 rmichalsky 2008-12-02 14:19:02 UTC
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.
Comment 14 Jesse Glick 2010-01-22 15:50:42 UTC
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 ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo