www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Plan of action] Setting up an official maven repository for the ASF
Date Wed, 07 Jun 2006 17:05:16 GMT
Henri Yandell wrote:
> Nothing from Brett yet, so braindump from me.

Henry, thanks for your reply.

> Two classes of repository - m1 and m2. We should focus on short-term
> goals for the m1 one and long-term for the m2 one.


> Some goals:
> * Development ease. It should not take forever to get a dependency
> deployed.

yes, although if shouldn't make it so easy that people will want to do
it without reading the "readme".

> * Authentic. PGP .asc files for each release.

I've been thinking about this and I suspect that this requires some
Maven changes. I mean, what's the point of having a PGP file if maven
doesn't use it? and currently the POM doesn't have the metadata to
locate the official PGP file (which, remember, should always fetched
from the original location never from a mirror.

> * Official. Projects should know their code is being placed in the
> repository.

Yes and I think that the PGP signature should contain trace of who did
it, so that there is some trace.

> * Oversight. People shouldn't be deploying jars randomly.

if we do the above, we solve this as well: knowing that you can be
traced, random stuff would slow down.

> * Complete. Javadoc, Source and Binary jars.

yup... I also believe that the maven2 plugin for eclipse is making
people aware of why this is needed.

Would also be nice if we could automate the extraction of such javadoc
jars and provide a javadocs.apache.org thingy

> * Stable. Files should not be easy to change.


> Multiple repositories are needed:
> * ASF Release Repository.
> * ASF Snapshot Repository. Deployed to from CI.
> * ASF Development Repository. May contain 3rd party jars and manual
> snapshots.

Can you elaborate more on this?

> Some random ideas:
> * Monitoring. Have a script that mails this list when something is
> added to the release or development repositories. Much like a cvs
> commit in another project.

great idea

> * Tighten things up in a staggered way. Every couple of months we can
> enforce something new. ie) All non-PGP signed jars will be removed by
> X.

+1, incrementality is good

> * Pull the Maven repositories out of the mirroring system. It's
> unnecessary. With the rsync being down atm, there's not a lot of
> reason to avoid it. In fact, rm the ones in the maven repos and move
> the ones in archive.apache to repo.apache.org. Need various
> repo.apache.org directory names.

I've had a wild idea the other day, inspired by some talks with some
other digital library fellows that were complaining about bandwidth
consumption. They pointed me at


which is something that ibiblio does to allow transparent
bittorrent-ization of resources.

And I thought... hmmm, we could take Azureus (which is a kickass
bittorrent implementation in java), strip down the transport part and
integrate it in maven. Then use osprey on repo.apache.org to
bittorrent-ize things.



View raw message