Community
Participate
Working Groups
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
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.
(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).
(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).
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"
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)?
(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$
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 :-)
