www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: Maven repository policies
Date Tue, 26 Jul 2005 14:12:20 GMT
Brett Porter wrote:
> Hi,
> 
> First of all, please do not retain the CC's on any responses to this.
> Folks interested in this topic, could you please subscribe and reply to
> the repository@apache.org list - thanks.
> 
> Ok, what I wanted to talk about here was establishing a new Maven 2
> repository for deployment of Apache redistributable artifacts, and any
> policies that should be enforced on that. The Maven 2 repository layout
> is currently described here:
> http://docs.codehaus.org/pages/viewpage.action?pageId=22230.
> 
> I would like to have something workable for everyone going from the
> outset. Here is what I am proposing - please let me know if you have any
> feedback, additional requirements, objections, etc.
> 
> This repository, which would be in parallel to the existing
> /dist/java-repository would be the place for Apache projects built with
> Maven 2 or Ant (using the Maven 2 deployment tasks) to drop individual
> libraries to. Maven 1 built projects can continue to use the existing
> java-repository - only one or the other should be used. Both will be
> rsynced to ibiblio and available to both Maven 1 & 2 clients.
> 
> I would suggest /dist/maven-repository as the location for this new
> repository (java is too specific - we hope to include more than java
> artifacts).
> 
> Some specific policies:
> 1) Clients would continue to point at ibiblio or a mirror, not directly
> at the Apache repository. In fact I have no problem with this either not
> being available over http if that assists in this goal, though it does
> make it easier to browse.
+1
> 
> 2) no development builds in /dist/. Currently, there is
> cvs.apache.org/repository for this in the Maven 1 style. A Maven 2
> repository of cvs.apache.org/nightly/maven-repository or similar would
> also need to be setup, though it would not be available to Maven 1
> clients. Maven 2 has built in controls to ensure development builds
> arrive at the correct repository (if setup). An alternative to having
> this repository on cvs.apache.org might be to have projects create their
> own in their zone, using whatever they use for nightly builds or
> continuous integration.

I would strengthen this to say explicitly that only *released* artifacts 
can be in /dist/ and that we enforce the policy (ideally in an automated 
way) that what gets put there corresponds *exactly* to what was released.
> 
> 3) require long groupId's. Currently the top level directory is polluted
> with a lot of different project names. I would like projects to use
> org.apache.project.subproject as the groupId so that it uses the
> directory structure /org/apache/project/subproject keeping individual
> directories with less files in them. The longest I can think of would be
> org.apache.jakarta.commons.collections. This should also be done for any
> future Maven 1 based releases (it works identically, but retains a
> shallow structure in the Maven 1 layout).

I don't know enough about maven repository management to understand 
fully the implications of this, but it seems to me that leaving 
"jakarta" out of the name adds flexibility with no loss of specificity. 
  So, if one day commons is a TLP, we do not have to rename.  It seems 
more natural to me to mirror the package names, but again I don't claim 
to understand all of the issues here.
> 
> 4) set permissions to group writable with the appropriate unix group
> governing modification of jakarta, for example. This is one area I'd
> like to investigate more to ensure we have proper controls on.
+1
> 
> 5) all files must have an .md5 and .sha1 checksum. Maven deploys these
> automatically, and I believe this is already monitored by a script which
> we could crack down on violations of in the new repo.
Out of curiousity, why both?  Does maven now generate both?
> 
> 6) all files in the /dist/ repository must have a .asc signature. We
> will need to get this automated by the final release of Maven 2.
What about KEYS?
> 
> Some things I would like to get more information on would be:
> - what is the best way to rsync this data from another machine?
> - what should the deletion policy be? I would think that something
> deleted from this repository should automatically be deleted from
> mirrors, the ibiblio Maven repositories and its mirrors.
+1
> - what should be the archive policy? People often use older releases
> from the repository, and require them for historical builds. If we want
> to archive them from this repository to archive.apache.org, they still
> need to be on ibiblio, so this needs to be managed with the deletion
> policy above.
Ambivalent on this one - I don't see a compelling reason to separate 
archived releases in the repository.  Is there an official apache 
archive policy? Maybe I am missing something.

Phil

Mime
View raw message