Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 340267

Summary:	Use Java 6 to run aggregation process.
Product:	Community	Reporter:	David Williams <david_williams>
Component:	Cross-Project	Assignee:	David Williams <david_williams>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	hmalphettes, sbouchet
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description David Williams

2011-03-17 00:02:14 EDT

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.

Comment 1 David Williams

2011-03-17 00:13:22 EDT

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).

Comment 2 David Williams

2011-03-17 03:52:12 EDT

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 :)