I don't know if there is any particular
reason for not setting an MD5, it could just be an oversite. None
of the places (publisher, repo tools) that do pack.gz set MD5 properties
The only question would be the use of
the MD5 at runtime. Is it checked against the raw artifact before
processing steps are applied?
Note there is a new ant task in M6:
It will update the artifact repository
with new MD5s for the jars and add pack.gz descriptors (but doesn't add
MD5s for the pack.gz files).
It also takes an optional pack="true"
attribute that will call the jarprocessor to pack the jars first, and it
takes a nested <sign> element to sign the jars as well. PDE/Build
uses this if you are building using the publisher.
Henrich Kraemer <henrich.kraemer@xxxxxxxxxx> Sent by: p2-dev-bounces@xxxxxxxxxxx
04/06/2009 05:41 PM
Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>
[p2-dev] generator and download.md5
for packed files
From a directory containing features and plugins, I am
using Jar Processor to pack the plugins.
Then I would like to make a P2 repository out of this. I only need an artifact
repository here. My code invokes org.eclipse.equinox.internal.p2.metadata.generator.EclipseGeneratorApplication
with the following arguments:
The output of artifacts.jar (see excerpt below) looks good except that
I am surprised that the packed files do not have a download.md5 property.
I would really want to have this property to enable integrity check the
associated downloads. Should this be considered a bug? Is there a work-around?
Another aspect - probably benign - but surprising to me was that I had
to specify a -metadataRepository argument for the task to generate <artifact
elements> inside artifacts.jar. Is this expected?