Neil Bartlett
Neil Bartlett
See also https://issues.apache.org/jira/browse/FELIX-5527
Unfortunately the version-specific part under `META-INF/versions` can override the non-version-specific classes. It seems that a multi-release JAR would have to result in at least a base bundle plus one fragment...
You can have `module-info.class` under `META-INF/versions`. So you could have entirely different dependencies for Java 9, 10, etc.
Okay nice idea with `Bundle-ClassPath`.
Yes I think that might need to be the way forward... runtime support for fragments nested inside a bundle. That way projects like log4j can just release a single JAR,...
I think the structure would look like this: A.class (pre-Java 9 class) B.class (pre-Java 9 class) META-INF/ \- MANIFEST.MF: Bundle-SymbolicName: foo Bundle-ClassPath: versioned, . Require-Capability: osgi.ee; filter:='(osgi.ee=JavaSE-1.8)' \- versions \-...
> Bundle-Classpath: META-INF/10,META-INF/9,. Yes I think this works, and bnd can generate that. It becomes tricky when the user wants to use `Bundle-ClassPath` for something else as well, but maybe...
STRONG disagree. I assume this is in relation to the discussion on #4460. Deprecation is a precursor to removal so I don't know why you want to take this capability...
I want to ensure that the following capabilities, which we have at present, are preserved: * Automated builds can be forced to break by a change in the resolution result...
+1 this would also allow the plugin to be made available from the Eclipse Marketplace.