Community
Participate
Working Groups
This is a follow-up for CBI bug 378234. org.eclipse.equinox.security declares Bundle-RequiredExecutionEnvironment: J2SE-1.4. As far as I understand, this means that any bundle that depends on org.eclipse.equinox.security will only resolve on J2SE-1.4 or newer. There is however a relatively large number of bundles (see full list below), which depend on org.eclipse.equinox.security but declare more restrictive minimal execution environments. This cases Tycho build to fail due to unresolved dependencies of org.eclipse.equinox.security bundle. I believe these bundles should require at least J2SE-1.4 eclipse.platform/update/org.eclipse.update.core eclipse.platform/update/org.eclipse.update.scheduler eclipse.platform/update/org.eclipse.update.ui eclipse.platform.ui/tests/org.eclipse.ui.tests.views.properties.tabbed eclipse.platform.team/bundles/org.eclipse.core.net eclipse.platform.team/bundles/org.eclipse.ui.net rt.equinox.p2/bundles/org.eclipse.equinox.p2.artifact.optimizers rt.equinox.p2/bundles/org.eclipse.equinox.p2.artifact.processors rt.equinox.p2/bundles/org.eclipse.equinox.p2.artifact.repository rt.equinox.p2/bundles/org.eclipse.equinox.p2.console rt.equinox.p2/bundles/org.eclipse.equinox.p2.director rt.equinox.p2/bundles/org.eclipse.equinox.p2.director.app rt.equinox.p2/bundles/org.eclipse.equinox.p2.directorywatcher rt.equinox.p2/bundles/org.eclipse.equinox.p2.engine rt.equinox.p2/bundles/org.eclipse.equinox.p2.extensionlocation rt.equinox.p2/bundles/org.eclipse.equinox.p2.garbagecollector rt.equinox.p2/bundles/org.eclipse.equinox.p2.installer rt.equinox.p2/bundles/org.eclipse.equinox.p2.metadata.repository rt.equinox.p2/bundles/org.eclipse.equinox.p2.operations rt.equinox.p2/bundles/org.eclipse.equinox.p2.publisher rt.equinox.p2/bundles/org.eclipse.equinox.p2.reconciler.dropins rt.equinox.p2/bundles/org.eclipse.equinox.p2.repository rt.equinox.p2/bundles/org.eclipse.equinox.p2.repository.tools rt.equinox.p2/bundles/org.eclipse.equinox.p2.touchpoint.eclipse rt.equinox.p2/bundles/org.eclipse.equinox.p2.touchpoint.natives rt.equinox.p2/bundles/org.eclipse.equinox.p2.ui rt.equinox.p2/bundles/org.eclipse.equinox.p2.ui.admin rt.equinox.p2/bundles/org.eclipse.equinox.p2.updatechecker rt.equinox.p2/bundles/org.eclipse.equinox.p2.updatesite rt.equinox.p2/bundles/org.eclipse.equinox.p2.ui.sdk rt.equinox.p2/bundles/org.eclipse.equinox.p2.ui.sdk.scheduler rt.equinox.p2/bundles/org.eclipse.equinox.p2.ui.importexport rt.equinox.bundles/bundles/org.eclipse.equinox.bidi bundle declares OSGi/Minimum-1.2 execution environment in the bundle manifest but jre.compilation.profile = J2SE-1.3 in build.properties. J2SE-1.3 does not provide OSGi/Minimum-1.2 and Tycho build fails with dependency resolution errors as the result. rt.equinox.p2/bundles/org.eclipse.equinox.p2.ui.importexport uses java generics but declares CDC-1.1/Foundation-1.1 as minimal execution environment. Source level according to declared minimal bundle execution environment is 1.3, and Tycho build fails with compilation errors. Even though it is possible to compensate for these problems in pom.xml files, I think it makes more sense to address the root cause and update bundle manifests to reflect actual minimal runtime execution environment.
This issue was discussed recently in a JDT compiler bug ... at least, I think its the same or similar issue. Such as, see bug 360164 comment 24.
I am not sure I understand your point, to be honest. Are you saying that all these bundles can actually work under their declared BREE? Is there really a way to make p2 work with CDC-1.1/Foundation-1.1, for example?
Bundle-RequiredExecutionEnvironment is not a transitive statement, it it just a statement about the EE requirements for that single bundle. The fact that it depends on another bundle, and there exists a version of that other bundle with a higher EE requirement is not relevant for the purpose of this header. Another version of org.eclipse.equinox.security could exist that supports OSGi-1.0 that could be used in conjunction with those bundles. Bundles need to be considered in isolation at build-time, because the line-up they are built against may not match the line-up they are resolved/executed against at runtime.
So, in other words, you insist that p2 and other bundles listed under "equinox.security" group legitimately declare one of restricted java profile as their minimal BREE? As I mentioned, this is not hard to accommodate via Tycho configuration, although this does add an extra configuration maintenance overhead. What about org.eclipse.equinox.bidi and org.eclipse.equinox.p2.ui.importexport? Do you think there is a discrepancy between bundle manifest and build.properties or should I come up with Tycho specific configuration for these bundles too?
(In reply to comment #4) > What about org.eclipse.equinox.bidi and This one does seem wrong. This is a new bundle in Juno so I am surprised we didn't just start at Java 5 for it. Seems we should just remove the entry from the build.properties at this point. > org.eclipse.equinox.p2.ui.importexport? Do you think there is a discrepancy > between bundle manifest and build.properties or should I come up with Tycho > specific configuration for these bundles too?
There is a number of bundles that have compiler target level incompatible with declared minimal BREE, at least as far as I understand BREE. For example, org.eclipse.osgi.util is compiled for java 1.5 but says it's compatible with OSGi/Minimum-1.2. Is this a bug or did I get BREE/codegen target compatibility wrong?
(In reply to comment #6) > There is a number of bundles that have compiler target level incompatible > with declared minimal BREE, at least as far as I understand BREE. For > example, org.eclipse.osgi.util is compiled for java 1.5 but says it's > compatible with OSGi/Minimum-1.2. Is this a bug or did I get BREE/codegen > target compatibility wrong? org.eclipse.osgi.util is a bad example since we don't actually compile the org.osgi classes from that bundle. We just checked in the .class files that we got directly from the OSGi alliance.
Okay, that was a bad example. What about org.eclipse.equinox.registry, which is compiled for target 1.2 but declares CDC-1.0/Foundation-1.0 as the minimal BREE? Or org.eclipse.osgi, says it's compatible with OSGi/Minimum-1.2 but compiled for jsr14?
(In reply to comment #8) > Okay, that was a bad example. What about org.eclipse.equinox.registry, which > is compiled for target 1.2 but declares CDC-1.0/Foundation-1.0 as the > minimal BREE? The registry lists three BREE in this order: J2SE-1.4, CDC-1.0/Foundation-1.0, J2SE-1.3 And we specify this in the build.properties: jre.compilation.profile = J2SE-1.4 So this project should be built against the J2SE-1.4 profile compiler settings. This is what is contained in the J2SE-1.4.profile file for compiler settings (which is what eclipse uses to set the compiler options for the project when they specify to "Use compliance from the execution environment 'xxx' on the 'Java Build Path': org.eclipse.jdt.core.compiler.compliance=1.4 org.eclipse.jdt.core.compiler.source=1.3 org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.2 org.eclipse.jdt.core.compiler.problem.assertIdentifier=warning org.eclipse.jdt.core.compiler.problem.enumIdentifier=warning As you can see the default is to use a targetPlatform=1.2. So I think that is the long explanation to org.eclipse.equinox.registry. > Or org.eclipse.osgi, says it's compatible with > OSGi/Minimum-1.2 but compiled for jsr14? This is the case where the project is being built using jsr14 option. Something we need to stop doing (probably in Kepler) because it does not play nicely with javac from Java 7 bug 369145. But ecj Java 7 support still understands it fine. jsr14 option allows us to use some Java 5 syntax (e.g. generics) in our code but down compiles it to be able to run on Java 1.4 VMs (only interesting because J2ME is still stuck on the Java 1.4 platform.
(In reply to comment #8) > Okay, that was a bad example. What about org.eclipse.equinox.registry, which > is compiled for target 1.2 but declares CDC-1.0/Foundation-1.0 as the > minimal BREE? Tom and I discussed the equinox.registry case. Although it is theoretically possible to run registry with J2SE 1.3 we think it is highly unlikely anyone will be using it. This was an unusual case, and we can streamline it by setting the EE to Foundation 1.1 + J2SE 1.4, and removing the custom attribute from build.properties.
I have changed org.eclipse.equinox.registry in Kepler stream: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=7d9838801c5c45eba52dd61d5a272c937073488a Igor would it be useful to make the same change in the Juno SR1 stream for CBI?
Closing as WORKSFORME. I sent some background information about this to cbi-dev mailing list [1], but I will leave to Platform development team to decide if anything needs to be changed or not. [1] http://dev.eclipse.org/mhonarc/lists/cbi-dev/msg00591.html
