Shurly think so! How can we help here? R,
Markus > > 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 [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- >
