BrettPorter

My thoughts on the road map...

Repository Policies

Checksum format

Different tools on different platforms write checksum file in different formats. The standard agreed for the ASF repository is:

d1dcb0fbee884bb855bb327b8190af36 *commons-collections-3.1.jar

The name of the checksum file should be the original filename with ".md5" appended, in lowercase.

This is equivalent to the output of GNU md5sum, where "*" indicates a binary file.

It is recommended but optional to also store a SHA1 checksum, following the same guidelines. The extension in this case is ".sha1" in lowercase.

Some files will only include the sum and not the filename. Tools should also be able to parse this.

Permissions

All directories should be group writeable in the repository, however no files should be group writable. This means that files can be removed but not changed without an explicit override.

Releases and SNAPSHOTs

At apache, projects using Maven should set:

maven.repo.apache.releases=scp://www.apache.org
maven.repo.apache.releases.directory=/www/www.apache.org/dist/java-repository

and

maven.repo.list=apache.snapshots
maven.repo.apache.snapshots=scp://cvs.apache.org
maven.repo.apache.snapshots.directory=/www/cvs.apache.org/repository

The release manager uses -Dmaven.repo.list=apache.releases to publish to the other location. This can be enforced by permissions if we really have a problem.

Required new features

These are features required in Maven Wagon to support the repository:

• sign code before pushing it up (using GnuPG)
  • handle this in the downloading also.
  • it can be at the users discretion: skip it, check it from the same location, check it, getting keys from a specified trusted location, only trust if the key is already in my keychain are probably the levels.
  • More details to be added.
• possibly use JAR signing
  • this is built into Java, but not other languages, so is only a bonus feature.
  • can be used inside secure classloaders, and only requires one GET as it is self contained
  • may require sealing, which causes other issues
  • requires a CA: might be beyond average joe, but Apache would have one?
  • more thought needed
• publish to a stage location so it can be vetted by a script for a valid md5, asc and that it isn't a SNAPSHOT, before copying it to the release location
• allow different repository formats, to support a possible difference between ASFRepository, Maven-1 and Maven-2
• license handling:
  • facilitating clickthrough licenses
  • permanent acceptance of a certain type of license
  • show license again if it changes
• possibly collaborate with the Mevenide folks to add integrated IDE support. This is something they may already have, and there is code in depot for eclipse that can be used
• for sourceforge projects: support making releases to the sf release system and pushing that to a repository (partial support in depot)
• Ant wishes that we can build it with no dependencies other than JREs 1.2+ and Xerces/Crimson. This is perhaps not realistic for all providers, but may be for lightweight-http (no publishing)
• An archival policy
  • is a good idea so old artifacts that have been renamed can be removed from the top group directory so people know what the current artifacts are (while still being able to get the old ones from an archive).
  • I think there's merit to having 3 repositories: snapshot, archive and current (current is not just the latest release, but all supported releases). Equivalent to cvs.apache, archive.apache and www.apache now.

Wagon's scope is really only transport though - uploading and downloading through a variety of providers with a common Java API. The repository layout code is no longer in there. It is in a separate component of Maven, so there can be some discussion on our end about whether that really makes it part of the Wagon project, but not the Wagon API. That's really administrative more than anything.

Repository Layout

Current ASFRepository proposed layout: http://wiki.apache.org/asfrepository/Proposals

Maven-2 layout: http://docs.codehaus.org/pages/viewpage.action?pageId=8003

TODO: list differences as a way to bring them together if possible

References

• Phil's scripts in committers/tools/releases:

  • sign_and_hash.sh -- creates checksums and sigs

  • symlinks.sh -- generates symlinks

  • verify_sigs.sh -- verifies checksums and sigs

• Commons Release documentation: http://jakarta.apache.org/commons/releases/release.html

Other Notes

From Henk:

• For cleanup purposes it would be nice if one could link something (X) in the repository, to something (Y) in '/dist/' : we can flag X for removal if Y is gone.