Bugzilla – Full Text Bug Listing
| Summary: | JDT UI Gerrit failing with "invalid location for system libraries" error | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Noopur Gupta <noopur_gupta> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P1 | CC: | christian.dietrich.opensource, daniel_megert, jan.sievers, jarthana, lshanmug, sravankumarl, stephan.herrmann, webmaster |
| Version: | 4.8 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://git.eclipse.org/r/114399 https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=60b79ba21629ebab8263763cc092fc31accb169f https://git.eclipse.org/r/115375 https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=0e02af11d2a82365412f0133f353ba0ea70aac13 https://bugs.eclipse.org/bugs/show_bug.cgi?id=528752 https://bugs.eclipse.org/bugs/show_bug.cgi?id=483300 |
||
| Whiteboard: | |||
| Bug Depends on: | 514471 | ||
| Bug Blocks: | |||
|
Description
Noopur Gupta
I20171218-2000 - Build failed due to the same issue. Probably this is what is being discussed in bug 528366, comment #3. Most likely caused by "fix" for bug 514471. SWT gerrit builds are also failing with the same error. (https://hudson.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/5824/console) did you try to adapt toolchains.xml as per https://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg29248.html (In reply to Jan Sievers from comment #5) > did you try to adapt toolchains.xml as per > https://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg29248.html We requested it but also worried about its impact on 4.7.3 builds starting in two days (4.7.3 uses Tycho version 0.26.0). I hope it won't affect 4.7.3. (In reply to Sravan Kumar Lakkimsetti from comment #6) > (In reply to Jan Sievers from comment #5) > > did you try to adapt toolchains.xml as per > > https://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg29248.html > > We requested it but also worried about its impact on 4.7.3 builds starting > in two days (4.7.3 uses Tycho version 0.26.0). > > I hope it won't affect 4.7.3. Tycho 0.26.0 is released and unaffected by the changes in current development 1.1.0-SNAPSHOT IMHO you should not use a Tycho development version (-SNAPSHOT) for release or patch builds for build reproducibility reasons. If you choose to use a development version of Tycho, you are on the "bleeding edge" and this may break your build from time to time. But I see that if you are using one and the same toolchains.xml on the same machine for builds with both Tycho 1.1.0-SNAPSHOT and Tycho 0.26.0, this incompatible change for the JDK home location is a problem. I think the best would be to have separate toolchains.xml for release and development builds. If this is not doable short term for you, we can revert the change [1] but when I'm back beginning of January we will put the change back in because it's blocking the adoption of Java 9 for Tycho builds. [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=392401801dcbcaa4494c67a4e7bae675f4989bbb revert commit https://git.eclipse.org/r/#/c/114399/ Gerrit change https://git.eclipse.org/r/114399 was merged to [master]. Commit: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=60b79ba21629ebab8263763cc092fc31accb169f (In reply to Eclipse Genie from comment #9) > Gerrit change https://git.eclipse.org/r/114399 was merged to [master]. > Commit: > http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=60b79ba21629ebab8263763cc092fc31accb169f > Thanks Jan! http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=60b79ba21629ebab8263763cc092fc31accb169f you may have to force SNAPSHOT updates (mvn CLI option -U) or wipe the local maven repo to see the latest Tycho SNAPSHOT (In reply to Jan Sievers from comment #7) > (In reply to Sravan Kumar Lakkimsetti from comment #6) > > (In reply to Jan Sievers from comment #5) > > > did you try to adapt toolchains.xml as per > > > https://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg29248.html > > > > We requested it but also worried about its impact on 4.7.3 builds starting > > in two days (4.7.3 uses Tycho version 0.26.0). > > > > I hope it won't affect 4.7.3. > > > Tycho 0.26.0 is released and unaffected by the changes in current > development 1.1.0-SNAPSHOT > IMHO you should not use a Tycho development version (-SNAPSHOT) for release > or patch builds for build reproducibility reasons. If you choose to use a > development version of Tycho, you are on the "bleeding edge" and this may > break your build from time to time. > > But I see that if you are using one and the same toolchains.xml on the same > machine for builds with both Tycho 1.1.0-SNAPSHOT and Tycho 0.26.0, this > incompatible change for the JDK home location is a problem. > > I think the best would be to have separate toolchains.xml for release and > development builds. If this is not doable short term for you, we can revert > the change [1] but when I'm back beginning of January we will put the change > back in because it's blocking the adoption of Java 9 for Tycho builds. > > [1] > http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/ > ?id=392401801dcbcaa4494c67a4e7bae675f4989bbb We are using 1.1.0-SNAPSHOT only in 4.8 releases. On 4.7.2 and 4.7.3 we are using 0.26.0. But both use same toolchains.xml file on the same machine. Thank you for reverting the change. I did not want to have this before year end holidays. Once you are back in January you can put this back and we can work with infra team to get this fixed for tycho 0.26.0 as well We are facing the same problem again [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:1.1.0-SNAPSHOT:compile (default-compile) on project org.eclipse.jdt.junit.runtime: Fatal error compiling: java.lang.reflect.InvocationTargetException: invalid location for system libraries: /opt/public/common/j2sdk1.4.2_19/jre -> [Help 1] full log: https://ci.eclipse.org/jdt/job/eclipse.jdt.ui-Gerrit/252/console Here the problem came with full jdk (In reply to Sravan Kumar Lakkimsetti from comment #13) > We are facing the same problem again > > [ERROR] Failed to execute goal > org.eclipse.tycho:tycho-compiler-plugin:1.1.0-SNAPSHOT:compile > (default-compile) on project org.eclipse.jdt.junit.runtime: Fatal error > compiling: java.lang.reflect.InvocationTargetException: invalid location for > system libraries: /opt/public/common/j2sdk1.4.2_19/jre -> [Help 1] > > full log: > https://ci.eclipse.org/jdt/job/eclipse.jdt.ui-Gerrit/252/console > > Here the problem came with full jdk if you use JREs in toolchains.xml as in your example /opt/public/common/j2sdk1.4.2_19/jre the change should be compatible [1] i.e. no need to change toolchains.xml as this in turn could break other builds on the same machine using older Tycho versions. If you use a "jre" folder, you should only get a warning now (see bug 514471 comment 47) and parent folder /opt/public/common/j2sdk1.4.2_19 should automatically be used instead (provided that /opt/public/common/j2sdk1.4.2_19 is a valid JDK home i.e. it has a "release" file with a key "JAVA_VERSION". This is the same check that JDT does to validate if it's a valid JAVA_HOME). you may want to check both toolchains.xml as well as /opt/public/common/j2sdk1.4.2_19 (In reply to Jan Sievers from comment #14) > (In reply to Sravan Kumar Lakkimsetti from comment #13) > > We are facing the same problem again > > > > [ERROR] Failed to execute goal > > org.eclipse.tycho:tycho-compiler-plugin:1.1.0-SNAPSHOT:compile > > (default-compile) on project org.eclipse.jdt.junit.runtime: Fatal error > > compiling: java.lang.reflect.InvocationTargetException: invalid location for > > system libraries: /opt/public/common/j2sdk1.4.2_19/jre -> [Help 1] > > > > full log: > > https://ci.eclipse.org/jdt/job/eclipse.jdt.ui-Gerrit/252/console > > > > Here the problem came with full jdk > > if you use JREs in toolchains.xml as in your example > > /opt/public/common/j2sdk1.4.2_19/jre > > the change should be compatible [1] i.e. no need to change toolchains.xml as > this in turn could break other builds on the same machine using older Tycho > versions. > > If you use a "jre" folder, you should only get a warning now (see bug 514471 > comment 47) and parent folder /opt/public/common/j2sdk1.4.2_19 should > automatically be used instead (provided that > /opt/public/common/j2sdk1.4.2_19 is a valid JDK home i.e. it has a "release" > file with a key "JAVA_VERSION". This is the same check that JDT does to > validate if it's a valid JAVA_HOME). > > > you may want to check both toolchains.xml as well as > /opt/public/common/j2sdk1.4.2_19 It looks like the "release" file is included from Java 7. I don't see this file available between java 1.4 and 1.6. I searched through our jDK installations available at /opt/public/common/ (In reply to Sravan Kumar Lakkimsetti from comment #15) > (In reply to Jan Sievers from comment #14) > > (In reply to Sravan Kumar Lakkimsetti from comment #13) > > > We are facing the same problem again > > > > > > [ERROR] Failed to execute goal > > > org.eclipse.tycho:tycho-compiler-plugin:1.1.0-SNAPSHOT:compile > > > (default-compile) on project org.eclipse.jdt.junit.runtime: Fatal error > > > compiling: java.lang.reflect.InvocationTargetException: invalid location for > > > system libraries: /opt/public/common/j2sdk1.4.2_19/jre -> [Help 1] > > > > > > full log: > > > https://ci.eclipse.org/jdt/job/eclipse.jdt.ui-Gerrit/252/console > > > > > > Here the problem came with full jdk > > > > if you use JREs in toolchains.xml as in your example > > > > /opt/public/common/j2sdk1.4.2_19/jre > > > > the change should be compatible [1] i.e. no need to change toolchains.xml as > > this in turn could break other builds on the same machine using older Tycho > > versions. > > > > If you use a "jre" folder, you should only get a warning now (see bug 514471 > > comment 47) and parent folder /opt/public/common/j2sdk1.4.2_19 should > > automatically be used instead (provided that > > /opt/public/common/j2sdk1.4.2_19 is a valid JDK home i.e. it has a "release" > > file with a key "JAVA_VERSION". This is the same check that JDT does to > > validate if it's a valid JAVA_HOME). > > > > > > you may want to check both toolchains.xml as well as > > /opt/public/common/j2sdk1.4.2_19 > > It looks like the "release" file is included from Java 7. I don't see this > file available between java 1.4 and 1.6. I searched through our jDK > installations available at /opt/public/common/ I will relax the check on the Tycho side to simply use the parent dir if the folder is named "jre" New Gerrit change created: https://git.eclipse.org/r/115375 We are using Tycho-snapshot versions to utilize Java 9. Please let us if there are any breaking changes in future. Thanks in advance Gerrit change https://git.eclipse.org/r/115375 was merged to [master]. Commit: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=0e02af11d2a82365412f0133f353ba0ea70aac13 (In reply to Sravan Kumar Lakkimsetti from comment #18) > We are using Tycho-snapshot versions to utilize Java 9. Please let us if > there are any breaking changes in future. Thanks in advance this change wasn't meant to be breaking. I hope that my last commit http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=0e02af11d2a82365412f0133f353ba0ea70aac13 fixes the intended backwards compatibility when using a JRE. I also hope that you read my announcement in bug 514471 comment 48 and adapted any "fake" JDKs in toolchains.xml to use an explicit bootclasspath now. Rebuild using mvn -U (force SNAPSHOT updates) to make sure you see the latest SNAPSHOT It still failed with this [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:1.1.0-SNAPSHOT:compile (default-compile) on project org.eclipse.ui.examples.job: Fatal error compiling: java.lang.reflect.InvocationTargetException: invalid location for system libraries: /opt/public/common/jdk1.6.0-latest -> [Help 1] Here is the location of our Java installations http://build.eclipse.org/common/jdk1.6.0_45/ this linked to jdk1.6.0-latest invalid location for system libraries error is coming from jdt core. Bug 487421 introduced setJavaHome functionality by checking "release" file in JDK home. But I noticed this "release" file doesn't exist for JDK 1.4 to 1.6. This is causing failure when we select JDK 1.4 to 1.6 as bree for eclipse projects. I don't have any documentation on when this file got introduced but I know that this doesn't exist(for JDK 1.4 to 1.6) in our installations used for maven builds. JDT team please suggest on how to proceed? (In reply to Sravan Kumar Lakkimsetti from comment #23) > Bug 487421 introduced setJavaHome functionality by checking "release" file > in JDK home. > > But I noticed this "release" file doesn't exist for JDK 1.4 to 1.6. This is > causing failure when we select JDK 1.4 to 1.6 as bree for eclipse projects. > > I don't have any documentation on when this file got introduced but I know > that this doesn't exist(for JDK 1.4 to 1.6) in our installations used for > maven builds. > > JDT team please suggest on how to proceed? Previous Gerrit builds worked until today and that change is from M3. Did you update the compiler yesterday? If not, it's still a regression in Tycho, even if it surfaced a bug in JDT. (In reply to Dani Megert from comment #24) > (In reply to Sravan Kumar Lakkimsetti from comment #23) > > Bug 487421 introduced setJavaHome functionality by checking "release" file > > in JDK home. > > > > But I noticed this "release" file doesn't exist for JDK 1.4 to 1.6. This is > > causing failure when we select JDK 1.4 to 1.6 as bree for eclipse projects. > > > > I don't have any documentation on when this file got introduced but I know > > that this doesn't exist(for JDK 1.4 to 1.6) in our installations used for > > maven builds. > > > > JDT team please suggest on how to proceed? > > Previous Gerrit builds worked until today and that change is from M3. Did > you update the compiler yesterday? If not, it's still a regression in Tycho, > even if it surfaced a bug in JDT. Tycho is using setJavaHome() method from JDT compiler using reflection. This method is a private method in JDT. This method sets the JAVA_HOME after verifying <JDK>/release file. There are 2 issues here. 1. I am not sure of Tyco using setJavaHome method using reflection. I don't think this is correct. Also there is no information on how Thcho team came to know about this method. 2. setJavaHome method expects <JDK>/release file to be present in the JDK installation. but this is not available for JDK 6 and below. I don't know whether this method is used for JDK below Java 7. This was uncovered because Tycho tried to use setJavaHome method. Either way Tycho needs to revert the change. I believe Jan has already done it. We moved to M4 compiler after M4 release. There still a missing link how did Tycho team came to know about a private method internal to JDT core and tried to invoke it using reflection. Till this is clarified I don't think we should put a blame on any component Thanks for making our Gerrit validation work again! (In reply to Sravan Kumar Lakkimsetti from comment #25) > Till this is clarified I don't think we should put a blame on any component Well, using a private method via reflection is enough for me to know who to be blame ;-). According to bug 528752, using reflection is a workaround/PoC while a request for additional API is still being discussed. See also bug 483300 and bug 483239. Just listing those bugs to show that both involved parties are aware of the need to improve. (In reply to Stephan Herrmann from comment #27) > According to bug 528752, using reflection is a workaround/PoC while a > request for additional API is still being discussed. See also bug 483300 and > bug 483239. > > Just listing those bugs to show that both involved parties are aware of the > need to improve. I am aware that reflection is not the way to go, this is why I opened bug 528752 some time ago already, but got no reply. I would appreciate some guidance from JDT on how to properly do in-process compilation with batch compiler Main against a JAVA_HOME different from the one currently running (In reply to Jan Sievers from comment #28) > (In reply to Stephan Herrmann from comment #27) > > According to bug 528752, using reflection is a workaround/PoC while a > > request for additional API is still being discussed. See also bug 483300 and > > bug 483239. > > > > Just listing those bugs to show that both involved parties are aware of the > > need to improve. > > I am aware that reflection is not the way to go, this is why I opened bug > 528752 some time ago already, but got no reply. > I would appreciate some guidance from JDT on how to properly do in-process > compilation with batch compiler Main against a JAVA_HOME different from the > one currently running Understood. I've increased the priority of the bug. |