incubator-depot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: duplicate data
Date Wed, 25 Feb 2004 07:36:14 GMT

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,
>> correct?
>>  
>> [...]
> 
> 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 www.apache.org, 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, www.apache.org 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.

Good.

...
> 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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Mime
View raw message