Bugzilla – Full Text Bug Listing
| Summary: | jsr14 still present in CBI | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Krzysztof Daniel <krzysztof.daniel> | ||||||||
| Component: | Components | Assignee: | equinox.components-inbox <equinox.components-inbox> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | akurtako, david_williams, john.arthorne, thanh.ha, tjwatson | ||||||||
| Version: | 3.9.0 Kepler | ||||||||||
| Target Milestone: | Kepler M6 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
(In reply to comment #0) > AFAIK jsr14 is abandoned by Eclipse. We should reflect that. For Kepler. Still there for Juno/maintenance. I'm fairly sure these were removed from 'master' of those projects. Not sure if aggregator commits were brought up to date. The only (In reply to comment #1) > For Kepler. Still there for Juno/maintenance. Yes, for Kepler. > I'm fairly sure these were removed from 'master' of those projects. Not sure if > aggregator commits were brought up to date. They are in a master. http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.io/pom.xml I guess it's time to educate commiters about pom.xml. Created attachment 226835 [details]
A patch for the remaining jsr14
Some jsr14 references where indeed removed. This patch tries to address remaining two.
Created attachment 226836 [details]
mylyn/context/zip
Created attachment 226851 [details]
Patch v2
Removes profiles completely.
These are in equinox component, right? (In reply to comment #6) > These are in equinox component, right? Yes. (In reply to comment #2) > They are in a master. > http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org. > eclipse.equinox.io/pom.xml > I guess it's time to educate commiters about pom.xml. I will admit to being uneducated on the pom.xml files ;-) But nobody has been able to explain to me why the pom.xml files for org.eclipse.equinox.io and org.eclipse.equinox.util needed the jsr14 option in the first place (see bug 389751). These projects do not require Java 5 are do not have Java 5 source code in them. Are you certain removing the profiles completely from the pom.xml files will not reintroduce the issues seen in bug 389751? I think I have also experienced a similar issue in bug 373258. Thomas, I'm not really sure why we needed that dependency. I think that execution environment J2SE1.3 is not fully compatible (in terms of compilation) with runtimes provided by VM (especially 1.5+), because the compiler for code 1.4 is not really able to handle 1.5 EE binaries. The fix, in my opinion, was enabling 1.5-compatible compiler that was capable of processing 1.5 EE binaries. jsr14 was used to keep the produced binaries at lowest level (but it could be replaced with 1.5 as well). I was able to succeffully build Eclipse without using the aforementioned profiles and using JDK 7. That means that on of following issues happened either migration of Equinox from jsr14 to 1.5 solved the problem or recent versions of JDT handle incompatibilities better. Thanh, could you double check that we really don't need the -Pno-bree-libs ? (In reply to comment #9) > Thanh, > could you double check that we really don't need the -Pno-bree-libs ? I get the error below. I guess the -Pno-bree-libs profile is still necessary. [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.17.0-SNAPSHOT:compile (default-compile) on project org.eclipse.equinox.util: Compilation failure: Compilation failure: [ERROR] /home/user/Downloads/eclipse2/eclipse.platform.releng.aggregator/rt.equinox.bundles/bundles/org.eclipse.equinox.util/src/org/eclipse/equinox/internal/util/security/PrivilegedRunner.java:[102,0] [ERROR] return (context != null) [ERROR] // [ERROR] ? AccessController.doPrivileged(runner, (AccessControlContext) context) [ERROR] : AccessController.doPrivileged(runner); [ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ERROR] Incompatible conditional operand types T and T [ERROR] /home/user/Downloads/eclipse2/eclipse.platform.releng.aggregator/rt.equinox.bundles/bundles/org.eclipse.equinox.util/src/org/eclipse/equinox/internal/util/impl/tpt/threadpool/ThreadPoolManagerImpl.java:[84,0] [ERROR] Object result = (ServiceFactoryImpl.privileged()) ? AccessController.doPrivileged(this) : new Executor(); [ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ERROR] Incompatible conditional operand types T and Executor [ERROR] 2 problems (2 errors) I'm testing with Krzysztof's original patch attachment 226835 [details] now. I will report the result once my build completes.
(In reply to comment #11) > I'm testing with Krzysztof's original patch attachment 226835 [details] now. > I will report the result once my build completes. This patch works for me. I think this is the best solution at the moment, removing the profiles as originally thought is not an option. (In reply to comment #12) > (In reply to comment #11) > > I'm testing with Krzysztof's original patch attachment 226835 [details] now. > > I will report the result once my build completes. > > This patch works for me. I think this is the best solution at the moment, > removing the profiles as originally thought is not an option. Correct me if I am wrong, but if we use <target>1.5</target> in the pom doesn't that mean the class files generated from the build will only work on Java 5 or greater? If this is the only choice then we have to bump up the BREEs of the effected bundles to Java 5. Perhaps we have to do that to work around this build issue. But if we are building against EE jars that provide a profile that is for the EE we need to build against like http://wiki.eclipse.org/Platform-releng/Platform_Build#Using_BREE_Libs suggests then I don't understand why or how we would get this issue as described in comment 10. (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > I'm testing with Krzysztof's original patch attachment 226835 [details] now. > > > I will report the result once my build completes. > > > > This patch works for me. I think this is the best solution at the moment, > > removing the profiles as originally thought is not an option. > > Correct me if I am wrong, but if we use <target>1.5</target> in the pom > doesn't that mean the class files generated from the build will only work on > Java 5 or greater? If this is the only choice then we have to bump up the > BREEs of the effected bundles to Java 5. Perhaps we have to do that to work > around this build issue. > > But if we are building against EE jars that provide a profile that is for > the EE we need to build against like > http://wiki.eclipse.org/Platform-releng/Platform_Build#Using_BREE_Libs > suggests then I don't understand why or how we would get this issue as > described in comment 10. The CBI Platform build supports 2 profiles: bree-libs, and no-bree-libs The <target>1.5</target> solution affects only when the user passes -Pno-bree-libs to Maven when running a build. This profile is needed when a user is just building locally and does not have access to the BREE-libs on their system. The other profile which is what the platform build is using -Pbree-libs tells Maven to use BREE libs when running the build. So the workaround only affects those who build locally. The platform build running on build.eclipse.org is using the -Pbree-libs profile. (In reply to comment #14) > The CBI Platform build supports 2 profiles: bree-libs, and no-bree-libs > > The <target>1.5</target> solution affects only when the user passes > -Pno-bree-libs to Maven when running a build. This profile is needed when a > user is just building locally and does not have access to the BREE-libs on > their system. > > The other profile which is what the platform build is using -Pbree-libs > tells Maven to use BREE libs when running the build. > > So the workaround only affects those who build locally. The platform build > running on build.eclipse.org is using the -Pbree-libs profile. Thanks Thanh, that clears things up for me. Not sure how I missed that before! I don't really want to change the required EE of these two bundles just to work around an issue with missing EE profiles to compile against. Let me go back to the code and see if there is some simple change to the code we can do to make it not fail to compile in this scenario. I went ahead and made the <target>1.5</target> for the no-bree-libs profiles. But I also made some small modifications to the code that I think will allow it to compile against generified class libraries (e.g. Java 5) without the strange [ERROR] Incompatible conditional operand types T and T: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=b0ce00715f964306ae494c0bf2e570c609fbb4c6 I'm still unclear but the conditional ? doIfTrue : doIfFalse seem to mess with the compiler if generics are involved but the target is not 1.5. It would be good at some point to test this out again with no <profiles> in the pom.xml files for these two projects. |
find . -name pom.xml -exec grep -H jsr14 {} \; ./rt.equinox.bundles/bundles/org.eclipse.equinox.event/pom.xml: <target>jsr14</target> ./rt.equinox.bundles/bundles/org.eclipse.equinox.metatype/pom.xml: <target>jsr14</target> ./rt.equinox.bundles/bundles/org.eclipse.equinox.io/pom.xml: <target>jsr14</target> ./rt.equinox.bundles/bundles/org.eclipse.equinox.util/pom.xml: <target>jsr14</target> ./rt.equinox.framework/bundles/org.eclipse.osgi/pom.xml: <target>jsr14</target> AFAIK jsr14 is abandoned by Eclipse. We should reflect that.