My thoughts on the road map...
Different tools on different platforms write checksum file in different formats. The standard agreed for the ASF repository is:
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.
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.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.
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
- 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
- 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.