www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <steve.lough...@gmail.com>
Subject Re: Maven repository policies
Date Mon, 25 Jul 2005 12:10:19 GMT
On 7/25/05, Brett Porter <brett@apache.org> wrote:

> 
> 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).

+1 

if there is one problem here, it is finding stuff if you dont know its
origin. For example, if I am browsing for commons-lang, should i have
to know it is a jakarta-commons project? As browsing is usually a
preamble to determining which versions are available, we may need a
human usable search interface to go with the nested layout.


> 
> 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.
> 
> 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.
> 
> 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.

yes, we have a big security issue here waiting to be found and abused. 

7. All distributable files must have a .pom, even if it is a minimal
(zero dependency) one. Without this the maven tasks break.

Some script also needs to run through all files, get their poms and
verify that the dependencies can all be satisfied by the repositories,
or that somehow the artifacts are marked as non-uploadable (eg. sun
jars with limited distribution)

I also worry about pom files with excessively tight dependencies to
things like xml parser implementations (e.g. jdom demands dom4j that
isnt found).

> 
> 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.
> - 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.
> 

Good point. Maybe we need a server of very old stuff (5+ years) that
is the last resort for old stuff.

Mime
View raw message