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.
Summary: | Support for OSGi wrappers using external:$ENVPROP$ | ||
---|---|---|---|
Product: | apisupport | Reporter: | Tomas Pavek <tpavek> |
Component: | Harness | Assignee: | pgebauer <pgebauer> |
Status: | NEW --- | ||
Severity: | normal | CC: | jglick, mmirilovic |
Priority: | P2 | ||
Version: | 7.2 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
Tomas Pavek
2012-01-31 16:26:13 UTC
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 ...
|