Comments on the module-file format

[Brian Pontarelli]

Savant does it the same way. It uses a separate MD5 file for each piece of an artifact, including the artifact itself and the artifact's meta-data (similar to Maven's POM). The MD5 files are used to verify the integrity of each artifact as it is downloaded and cached. A repository might look like this:

	foo-1.1.jar
	foo-1.1.jar.md5
	foo-1.1.jar.amd
	foo-1.1.jar.amd.md5

The AMD file is the Artifact Meta Data which is used for transitive dependencies and version compatibility.

One thing I'd like to bring up again regarding in-place revisions and SNAPSHOTs is that they are in general a bad idea for large systems and can cause grief when releasing and testing. You might have 10+ different versions of 1.1-SNAPSHOT for example and they are littered about your organization and servers. Often there are no constraints around releasing with SNAPSHOT dependencies either and this makes matters worse. Maven's system for all of this is something I would recommend not using.

Savant uses integration builds to solve this problem which create new versions each time using a timestamp. In general, integration builds are local only and they enforce strict semantics, which SNAPSHOT doesn't.

-bp


On Feb 5, 2010, at 2:55 AM, Patrick Wright wrote:

> I'd like to quickly note three use cases which come up in real-world
> module distribution, in my experience both as a consumer of
> open-source libraries and of Maven repositories--in our team, for
> example, we rely on several dozen open source libraries, with
> dependencies tracked via Maven.
> 
> 1) The module artifact has a checksum by which the repository manager
> (e.g. Maven) can determine if the local copy of the artifact is
> up-to-date. AFAIK, this is to cover the case that an artifact was
> updated in-place. This in turn can happen if the distributor makes a
> small mistake in packaging, for example, but does not want to rev the
> version number, or within teams, using a single "snapshot" version
> which is regularly overwritten. I believe in Maven the checksum is
> always in an external file, most likely for backwards compatibility
> with projects that already had JAR files which could then be uploaded
> as-is to Maven repositories. I don't think this can be used (as-is) to
> authenticate origin, as the hash is normally placed on the repository
> server next to the artifact (so if someone could hack the server and
> overwrite one, they could overwrite the other as well).
> 
> 2) An open source project publishes a key by which the artifact can be
> verified as authentic. Most often I've seen this in projects from
> Apache, where the end user is asked to verify the artifact manually
> after download, and the hash is posted on a web page. AFAIK, the use
> case is to verify that the artifact was not swapped or tampered with
> by some third-party on the hosting servers.
> 
> 3) Signed JARs, which we already know about.
> 
> Given the increasing reliance I see in my own team and among my
> colleagues elsewhere on open source software, it seems that having a
> standard, fairly straightforward and at best automated way to handle
> case #2 would be valuable.
> 
> I don't have any specific proposals, but wanted to offer this as input.
> 
> 
> Regards
> Patrick