Bug 315438

Summary:	org.eclipse.jst.j2ee.tests can not be unpacked
Product:	[WebTools] WTP Java EE Tools	Reporter:	David Williams <david_williams>
Component:	jst.j2ee	Assignee:	David Williams <david_williams>
Status:	RESOLVED FIXED	QA Contact:	Chuck Bridgham <cbridgha>
Severity:	major
Priority:	P1	CC:	ccc, neil.hauge
Version:	3.1	Flags:	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+
Target Milestone:	3.2 RC4
Hardware:	PC
OS:	Windows 7
Whiteboard:	PMC_approved

Description David Williams

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

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

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

2010-06-02 22:01:24 EDT

Sounds fine to me.

Comment 4 David Williams

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

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

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

2010-06-03 13:40:56 EDT

released