Community
Participate
Working Groups
More and more bundles run into problems with compile-time dependencies that are not required at run time and thus should not be added via Require-Bundle nor via Import-Package (source annotations, see bug 413583, bug 434243). PDE has two mechanism for adding compile-time dependencies, but both don't support version constraints in their entries in build.properties: - PDE UI has additional.bundles (bug 354724 comment 2) - PDE build has jars.extra.classpath and extra.<library> The best solution for all these problems would be a proper OSGi way for specifying compile-time dependencies. E.g. a new manifest header like Require-Bundle-Build: org.eclipse.jdt.annotation;bundle-version="[1.1.0,2.0.0)" or a special directive like Require-Bundle: org.eclipse.jdt.annotation;bundle-version="[1.1.0,2.0.0)"; resolution:=build ... where "resolution:=build" means "mandatory" at build time but "optional" at run time.
This sounds like a terrible idea. Manifest-first in PDE is already bad. This just makes it worse. Furthermore, Require-Bundle is defined by the OSGi spec which does not understand resolution:=build. And I don't see adding that to the spec. The manifest is input to the runtime and output of the build time. PDE is wrong in also using it as input to the build time.
Moving to PDE since I don't think anything spec related will happen here, at least not specifying it in the bundle manifest. Anything done here would also need to work for tycho base builds. The use of a "build" value on the resolution directive will cause the requirement to be ignored completely at runtime since we only pay attention to resolution of types mandatory, optional or dynamic. All other requirement resolution types would be ignored at runtime, but this also pollutes the runtime artifact with requirements that will be visible in other repository technologies like the OSGi Repository service (and p2) and may cause unwanted behavior.
Bug 434243 comment 5 ff contain an interesting discussion on this very subject. Of course, Equinox should not implement something like "Require-Bundle:...;resolution:=build" unless that gets supported by OSGi. An alternative solution has been suggested in bug 354724 comment 4: Make the "extra.<library>" and "jars.extra.classpath" in build.properties support "platform:/plugin/org.foo.plugin" For the null annotations case, the "platform:/plugin/" protocol would also have to be extended to support version constraints. Looks like that would require changes at least here: org.eclipse.core.internal.boot.PlatformURLConnection org.eclipse.core.internal.boot.PlatformURLHandler org.eclipse.core.internal.runtime.PlatformURLPluginConnection
I've just landed here because I am trying to get establish a Tycho build for my working application (by working I mean a product export from the IDE produces a working application from my set of bundles). There has obviously been a discussion going on about this overall topic for several years, and I may be missing something but I think people may be getting confused by implementation details from a knowledge of the internals if Eclipse/OSGi/Maven etc. The problem I see is this: Bundle A depends upon Bundle B and has import-package or require-bundle for B Bundle B depends upon Bundle C and has import-package or require-bundle for C The problem is that at build time A, B and C all need to be on the (flat) class path, eclipse can sort this out because of class loader delegation, but javac can't. Eclipse knows about C when it compiles A because of an additional.bundles entry. Tycho now knows about C when it compiles A because I am copying entries from additional.bundles to jars.extra.classpath The discussion here seems to be about different ways for me, the developer, to tell all the bits of software about the transitive dependency of A on C but this is all wrong. The dependency of B on C is an internal implementation detail as far as A is concerned. The whole point of inventing import-package is so that B can be replaced with another implementation of the same interface without A needing to know or care. This whole discussion breaks that, it is simply not my problem to worry about B's dependency on A, I don't want to copy manifest entries from one place to another and I don't want to worry about this. Surely at compile time, someone in the build system needs to chain together A, B and C and feed them all to javac? If I have to link A and C I may as well go back to require-bundle. Am I missing something?
At the very least shouldn't PDE and Tycho be able to see the same build.properties entry so I don;t have to copy entries from additional.bundles to jars.extra.classpath?
The thread "[equinox-dev] dependency on org.osgi.annotation?" deals with the same problem: https://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08210.html I don't think comment 4 belongs to this bug.
Currently we are not actively enhancing PDE build anymore. Therefore, I close this bug as WONTFIX. Please reopen, if you plan to provide a fix.
Let me just document, that this issue is not limited to PDE/Build but affects every PDE user trying to find a way for expressing a versioned dependency on annotations with retention CLASS (e.g., org.eclipse.jdt.annotation@2.0.0). As such it is a blocker for some projects against adopting JDT null annotations. It was originally filed against Equinox/Framework and then re-routed to PDE. Would the resolution differ if I change the component to PDE/UI?
.
