Bugzilla – Full Text Bug Listing
| Summary: | update Mylyn WikiText required execution environment (BREE) to Java 7 | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | David Green <greensopinion> |
| Component: | Mylyn | Assignee: | David Green <greensopinion> |
| Status: | RESOLVED FIXED | QA Contact: | David Green <greensopinion> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | sam.davis, steffen.pingel |
| Version: | unspecified | ||
| Target Milestone: | 2.4 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 423848 | ||
| Bug Blocks: | |||
|
Description
David Green
David, the change in Wikitext has also broken the Mylyn release build: https://hudson.eclipse.org/hudson/job/mylyn-3.15.x-release/9/console. This shows that adopting Java 7 in Wikitext will in fact force all of Mylyn to switch to Java 7, or at least require reconfiguring some builds. I think it would have been better to wait until there was a consensus to make this change. At this point, since I expect we will switch to Java 7 in the next release cycle, I think it's better not to revert the change. Instead, I'll try to fix the builds that fail as I notice them. Note that this shouldn't affect the upcoming release since the build will be done from a branch. I think it's too late to do this for the 2.4 release. Sam, apologies for the disruption. I thought that it would be easy to back out the change if needed - and forgot about the release build. For the release build, isn't it just a matter of changing the build job to use Java 7 instead of Java 6? I'm wondering if we could avoid backing out the change even if the work up updating the BREE to Java 7 for the rest of Mylyn is deferred to the next release. I don't think we need to revert the change because I was already planning to create a branch from before the change and do the build from the branch. I'd rather not change the build configuration at this point just in case it causes any unexpected issues. This docs build has 188 test failures since wikitext was changed to Java 7: http://ci.mylyn.org/job/mylyn-docs-snapshot/. They all seem to be NoClassDefFoundErrors and VerifyErrors. But the build says that it's already using Java 7 (java-7-openjdk-i386). I also don't see a way to configure that in the job configuration (maybe we'd have to upgrade Hudson?). Amazing, I've never seen this before: http://ci.mylyn.org/job/mylyn-docs-snapshot/871/testReport/junit/org.eclipse.mylyn.internal.wikitext.core.parser.html/HtmlParserTest/testParseInvalidHtml/ Any ideas? I suspect that there's a problem with the Java compiler on the mylyn.org site. Perhaps using a newer version of Java 7 would fix the problem. This build doesn't have the same problem: https://hudson.eclipse.org/hudson/job/mylyn-docs-nightly/ Any reason we're still running that build job (on mylyn.org)? This one looks the same to me: https://hudson.eclipse.org/hudson/job/mylyn-docs-nightly/ Perhaps we should just delete the mylyn.org job. I'd be ok with deleting the mylyn.org docs job but I bet we'll have the same problem with other mylyn.org jobs once we move to Java 7. So we should probably try updating to a newer Java 7 first. @steffen do you recall why we have two builds per comment #9? Any objections to deleting the build on mylyn.org? (In reply to comment #11) > @steffen do you recall why we have two builds per comment #9? Any objections to > deleting the build on mylyn.org? The mylyn.org builds are more reliably and track a longer change history which makes it easier to identify which commit introduced test failures. I don't care if you want to the job but that doesn't sound like a proper solution to me. The Java version looks pretty recent: Java version: 1.7.0_65, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-openjdk-i386/jre My guess is that test failures are caused by this test failing first so I'd start by looking at the test discovery mechanism: http://ci.mylyn.org/view/Snapshots/job/mylyn-docs-snapshot/lastCompletedBuild/testReport/org.eclipse.mylyn.wikitext.core/MarkupFilesTest/initializationError/ I was wrong. The failure seems to be indeed related to the particular JVM on the server and is possible the same that is described here: http://stackoverflow.com/questions/24061672/verifyerror-uninitialized-object-exists-on-backward-branch-jvm-spec-4-10-2-4 . I attempted to update the JDK to 1.7.0_75 and using a newer version of Tycho (and hence a different compiler) but that didn't fix the problem. Installing JDK 1.8, adding it to Hudson and changing the docs snapshot job to use that JDK seems to have worked though: http://ci.mylyn.org/view/Snapshots/job/mylyn-docs-snapshot/877/. Thanks Steffen! Maybe we should make 1.8 the default once we switch all of Mylyn to Java 7. I've updated https://hudson.eclipse.org/hudson/job/mylyn-integration-connectors/ and https://hudson.eclipse.org/hudson/job/mylyn-integration/ to use Java 7 after they failed. I couldn't find a way to configure the Java version of the latter in the build settings so I added a parameter called JAVA_HOME with a default value of /opt/public/common/jdk1.7.0-latest/jre and that seems to have worked. Thanks for supporting this effort Sam & Steffen. Marking as resolved/fixed since we appear to be done here. |