On Sat, 2004-02-21 at 01:01, Mark R. Diggory wrote:
> Noel J. Bergman wrote:
> >>The issue is... the jars/distributables are placed into the
> >>java-repository using maven.
Can you explain this a bit? I thought Maven was used to fetch
projects and dependencies. Ofcourse I can read up on Maven,
but a quick summary of the technicalities would be appreciated.
> so, currently, if you look in
> >>something like the commons project.properties you'll see that
> >>they are pointing to the central repository for the location
> >>of where to "publish" files.
> >>The "convergence issues" we currently have for the repository:
> >> 1.) We want single copies of files on the mirrors.
> > +1
This is the core point.
> >>My best conclusion is
> >> keep "jars" in the java-repository, do not keep them
> >> in your /dist/<project>/<binaries> directory. Remove all
> >> [jar/zip/tar files] from the java-repository.
> >>symlnk the appropriate java-repository dir into their appropriate
> >>"dist" directory.
That would mean that this entire area would have to be rw to all
groups producing releases that are to be in there. This kindof means
apcvs group ownership, which I don't really fancy doing. The other
way around, control and access of each projects dist/ area seperated,
and symlinking to that from java-repository, seems a bit sa[fn]er to
> > That sounds OK to me, but folks like Sander and others more involved in
> > mirroring should be put in the loop. Everything we put under dist/ effects
> > 100s of mirrors.
Not me specifically, but Infrastructure. Others are more actively
maintaining the mirrors list and monitoring the mirrors. The mirrors
are a precious resource and we want to be careful not to 'scare' any
mirrors away with actions on our end.
> Yes, I learned that the hard way when we created the contents of
> java-repository... that was not a happy weekend. I don't make any "rash"
> changes to dist any more...Only well thought out moves. But we are in a
> state of cleanup now as well, we have to consider what we are going to
> do next.
If you are making large changes to the directory structure and the
majority of the files is already on the mirrors, send a mail to
mirrors@, attach a shell script that moves everything around locally,
and give them a heads up on when this shuffle is happening. This
save a _lot_ of bandwidth.
Also, when adding a lot, make sure to inform the mirrors, so they
> >>Discussion about how to finalize the directory structure such
> >>that "Repository", "Dist/Mirror" and "Maven" has to move forward.
I don't parse this, but since Noel can read it, I am probably missing
> > That would be good.
> In our last discussion, I think one of the conclusions that was arrived
> at as well, was the idea of breaking the java-repository up into two
> different locations.
> www/cvs.apache.org/dist/java-repository --> nightly builds
> www/www.apache.org/dist/java-repository --> official releases.
> the idea was that nightly/weekly builds are not things we want to see on
> mirrors but to be available for developers. And that official release of
> jars are things we want to see mirrored.
Is Maven using the mirrors today, like getting the list of active
mirrors from the main site and finding the closest? Or is it only
using the main site and perhaps iblibio?
> When it comes to things like the ibiblio maven repository, it would only
> maintain full version releases of apache projects.
Can you explain why ibiblio is special here? I mean, what you describe
is what is supposed to be on all the mirrors right?
> If your an apache
> project and need to be on the bleeding edge for a component, then you
> can simply add
> as your first repository location and get your apache jars straight off
> the nightly builds...
> The big question is how to facilitate this a build process, I think the
> last decision on the Jakarta Commons/General/Maven lists was that we
> would automate the build process for releasing the nightly jars into
> And the only publishing of jars by actual humans (Release Managers)
> would be the full releases onto
Symlinks I hope. Mirrors handle symlinks efficiently, that is,
if they follow our rsync instructions.
Take a look at http://www.apache.org/~henkp/md5/, specifically
the fyi: some duplicates section. Dups are a waste of bandwidth
I'll ask Henk to disable the checks for presence of md5 in the
dist/java-repository, since that doesn't seem to be applicable
there. It seems to me that you do want to do some verification
in maven, but you are probably storing signature information
somewhere in the maven 'database'?
> I believe this sort of approach would be inline with the policies of the