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 Wed, 01 Mar 2006 06:09:16 GMT
My reply to Henk in December.

On 12/28/05, Brett Porter <brett.porter@gmail.com> wrote:
> On 12/28/05, Henk P. Penning <henkp@cs.uu.nl> wrote:
> >   -- all apache.org software must be signed.
>
> Agreed. For now, I am manually chasing this in this directory, as
> syncs are on demand. Have got some of the automation steps in place.
>
> > Ideally, for legal
> >      reasons, every piece of software should be accompanied by
> >      a reference to a pmc's decision to publish ; for instance
> >      a reference to some mail in the public mail list archive.
>
> Never heard of doing this before. Would it be better stored in SVN
> with the tagged source code?
>
> >   -- 'dist/' must be kept clean because of bandwidth costs for
> >      the rsync roots and mirrors, and user convenience.
>
> ok, understood
>
> >   -- production stuff (stuff needed for (one time) installation
> >      of software) must be in 'dist/', that is, on the mirrors.
>
> ok, this is not really what the maven repository is for
>
> >   -- The ASF has no infrastructure to support applications that
> >      do some form of 'build', every time they run.
>
> This is not quite how Maven works, so I'll examine this more closely.
>
> Maven itself uses a plugin architecture, so downloads some of its code
> from the web at runtime. Depending on the plugin author, this code
> might be from Apache, or from someone else. And some of this code uses
> additional dependencies which also come from the repository. There are
> additional security aspects to this we need to take care of if it is
> to be secure without manually establishing all of this code, but
> that's how it works.
>
> The other use is for people building software, where they download
> their own dependencies from the repository using Maven. This has
> nothing to do with how they run, its a normal build process. Still,
> the same rules apply as above.
>
> >   Is it correct that, currently, 'ibiblio' is the only 'user'
> >   of the repository, in the sense that no 'clients' use the
> >   apache.org repo ? Is that what you ean by "mirroring is all
> >   done through Maven's repository system".
>
> Yes. There is a lot more software in the Maven repository than that
> that comes from Apache, but we'd obviously like to make it easy (as
> well as secure!) for Apache projects to publish their artifacts to
> that repository system.
>
> >   Because the 'java-repository' model of software devellopment and
> >   distribution is quite unlike that of 'projects'. Any change requires
> >   approval of the mirror team (apmirror@a.o), infrastructure and
> >   eventually the board.
>
> I'm not clear on what you mean here.  Basically, there are two groups
> of people here:
> - the apache projects publishing releases (this includes us). They
> publish it under the same rules they always have, but place it in a
> format that Maven can digest (though it doesn't use the apache servers
> directly).
> - the maintainers of the central repository (ibiblio and its mirrors).
> While a group of Maven developers also work on this, its not part of
> the Apache project. It doesn't distribute any code, but just manages
> other peoples distributions and getting them into one place so Maven
> can find them easily.
>
> I don't see that this really changes any policies (maybe I'm over
> simplifying), but I'm more than happy for the decision of how best to
> do this to be reached and have that agreed by the Maven PMC,
> infra/mirrors and the board.
>
> >   If my summary above is correct, removing the repo's from dist
> >   would be a good idea, provided that stuff is signed and the
> >   new repo isn't a 'sigle resource' for maven clients.
>
> Agreed. So I guess this opens up a new question - where?
> www.apache.org/maven-repository? maven-repository.apache.org? Or
> should it be somewhere not web available and only for external sync to
> ensure clients don't use it? (it would never be a default, but it is
> possible to use it, and particularly browse it).
>
> >
> >   Putting stuff directly is 'archive' is not a good idea, imho.
> >   It is an archive of '/dist/', and that shouldn't change.
>
> Makes sense. I think so too.
>
> Thanks for all your help! Back to signing the rest of my keys from
> ApacheCon US :)
>
> - Brett
>

Mime
View raw message