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.
Currently it's difficult to have a project depend on an OSGi bundle that has additional JARs on classpath. The build system/project system seems to ignore the Bundle-ClassPath manifest element. It's not easily possibly to use classes from the wrapped JAR, the build fails and also the IDE shows errors for usages of the classes. Workaround is to add the JAR to cp.extra project property. It becomes awkward quickly when it needs to be used often, duplicating the paths in build property files. As an example, take jdeveloper/external/oracle.javatools-nodeps.jar that has the following in its manifest: Bundle-SymbolicName: oracle.javatools-nodeps Bundle-ClassPath: .,external:$ORACLE_HOME$/jdeveloper/modules/oracle.javatools_11.1.1/javatools-nodeps.jar The requirement is that setting up a dependency to "oracle.javatools-nodeps" (e.g. from a module suite project) should simply allow to use classes (build, edit) from the complete bundle's classpath, including the target javatools-nodeps.jar. The 'Bundle-ClassPath' element should be processed and classpath composed from it. That should also include resolving the property in the path ($ORACLE_HOME$).
While supporting Bundle-ClassPath in various places including the build harness would be desirable, the external:$ORACLE_HOME$ syntax is nonstandard and nonportable. Bundle-ClassPath may only be used for JARs embedded in the bundle (i.e. nested ZIP entries). I would suggest fixing this on the JDev side first.
I'd like to define ORACLE_HOME=${jdeveloper.dir} in the suite/nbproject/platform.properties and convince both harness and editor to use such value when processing external:.... references.
This sounds like a bad approach. If there is a plain old JAR somewhere that should be made visible from an OSGi bundle, add OSGi headers to it and include it in the binary cluster path.
The customer may not have permission to modify some of the JARs, I am afraid. Other JARs are reused in different products and possibly owned by teams which have not adopted OSGi yet and as such it is hard to include OSGi manifests in there. Anyway "external:" protocol is Equinox officially supported extension and as NetBeans IDE uses Equinox since 7.1, it make sense to include this support in harness too.
I will not able to handle this for 7.2 version.
(In reply to comment #5) > I will not able to handle this for 7.2 version. ... and is this the reason to DEFECT -> TASK transfer ?
(In reply to comment #6) > (In reply to comment #5) > > I will not able to handle this for 7.2 version. > > ... and is this the reason to DEFECT -> TASK transfer ? Yes. If I fixed it by the release, I would not care about the type of the issue.
> > > I will not able to handle this for 7.2 version. > > > > ... and is this the reason to DEFECT -> TASK transfer ? > > Yes. If I fixed it by the release, I would not care about the type of the > issue. Yes, but P2 DEFECT - means to be fixed in 7.2 .... P2 TASK - means nobody really cares about this bug ...