Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 369896 - Experiment with --segment-limit=-1 for pack200
Summary: Experiment with --segment-limit=-1 for pack200
Status: RESOLVED INVALID
Alias: None
Product: Orbit
Classification: Tools
Component: releng (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Project Inbox CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-27 01:05 EST by David Williams CLA
Modified: 2012-01-27 03:41 EST (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2012-01-27 01:05:39 EST 
Given bug 361628, I search VM pack200 bugs for possibly related bugs. Seems one that might be related is 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5078608
titled: Digital signatures are invalid after unpacking

While (I think) some fixes were put in 1.5, some reports sounds like it can still be a problem with later VMs, thought 1.7 isn't mentioned explicitly. 

That bug suggest that using --segment-limit=-1 in the pack200 invocation (for both the conditioning step, and the pack step) will cause the process to behave a bit more predictably. 

It is a little "trial and error" attempt to solve the problem, but I think worth a simple experiment with orbit build to see if our 4 "easy to reproduce" cases are fixed by this simple workaround. And, this bugzilla is just to document the experiment.
Comment 1 David Williams CLA 2012-01-27 03:41:06 EST 
No effect, on unpack behavior, but ... thinking about it, these "test ok" with using the raw gzip and unpack200 tools ... so ... fairly clear there is nothing wrong with the jars/bundles themselves ... just thow they are being read by Java code. It appears Ian has some initial ideas in bug 361628.