www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <brett.por...@gmail.com>
Subject Re: Maven repository policies
Date Tue, 26 Jul 2005 12:31:49 GMT
On 7/25/05, Steve Loughran <steve.loughran@gmail.com> wrote:
> +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? 

I'm not sure where you started from here? Someone that has a
commons-lang JAR file from somewhere else might have this problem.
Someone with a project with that dependency can see where it came
from, as can someone finding commons-lang through Jakarta (hopefully).

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

Absolutely. There is actually a M1 search hosted by someone else, and
we hope to develop a more comprehensive one for m2.

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

It's not quite that bad - for ASF artifacts it would still rely on the
ASF box getting compromised. Though where pretty good at doing that
ourselves (refer to commons-cli). Lots of tools needed in this area.

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

Not any more :)

> Some script also needs to run through all files, get their poms and
> verify that the dependencies can all be satisfied by the repositories,

http://jira.codehaus.org/browse/MRM-2

> or that somehow the artifacts are marked as non-uploadable (eg. sun
> jars with limited distribution)

Sun artifacts now have POMs so that they can be identified (though
they just contain a download link).

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

Yes, though I think the metadata is improving through increased use.
Spec. dependencies (which have been left for a bit later) will help
with the xml/j2ee/etc dependencies.

Nice job on the presentation, btw. - caught it on your blog.

Thanks,
Brett

Mime
View raw message