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: Summary
Date Wed, 01 Mar 2006 10:44:50 GMT
On 3/1/06, Henri Yandell <flamefew@gmail.com> wrote:
> Things seem quite quiet here. This is what I understand by reading the
> various emails and wiki pages (Brett/Robert); and hassling Brett
> mercilessly on IRC (sorry Brett):
> There are four repositories:
> /www/www.apache.org/dist/java-repository  - ibiblio-sync m1 repo
> /www/www.apache.org/dist/maven-repository  - ibiblio sync m2 repo
> /www/cvs.apache.org/dist/maven-snapshot-repository  - snapshot m2 repo
> /www/cvs.apache.org/dist/repository  - snapshot m1 repo
> The aim being to kill the m1 repo's and replace them with the m2
> repo's at some point soon.


I didnt know about the m2 repo on cvs.apache.org; does it still have
everything of the m1 repository; it looks fairly sparse compared to
the m1 repo


the latter includes 3rd party things like jena, which is part of the
problem. But maybe maven users want to use snapshots of non-apache
stuff; it needs a place too, somewhere.

> There are various rules:
> * jars must be: md5'd, sha1'd, pgp (.asc'd).

+1 to the PGP; I see you have been hassling people there. We have to
make sure that the pgp key works with bouncycastle for future options.
I think it may be useful to have a signatory
thirdparty-not-apache-trusted for signing 3rd party stuff, so that you
can choose whether or not to trust the third party stuff, but still
have tamper-resistance in the system.

> * only asf artifacts should be present

OK, though somewhere is needed for third party things. Sourceforge?

> * SNAPSHOTs must not appear in the ibiblio-sync repos
> * md5 files have a specified format
> There are various issues:
> * unknown releases have been done (velocity-dvsl)
> * jars have been overwritten (commons-cli)
> * unknown projects have been released (commons-grafolia?
> commons-jdbc2pool? magicGball?)
> * oversight is therefore non-existent
> * structure is sloppy in the m1 repos (tbh, it's sloppy in the m2 repos too)
> * non-asf artifacts are there
> There's history:
> * This list was created with lofty goals - and various build system
> involvement to create a repository structure of use to as many people
> as possible (the success of the maven repository having driven a
> desire to include all and not just maven)
> * Now it's really just a place for managing the maven repository -
> which the three main build systems in Java can all easily use (ant,
> maven1, maven2)
> * The wiki is mostly a result of the former character; mostly water
> under the bridge now.
> There's a plan for needed docs from Brett:
> We need:
> - how to upload releases to the repository manually (ant users, etc)

Ant should be automated too. If it aint, we've failed. I'd expect a
.pl or .py script for unix people too. Distribution is far too
important to do by hand.

> Here's some thoughts:
> * The repository needs to be sliced into TLP structure. Things will
> move when TLPs move; user's will have to deal. Authentication needs to
> be in place so that TLPs have access only to their part of the
> structure - this will do a good job of lessening the ability to push
> out non-asf things.
> * We need to be monitoring things as they get added. Ideally, an email
> to repository@ whenever a file is added. Bigger emails when a file is
> changed.

yes. state monitoring is good. an RSS feed too ?

> * We need to enforce that the correct amount of files are added.
> Personally I think we should be enforcing that src and javadoc are
> also added; along with the jar, pom and various auth files.


> * The m2 repo needs cleaning ASAP (why is there anything in those two
> repos top dirs except 'org'? We then need to be very firm on keeping
> it clean and migrate the relevant parts of the m1 repo across - or
> maybe ask the pmcs to do so. Finally we need to rm -r the m1 repo.

this is trouble. I think it may already be almost too late to impose a
new structure. But if we don't, then we end up in the
scalability/management mess that we are trying to leave behind.

If it were done, then do it now: patch every pom, move every file. Be
brutal, before the migration from m1 to m2, has taken place, and
before the m2 tasks get used much in ant. And before "Java development
in Ant, 2nd edition", is code-frozen. I will take on the work
correcting that :)

The other bit of interest is on the maven dev list; glassfish includes
all the source to many of the javax.* artifacts. We cannot redist the
compiled stuff, but we are allowed to recompile and redist. so we may
have to have a repository of Apache-rebuilt-sun stuff in some location


View raw message