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

Bug 315392

Summary:	if jarprocessor.exclude.pack=true is set, nested jars are created as pack.gz files
Product:	[Eclipse Project] Equinox	Reporter:	Kim Moir <kim.moir>
Component:	p2	Assignee:	P2 Inbox <equinox.p2-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	aniefer, david_williams, thomas
Version:	3.6
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Kim Moir

2010-06-02 09:14:32 EDT

An eclipse.inf file with 
jarprocessor.exclude.pack=true

was added to the pde.api.tools and jdt.debug.ui bundles yesterday to exclude these bundles from packing.  The packed jars that were created were always corrupt.  See bug 314603 for details.

The problem is that today, these bundles have their nested jars in pack.gz form instead of .jar. Thus the pde.api.tools ant tasks are not available.

-bash-3.00$ unzip -l org.eclipse.pde.api.tools_1.0.201.N20100601-2000.jar  | grep jar
Archive:  org.eclipse.pde.api.tools_1.0.201.N20100601-2000.jar
    28639  06-01-10 20:35   lib/apitooling-ant.jar.pack.gz

-bash-3.00$ unzip -l org.eclipse.jdt.debug.ui_3.5.0.N20100601-2000.jar  | grep jar
Archive:  org.eclipse.jdt.debug.ui_3.5.0.N20100601-2000.jar
      587  05-20-04 10:33   icons/full/obj16/jar_obj.gif
     1268  06-01-10 20:34   snippetsupport.jar.pack.gz

Comment 1 Andrew Niefer

2010-06-02 11:04:35 EDT

bug 314603 really wanted "jarprocessor.exclude.children.pack".

However, "exclude.pack" should imply "exclude.children.pack" because otherwise the children never get unpacked later because the container isn't packed.

Comment 2 Thomas Hallgren

2010-06-02 11:26:32 EDT

(In reply to comment #1)

> However, "exclude.pack" should imply "exclude.children.pack" because otherwise
> the children never get unpacked later because the container isn't packed.

An alternative is to pack the parent with effort 0 for this special case. Effort 0 is a simple passthrough so it can be used as a mechanism to trigger and recognize the children (this is what the Buckminster recursive jarpacker does).

Comment 3 David Williams

2010-06-02 11:27:22 EDT

(In reply to comment #1)
> bug 314603 really wanted "jarprocessor.exclude.children.pack".
> 
> However, "exclude.pack" should imply "exclude.children.pack" because otherwise
> the children never get unpacked later because the container isn't packed.

I thought "they" picked "exclude.pack" because it was mentioned some of the class files complained about being invalid were not in the nested jar, but in the outer one. Are you saying that doesn't matter? 

I guess in the mean time (until jarprocessor fixed) someone could work around the problem by specifying both options? (that is, then desired to exclude the whole bundle from being packed, both options _should_ be specified).

Comment 4 Andrew Niefer

2010-06-02 11:44:23 EDT

When I tried it in bug 314603 comment #25, excluding the child from packing was enough to make the class files ok in the outer jar.

Since we don't really have an explanation for when pack200 screws up like this, it could be a good idea to actually add both "exclude" and "exclude.children"

Comment 5 David Williams

2010-06-02 14:01:26 EDT

Sorry to piggy back, but in looking at this, I just noticed that 
http://wiki.eclipse.org/JarProcessor_Options

has 

jarprocesor.exclude

listed as an option. I assume that is a typo, and it should be 

jarprocessor.exclude  (two s's, like the others)?

Comment 6 Andrew Niefer

2010-06-02 14:45:49 EDT

(In reply to comment #5)
> Sorry to piggy back, but in looking at this, I just noticed that 
> http://wiki.eclipse.org/JarProcessor_Options
> 
> has 
> 
> jarprocesor.exclude
> 
> listed as an option. I assume that is a typo, and it should be 
> 
> jarprocessor.exclude  (two s's, like the others)?

Yes it is a typo, the code has
public static final String MARK_EXCLUDE = "jarprocessor.exclude"; //$NON-NLS-1$

Comment 7 Kim Moir

2010-06-03 13:32:55 EDT

I think this bug can be closed. The problem was that I didn't include 
jarprocessor.exclude.children.pack=true.  It's not intuitive to me that I should have to do this but now I know :-)