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.
- create netbeans platform app suite - create some nbm in it (add class to package and declare as public) - create some osgi bundle on it - add dependency on nbm (on osgi bundle) - clean and build suite - run in felix ... run-osgi: suite-osgi.init: suite-osgi.run: Created dir: C:\Users\tester\Documents\NetBeansProjects\suite2\suite3\build\osgi-cache No config.properties found. Welcome to Felix ================ ERROR: Error starting file:/C:/Users/tester/Documents/NetBeansProjects/suite2/suite3/build/osgi/o3-1.0.jar (org.osgi.framework.BundleException: Unresolved constraint in bundle o3 [3]: module; (&(bundle-symbolic-name=org.netbeans.libs.osgi)(bundle-version>=1.0.1)(!(bundle-version>=100.0.0)))) org.osgi.framework.BundleException: Unresolved constraint in bundle o3 [3]: module; (&(bundle-symbolic-name=org.netbeans.libs.osgi)(bundle-version>=1.0.1)(!(bundle-version>=100.0.0))) at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3295) at org.apache.felix.framework.Felix.startBundle(Felix.java:1653) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1124) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619)
The problem is that while the output of the bundle project looks like it is just a regular OSGi bundle, it isn't; it is a NB module project retrofitted to produce a few OSGi headers. In certain respects the result is actually less idiomatic than the output of <makeosgi> run on a regular module binary. In general, creating a module project with OSGi metadata will not produce good bundles; see bug #181496 for an example of something that will not be fixed but should be at least reported. It is better to use a real OSGi project (such as a Maven project, or something using BND); the intent of NetBeansInOSGi has always been to translate some subset of the NB platform to a set of bundles, in a one-time-only conversion step, that can then be used as a binary input to a native OSGi development environment (which may or may not include the NB IDE). In this case the problem is that the manifest of the compiled bundle has Require-Bundle: org.netbeans.libs.osgi;bundle-version="[1.1,100)", reg ular;bundle-version="[1.0,100)" and the native execution mode in Felix intentionally omits org.netbeans.libs.osgi as this is just a placeholder for OSGi libraries for use by the NB module system. Really it should read something like this: Require-Bundle: regular;bundle-version="[1.0,100)" Import-Package: org.osgi, ..... depending on what org.osgi.** classes it actually uses (e.g. BundleActivator). (To follow OSGi recommendations to avoid Require-Bundle, the best style would really be Import-Package: org.osgi, regular.api.pkg;bundle-version="[1.0,100)" but this is entirely outside the scope of what could be generated by an NBM project. You would need to be using a native OSGi project to manage dependencies in this way.)
core-main #07a1ef742581
Integrated into 'main-golden', will be available in build *201004220200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/07a1ef742581 User: Jesse Glick <jglick@netbeans.org> Log: #184434: do not add bundle dep on org.netbeans.libs.osgi.
BTW jtulach - please review this fix (and the preceding commit to JarWithModuleAttributes) if you have not done so already. It means that project.xml will still list libs.osgi, so code completion etc. works, but the actual runtime dep must be written out in manifest.mf#Import-Package. Simple and solves the use case given here, but not perfect: if you run the BundleActivator wizard, it works; if you want to use other org.osgi.** packages, or do not have an activator, then you have to edit the manifest yourself. I could not find a better solution involving generating the attribute when the libs.osgi dep is found: 1. Adding 'Import-Package: org.osgi.framework' is good enough for BundleActivator, but not if you are using other packages - you would still need to edit the manifest in such a case (despite the module compiling successfully). 2. Adding an Import-Package with every org.osgi.** package could break usage in containers which lack some of them, especially from the Compendium JAR; and is misleading since you are surely not actually using all of them (perhaps even none of them, if you have no activator). 3. Modifying #2 with ;optional:=true (*) would solve part of the problem from #2, but still leaves a long mess in the resulting JAR manifest; and would lead to a runtime NCDFE rather than polite error if you are in fact using some unusual package that the container does not offer. 4. Modiifying #2 to use DynamicImport-Package suffers from the same problems as #3; could result in you loading org.osgi.** packages from something other than the system framework, causing other LinkageError's; and can in Felix lead to deadlocks for complicated reasons. 5. Modifying <verifyclasslinkage> to check for Import-Package would make that task more complicated, and would anyway only produce warnings that the user might never see. (*) To calculate: (for j in libs.osgi/external/*.jar; do zipinfo $j; done) | cut -c54- | fgrep .class | perl -p -i -e 's!/[^/\n]+$!!g; s!/!.!g' | sort | uniq | perl -p -i -e 's!\n!;resolution:=optional, !g'