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.

Bug 181025 - plugin catalog to reference OSGi bundles
Summary: plugin catalog to reference OSGi bundles
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Autoupdate (show other bugs)
Version: 6.x
Hardware: All All
: P2 normal (vote)
Assignee: dlipin
URL:
Keywords:
Depends on: 181496
Blocks: 180077 197842
  Show dependency tree
 
Reported: 2010-02-22 02:33 UTC by Milos Kleint
Modified: 2011-09-29 14:51 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Milos Kleint 2010-02-22 02:33:34 UTC
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.
Comment 1 dlipin 2010-02-27 05:11:19 UTC
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.
Comment 2 Milos Kleint 2010-02-27 09:36:25 UTC
sorry, I don't see a point in having a wikipage, I'm going to comment here.

facts:
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.

possible solutions:

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.

Questions?
Comment 3 Jesse Glick 2010-02-27 10:28:36 UTC
(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

Meaning:

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.)
Comment 4 dlipin 2010-03-01 16:02:21 UTC
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.
Comment 5 dlipin 2010-03-03 05:41:50 UTC
Reassigning to apisupport/harness - please take care of 1,2,3,7; I`ll take care of 4,5,6 after that.
Comment 6 Jesse Glick 2010-03-03 14:07:07 UTC
For #3, will back out bug #180077 patch since it is not what we want.
Comment 7 Jesse Glick 2010-03-03 15:15:20 UTC
#7 is less critical (just a sanity check) so filing separately: bug #181496
Comment 8 Jesse Glick 2010-03-03 17:27:59 UTC
Doing #2 only for harness, since we do not create bundles in nb.org anyway. 1, 2, 3: core-main #8306181e8f54
Comment 9 dlipin 2010-03-04 17:42:31 UTC
4,5 and 6 (partially) fixed in core-main#6c9e5a5df410

Still need to rebuild windows launcher (I don`:
ide/launcher/windows
o.n.bootstrap/launcher/windows
Comment 10 dlipin 2010-03-04 17:47:44 UTC
pardon..

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:
ide/launcher/windows
o.n.bootstrap/launcher/windows

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.
Comment 11 Quality Engineering 2010-03-04 22:12:52 UTC
Integrated into 'main-golden', will be available in build *201003050200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/8306181e8f54
User: Jesse Glick <jglick@netbeans.org>
Log: #181025 (parts 1, 2, 3): treat OSGi bundle JARs as equivalent to complete NBMs.
Comment 12 dlipin 2010-03-09 06:41:30 UTC
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.