p2-dev-bounces@xxxxxxxxxxx wrote on 04/03/2009 01:37:15
> thanks a lot. I have more questions:
> > 1 - JDK 1.5 pack can handle 1.6 (or later) java code, the things
> > that it doesn't understand as essentially passed throug.
> Does that mean that the entire jar remains unpacked or perhaps
> some parts of it?
I believe this is handled per class file, so the jar
will be packed but some particular class files won't get compressed. See
"5. Handling unknown
attributes " in http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
> > ....
> > 4 - yes, different jars could be packed by different pack200
> > versions if they were produced by different builds
> It appears that this cannot be controlled for individual bundles
> but for the entire build using system property
> "org.eclipse.update.jarprocessor.pack200". In Eclipse builds
> the value set?
I don't believe this is set for Eclipse builds, so it just uses the pack200
from the jdk running the build. The conditioning is currently done together with signing
on the foundation servers. This is done with a 1.5 vm, generally this also means the packing done later should
also occur with a 1.5 vm.
> > ...
> > The pack200 parameters that were used to condition/pack a bundle
> > recorded in that bundle's META-INF/eclipse.inf file.
> > ...
> In one example produced using JarProcessorExecutor the eclipse.inf
> file does not contain the pack200.args property:
> #Processed using Jarprocessor
> pack200.conditioned = true
> There is no pack200.args property. Does this mean some defaults are
> used? Are the defaults documented? In practice should every bundle
> specify pack200.default.args in its eclipse.inf file?
This would mean that the jarprocessor tool did not use any arguments. So
the defaults are whatever the pack200 tool uses as defaults.