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.
See bug #179436 for discussion.
#1 Bug 179436 contains some confusion. #2 While I sort of want to split the packages too (would simplify integration with Equinox), I do not see it a priority. Lowering to P4. The core.netigso has public packages and those public packages offer org.osgi.** only. Whoever depends on them, compiles against plain OSGi. Nothing from Felix is visible.
Seems to be required for Equinox integration.
core-main #0205e142533f & core-main #2dcc15ea3b0c
OK, now we can minimize the amount of code on dynamic class path. So I will create new wrapper module for felix and put it into modules/* directory. At least it will run in the same environment as equinox. However I don't understand why you have included osgi.cmpn-4.2.jar. It is not needed by netigso at all. Does anyone else needs it? Can you delete it? Separate it into own autoload module?
(In reply to comment #4) > I will create new wrapper module for felix and put it into modules/* directory OK, I was not that ambitious. > I don't understand why you have included osgi.cmpn-4.2.jar. It is not > needed by netigso at all. Does anyone else needs it? It includes org.osgi.util.tracker, which the Felix distribution bundles (and I presume uses). Arbitrary OSGi bundles could rely on any of the packages in that JAR as well.
Felix is in libs.felix now: http://hg.netbeans.org/core-main/rev/99fde60a705a core.netigso "needs" it. I am not sure if that is correct and if that will work when libs.felix is not present. The next question whether we need libs.osgi module? I can be merged into core.netigso. I am little nervous about the amount of JARs in platform/core directory and this would make it lower. Re. ServiceTracker, the only use is in URLHandlersActivator, it would be better to take just that one class (looks like this is what Felix did): src/felix/felix-trunk/framework$ grep -r Tracker * doc/changelog.txt: * [FELIX-971] - Exception thrown in ServiceTracker at shutdown doc/changelog.txt:* [2007-05-22] Modified JAR file to include Service Tracker package. src/main/java/org/apache/felix/framework/URLHandlersActivator.java:import org.osgi.util.tracker.ServiceTracker;
Additional option. Now when Felix is real autoload module, we can turn (most of) the OSGi API to autoload module as well. #1: Put osgi.core-4.2.jar into core.netigso and expose as public. Leave osgi.cmpn-4.2.jar in libs.osgi and place that in modules/org.netbeans.libs.osgi.jar. Make modules/org.netbeans.libs.felix.jar depend on core.netigso and libs.osgi. This way the osgi.cmpn-4.2.jar is removed from the platform/core directory. #2: Turn whole libs.osgi into real autoload. Create some non-OSGi based API in core.netigso (core.netigso will not depend on OSGi binaries at all). Make libs.felix implement the new core.netigso API. This way we need no OSGi stuff in platform/core #3: Slight variation of #2 - don't expose anything from core.netigso, but use reflection to call the OSGi APIs. I guess I shall reopen the bug, as there is still some work that shall be done. #1 could be done by you. #2 or #3 is probably for me. We can take some time to discuss what is the best option. Btw. libs.osgi version shall be changed to match version of the spec - e.g. 4.2, right?
(In reply to comment #7) > Put osgi.core-4.2.jar into core.netigso and expose as public. I would rather not expose official org.osgi.** packages from a strangely named module with other stuff in it. Mylyn-related (bugtracking) modules running normally in NB just need to link against OSGi interfaces and they do not need netigso or Felix in any way. Please keep OSGi libs separate. > Make > libs.felix implement the new core.netigso [S]PI. This way we need no OSGi stuff > in platform/core May work. (BTW does netigso have to be in core at all?) > use reflection to call the OSGi APIs -1. > there is still some work that shall be done Up to you. I don't really have a problem with the current state. Whatever changes you make, I'll have to rewrite bits of nb-in-osgi-179473 to keep up. > libs.osgi version shall be changed to match version of the spec - e.g. > 4.2, right? No, we do not try to make OpenIDE-Module-Specification-Version align with version numbers of wrapped external binaries. There are too many versioning schemes in use for this to be possible consistently, and anyway we need to use x.y versions in trunk and still increment them to reflect packaging changes. Leave it as 1.0 and just make sure the OSGi version is reflected in the JAR names.
(In reply to comment #6) > Re. ServiceTracker, the only use is in URLHandlersActivator, it would be better > to take just that one class Prefer to distribute the OSGi Compendium intact as distributed from osgi.org. (I removed OSGI-OPT/ with the bulky sources, as the OSGi spec explicitly permits. We might also need to remove at least Bundle-Name from MANIFEST.MF since this is not really a "bundle" in the normal sense; apisupport seems to get confused and think the OSGi JARs should be considered modules in their own right, though perhaps this would not happen if they were in modules/ext/*.jar rather than core/*.jar as now.)
>> #2 > May work. > (BTW does netigso have to be in core at all?) There has to be something in core/*.jar to recognize JARs with the Bundle-SymbolicName attribute. However your question gave me an idea of slight modification of #2: I can move NetigsoModule (extends Module) into o.n.bootstrap. Merge NetigsoModuleFactory with o.n.bootstrap.ModuleFactory and create an interface NetigsoCallback. That interface would be implemented by core.netigso (now regular module). So we will have no OSGi in core/*.jar, we will not change the current system, etc. I'll try it tomorrow, unless you stop me.
Integrated into 'main-golden', will be available in build *201001271614* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/0205e142533f User: Jesse Glick <jglick@netbeans.org> Log: #179470: package OSGi specification as a separate module from netigso.
(In reply to comment #10) > I can move NetigsoModule (extends Module) into o.n.bootstrap. Merge > NetigsoModuleFactory with o.n.bootstrap.ModuleFactory and create an interface > NetigsoCallback. That interface would be implemented by core.netigso (now > regular module). Sounds reasonable, especially if the callback can be fairly thin.
core-main#be47ba6ddf4d
Btw. the work has been hosted in netigso-as-module branch.
(In reply to comment #8) > Whatever > changes you make, I'll have to rewrite bits of nb-in-osgi-179473 to keep up. I think done in core-main #bab8a352ccc9 and core-main #6e0460cc9ef2.
Integrated into 'main-golden', will be available in build *201002040200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/be47ba6ddf4d User: Jaroslav Tulach <jtulach@netbeans.org> Log: Merge of work on #179470: OSGi spec & co. exorcised from platform/core into platform/modules