Community
Participate
Working Groups
This was first mentioned in Planning Council meeting in December: http://wiki.eclipse.org/Planning_Council/December_01_2010 The issue is that Java 5 can not always unpack200 jars that have been pack200'd with Java 6. For Helios and earlier, we always required projects to use Java 5 while using pack200 to make sure all install scenarios would work. Thus, with the aggregation process, we have always used Java 5, specifically to catch these errors. But, with Indigo, we are claiming that Java 6 is the minimum JRE to use, so it makes sense to no longer have this requirement. And, if we no longer have the requirement, it makes sense to move to Java 6 to run aggregation process so projects that use Java 6 to do the pack200 will no longer cause an aggregation failure. Of course, some (or many?) projects will still want to use Java 5 to do the pack200 step, just for greatest versatility, but they will be "on their own" to test, or make sure their releng does that ... we will no longer "catch" it in the aggregation process. It is advantageous for the Sim Rel aggregation process to use Java 6, since it is a common "error" for new projects to hit, and there is little reason for it, so will make it easier for those that do not care about running on Java 5 ... which is most projects/components.
I see also, from my notes, to remind everyone that even if a user running 1.5 runs into this issue, they can "substitute" the pack200 executable from a Java 6 VM to do installs, mirror operations, etc, if needed ... that is even a VM less than 1.6 can still use a pack200 (or, an unpack200 executable) from another VM, such as a 1.6 distribution, and specify it on their command line using -Dorg.eclipse.update.jarprocessor.pack200. See http://wiki.eclipse.org/Pack200#Pack200_Executable_location (Should be very rarely needed, but the point it, no one would be "stuck" by some inconsistency).
The fix for the M6 build, with the issue with Gyrex using Java 6 but build using Java 5 was resolved as expected. That is, the final run worked, with the "number of pack.gz files" increasing ... but, little else: Using Java 5, causing some errors related to pack.gz files Type Count size (disk used) Features: 719 18M Plugin jar files: 3272 776M Plugin pack.gz files: 2354 242M After fix to use Java 6, so no pack200 issues Type Count size (disk used) Features: 719 18M Plugin jar files: 3272 778M Plugin pack.gz files: 2411 243M So, Java 6 is here to stay :)
