within the current work on nb platform+osgi interoperability the ant harness support creates nbm files out of osgi bundle jars and has these referenced by the update center catalog. In maven based projects this is not completely possible to replicate as the bundles/modules referenced by the catalog can reside in a maven remote repository and generating such nbm file on the fly is not possible.
The most straightforward solution to the problem is to have the catalog files to reference osgi bundles directly, and have the autoupdate on the client to generate the additional content required locally after download.
This content includes: config/Modules/cnb.xml files and update_tracking/cnb.xml files. So part of the codebase from the ant tasks in the harness would be reused/copied to update center module codebase and the and build scripts and maven goals will be changed to generate a catalog file referencing the bundle jar.
initially assigning to autoupdate as that looks like a first-step candidate to me. defect as it's to be done ASAP.
Sorry, I haven`t caught what you are taking about. Could you please set up a wiki page describing the problem in details and the solution that you are proposing as well as alternative solutions? Thanks.
sorry, I don't see a point in having a wikipage, I'm going to comment here.
1. currently plugin catalog only can reference nbm files.
2. in 6.9 we allow osgi bundles to be part of the platform/IDE
3. bundles don't have nbm files naturally
4. ant harness creates nbm files out of bundles during build.
5. maven projects creates plugin catalog and references modules and bundles in remote maven repositories.
6. maven repository doesn't contain nbm files for bundles.
5+6 are the problem to solve.
1. cripple maven support and stop creating plugin catalog/update center from deployed maven repository artifacts. -> creates additional manual steps for deployment and maintainance of netbeans platform applications
2. create plugin to Nexus (and other maven repository managers) to create the nbm files for bundles on the fly on the server. -> unknown complexity+vendor lockin to make the feature work.
3. have plugin catalog reference bundles naturally, have plugin manager generate the required files after downloading the bundle. -> this is what this issue is about.
(In reply to comment #2)
> ant harness creates nbm files out of bundles during build.
This should be changed so that bundles are simply copied verbatim to the NBM build directory. The update descriptor XML should reference the bundle JAR in the distribution attr, but for simplicity could include a <manifest> that mimics the essential attributes that an NBM would have.
> have plugin manager generate the required files after downloading the bundle
config/Modules/*.xml - generated (always enabled=true, no autoloads/eagers)
modules/*.jar - the bundle
update_tracking/*.xml - generated, as for any NBM
(When either building a module bundle project from sources, or running <makenbm>, the harness should also verify that there are no other associated files besides the generated config/Modules/*.xml. It is not permitted to add a Class-Path extension to a bundle, for example, since OSGi defines a different mechanism for this.)
So, the list of tasks is:
1) Modify nbbuild/antsrc/org/netbeans/nbbuild/MakeUpdateDesc.java so that it can work not only with .nbm but also with OSGi bundles (.jar)
2) Inspect every usage of <makeupdatedesc> in harness/nbbuild and check whether it should be extended to pass not only *.nbm, but also *.jar files in <fileset>.
3) Currently used strategy - when ant harness creates nbm files out of bundles during build - should be changed so that bundles are simply copied verbatim to the NBM build directory. Which files does this change affect?
4) Make autoupdate.services (as well as autoupdate.ui) work with OSGi bundles on the same level of functionality as NBMs.
5) When running updater (autoupdate.services/libsrc) generate config/Modules/*.xml for OSGi bundle, puts its jar directly to modules/*.jar and create update_tracking/*.xml as for any NBM
6) Launchers (Windows/Linux) should scan not only for *.nbm files, but also for *.jar in <cluster>/update/download
7) When either building a module bundle project from sources, or running
<makenbm>, the harness should also verify that there are no other associated
files besides the generated config/Modules/*.xml. It is not permitted to add a
Class-Path extension to a bundle, for example, since OSGi defines a different
mechanism for this.
Have I missed anything? Has anyone have something to add/correct to the proposed solution/details above?
Is this issue about all this tasks or some are already tracked as separate issues?
I guess, 1,2,3,7 is about apisupport/harness, 4,5 - platform/autoupdate, 6 - platform/Launcher&CLI.
Reassigning to apisupport/harness - please take care of 1,2,3,7; I`ll take care of 4,5,6 after that.
For #3, will back out bug #180077 patch since it is not what we want.
#7 is less critical (just a sanity check) so filing separately: bug #181496
Doing #2 only for harness, since we do not create bundles in nb.org anyway. 1, 2, 3: core-main #8306181e8f54
4,5 and 6 (partially) fixed in core-main#6c9e5a5df410
Still need to rebuild windows launcher (I don`:
4,5 and 6 (partially) fixed in core-main#6c9e5a5df410, tests to follow.
Still need to rebuild windows launcher - I don't have cygwin properly configured at the moment to build those:
OSGi bundles can now be installed when they are referenced from the UC catalog.
Manual installation of such bundles (e.g. using Downloads tab in Plugin Manager) - and general working with OSGi jars like with NBMs - is not yet supported as it requires rather big code change.
Integrated into 'main-golden', will be available in build *201003050200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <firstname.lastname@example.org>
Log: #181025 (parts 1, 2, 3): treat OSGi bundle JARs as equivalent to complete NBMs.
Added test (core-main#35ab3b37de8f) for checking OSGi bundles installation when they are referenced from UC catalog. Windows launcher/dll was rebuild by Tonda and integrated as core-main#d787b1557441.
Marking this issue as fixed.
Support for using OSGi bundles the same way as NBMs in AutoUpdate is tracked as separate Issue #181683.