Bug 315438 - org.eclipse.jst.j2ee.tests can not be unpacked
Summary: org.eclipse.jst.j2ee.tests can not be unpacked
Status: RESOLVED FIXED
Alias: None
Product: WTP Java EE Tools
Classification: WebTools
Component: jst.j2ee (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows 7
: P1 major (vote)
Target Milestone: 3.2 RC4   Edit
Assignee: David Williams CLA
QA Contact: Chuck Bridgham CLA
URL:
Whiteboard: PMC_approved
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-02 13:52 EDT by David Williams CLA
Modified: 2010-06-03 13:42 EDT (History)
2 users (show)

See Also:
david_williams: pmc_approved+
david_williams: pmc_approved? (raghunathan.srinivasan)
david_williams: pmc_approved? (naci.dai)
deboer: pmc_approved+
neil.hauge: pmc_approved+
david_williams: pmc_approved? (kaloyan)
ccc: review+

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 2010-06-02 13:52:05 EDT 
I've recently remembered to pack200 our bundles in our repo. 

After that, I noticed an error occurs trying to unpack
org.eclipse.jst.j2ee.tests

Concretely, if I try to 
unpack200 org.eclipse.jst.j2ee.tests_1.1.400.v201005270700.jar.pack.gz ~/temp/x.jar

I get an error "error inflating input" and the resulting jar is not usable.
Comment 1 David Williams CLA 2010-06-02 13:54:10 EDT 
The eclipse.inf file for this jar already has 
jarprocessor.exclude.children=true

I suggest we try excluding the whole thing from processing with 
jarprocessor.exclude=true
jarprocessor.exclude.children=true

While this will result in a pack.gz file from not being created, that seems better than creating a "bad" one that can't be used.
Comment 2 David Williams CLA 2010-06-02 13:57:51 EDT 
Carl, Chuck ... if you agree, I couldn't mind slipping this in to one of our final builds. It has no immediate consequence (we don't use the "packed" version in our tests) but with our new retention policy, once we release our repository, it will be persistent forever ... so, hate to have this "bad file" in it. 
But, it is also try that p2 will ignore the bad pack.gz file and try again for the jar. Some mirroring/aggregation operations might fail, though, if someone tried to mirror our whole repository.
Comment 3 Carl Anderson CLA 2010-06-02 22:01:24 EDT 
Sounds fine to me.
Comment 4 David Williams CLA 2010-06-02 22:07:13 EDT 
Thanks. putting up for PMC review. 

The serious thing about this is it puts a "bad file" in our repository. 

In theory, the repo can be repaired after the fact (by removing the file) but that's error prone and not a very good practice. 

And, the fix is as safe as any change could be. Could not make things worse.
Comment 5 David Williams CLA 2010-06-02 22:24:39 EDT 
> 
> In theory, the repo can be repaired after the fact (by removing the file) but
> that's error prone and not a very good practice. 

This give the wrong impression ... its more than removing the file from the file system, it is removing the file from the repository (which includes removing its metadata, hence, touches the "central" files in a repo.
Comment 6 David Williams CLA 2010-06-02 22:26:15 EDT 
marking as major, since would prevent mirror reproduction (at least with some aggregators, such as b3 aggregator) even though we do not actively do that now ... I hope we can in future.
Comment 7 David Williams CLA 2010-06-03 13:40:56 EDT 
released