Mark R. Diggory wrote:

Sander Striker wrote:

I understand. But it has to be fairly mature before one can
deploy and recommend using it to the PMCs. Also, you can't
force all the projects to use it. For this you need some way
of handmaintaining 'shadow' packages in java-repository,

Maven exists and is used by many apache projects, I am, in no way, promoting any sort of "requirement" that projects be forced to use it. I am primarily concerned with maintaining the content properly for the projects that do use it and in assuring that the Apache Repository structure be convergent and that future versions of Maven be able to support it. I approach this because I am and will be a user of both, not as a developer of one or the other.

Currently the duplication is minimal because projects that distribute actual jars are already using maven specifically, otherwise they package into archives (zip/tar).

In the Incubator there is the Depot project, and specifically Ruper, that also can work with this kind of repositories. So we are already in two tools that can work with them, and this list was created to define best practices and common ground between repository projects.

But this is fairly utopic at this point, no?  Is the Repository URI spec
stable?  Is the tool mature?

I may only be able to speak only for myself at this point.

The spec is actually very "independent" of the clients/tools that may make use of it. Using Maven as an example, the tool is becoming mature, not in that it has officially gone 1.0, but that the usage (especially for java projects at apache) is becoming very prevalent. It represents a popular base of users that need accessibility to the repository.

It may be utopic in that I/We are working to unify disparate groups and existing resources into a standardized directory structure. But ultimately such a goal can only benefit Apache as a whole.

There is already a standard directory structure at Apache AFAIK. Why does it have to change yet again?

That looks like a priority then.  It will make it actually make
all the mirrorring worth it.  And it should help the user aswell,
since closer hosts usually mean quicker downloads.

Yesssss, we need to make our tools take advantage of it.

Ruper can already do so, and it does so also for sourceforge projects. While the Maven tools are ATM focused on a main repository AFAIK, we are more on making people publish where they prefer.

I'd say the default should be, and from there it should
select the 'best' mirror.  Note that for any mirror use, and that
includes ibiblio, integrity checking is a must for an application
like Maven.

Its a struggle, because, currently doesn't represent the canonical contents for maven itself. I'm not sure how positive the Maven group is about "distributed" retrieval, but it is something I see as very important.


Its not like "Maven" is run on minotaur, Maven is run on a client, it establishes an ssh session and performs the md5sum command on minotaur, but the client side script that does this isn't configurable, and is hardcoded to call Linux/Gnu md5sum. I will submit a bug to Maven to make it more configurable, currently all md5 checksums generated using Maven are broken because of this, I think others have recognized this and generate them by hand on their own.

In Ruper we have an md5sum implementation in the scratchpad. What about checking that we are on the same boat with the md5 format? :-)

I am seeing that you are struggling to set up the repository for Apache, and it's unfortunate, as it's a great thing if done well.

Depot guys, shall we give him a hand, and stop profiting from his kind work without giving back? :-)

Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

Reply via email to