You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@depot.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2004/02/25 07:36:14 UTC
Re: duplicate data
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)
---------------------------------------------------------------------
Re: duplicate data
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Sorry for the later response, currently, I think the major issues are in
managing the content of java-repository in responsible manner.
Key issues I can see needing to be addressed are the following.
1.) Get projects to be as "responsible" for their content in
java-repository as they are for the content of their "project"
directories in dist.
2.) Resolve the only duplication left which has to do with the fact that
avalon runs their own "Avalon Repository" in /dist/avalon. So its
contents are currently duplicated with java-repository/ibiblio.
3.) Maintaining proper permissions on all the directory contents of the
repository (group write, group ownership of files and new directories
should be the users primary group)
4.) Find a way around the current "shortsightedness" in Maven where the
command executed on the serverside are all "gnu linux" and do not map to
BSD, md5 = md5sum. So using the "repository" goals in maven fails to
produce proper md5 checksums.
Nicola Ken Barozzi wrote:
> Some action items:
>
> 1- how can we make mirroring work for both of us? (IIRC Ruper already
> showed it's easy to do, but I need help from Adam that already tried it)
>
> 2- How does Mark think we can proceed in not making it compulsory to
> phisically have jars in a defined location?
>
These two are a "double-whammy", but I think I have a possible solution
to the whole subject. Currently we think of the "Repository" as just
that "A Repository", a physical location for the jars. But what if we
defined the URL's for a "Repository" to simple be pointers or addresses
that when resolved by a client, point to the proper location of that
resource. This in essance, makes the repository into a resolver or a
naming service.
In my line of work (Digital Libraries) we already have a service that
accomplishes this task (actually we have 2 competing/complimentary
naming systems)
PURLS (Persistent Uniform Resource Identifier)
http://www.purl.org
http://www.oclc.org/research/projects/purl/download.htm
Handles (analogous to publicId's, ISBN's, Dewey Decimal System,, etc...)
http://www.handle.net/
http://www.handle.net/download.html
If your wondering how PURLs and Handles stack up, heres some comparison
documentation.
http://www.nclis.gov/govt/assess/handles.html
http://memory.loc.gov/ammem/award/docs/PURL-handle.html
http://web.mit.edu/handle/www/purl-eval.html
So what we are talking about really is a naming system that provides for
the "resolution" of registered names to physical locations. Interesting
ly, I think the lack of this sort of separation of "Resolution" from
"Storage" is exactly the issue that is causing "friction" in our community.
I think its quite possible, that one could completely and transparently
replace the underlying URL based repository syntax in both Maven and
other tools with a resolving layer. to clarify this, heres a few examples.
1.) an example using PURL's.
http://www.ibiblio.org/maven/xerces/jars/xerces.jar
this is currently a URL pointing to physical resource on ibiblio.
if this were not a physical resource but a PURL in the PURL naming
system, then it could (redirect using currently existing PURL server
software) the client to the appropriate resource (mirrored or not).
http://repository.apache.org/maven/xerces/jars/xerces.jar
would actually resolve (through redirection to)
http://www.apache.org/dist/xml/xerces-j/jars/xerces.jar
and
http://repository.apache.org/xml.apache.org/xerces/2.0/jars/xerces.jar
could also point to
http://www.apache.org/dist/xml/xerces-j/jars/xerces.jar
This provides a layer of flexiblity, its solves issues with both the
projects needing to place their content in a specific structure/location
and it also solves issues of name changes over time,
2.) So if we decide that we want to have different "groupID's" in maven
for a specific project, the naming system maintains the old naming
structure pointing to the jars as a means for dependent projects to
still be able to resolve to the resource.
http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-1.0.jar
we are currently planning to adopt a more hierarchical naming approach
http://www.ibiblio.org/maven/jakarta.apache.org/commons-collections/jars/commons-collections-1.0.jar
We could (at little cost in both maintenance and diskspace) , maintain
the old naming resolution and the new one. In fact, this is the very
foundation of the PURL system, the old uri's stay persistent over time.
3.) With such a level of "redirection", we can also maintain archival
and production releases of the content without the actual location
specifier changing. So when Apache retires commons-collection-1.0.jar
from production and removes it from the mirrors, instead placing it onto
archives.apache.org, then that resolver entry in the PURL database can
be adjusted to point at the new location>
http://repository.apache.org/maven/commons-collections/jars/commons-collections-1.0.jar
now points to the following location instead:
http://archive.apache.org/maven/commons-collections/jars/commons-collections-1.0.jar
> 3- We really should see that the md5s are compatible between Ruper and
> Maven (IOW Mark meet Markus, Markus meet Mark :-)
>
4.) I think that as well, the usage of both signatures and md5 checksums
as user metadata in the system can be maintained on the filesystem and
in the database for comparison, the clients can compare the
md5's/signatures in the naming system with those of the filesystem and
as such verify the integrity of the resolved resource is the same as was
intended when the name was registered with the naming system.
5.) Finally, Naming systems can be "Chained" together in such a way that
http://www.ibibilio.org/maven/apache is actually a PURL to the the
Apache Naming resolver http://repository.apache.org so that
http://www.ibiblio.org/maven/apache/commons-collections/jars/...
is actually resolved by ibiblio to:
http://repository.apache.org/apache/commons-collections/jars/...
which is then resolved by repository.apache.org to:
http://<your mirror here>/jakarta/commons/collections/jars/...
It may seem complex at first, but its not really, and it something that
the library community has been working on for years now, so it is well
tested. The examples I've shown are PURL based, but the use of Handles
and Purls is a complimentary and bridges between the to resolving
systems do exist.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
Re: duplicate data
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Sorry for the later response, currently, I think the major issues are in
managing the content of java-repository in responsible manner.
Key issues I can see needing to be addressed are the following.
1.) Get projects to be as "responsible" for their content in
java-repository as they are for the content of their "project"
directories in dist.
2.) Resolve the only duplication left which has to do with the fact that
avalon runs their own "Avalon Repository" in /dist/avalon. So its
contents are currently duplicated with java-repository/ibiblio.
3.) Maintaining proper permissions on all the directory contents of the
repository (group write, group ownership of files and new directories
should be the users primary group)
4.) Find a way around the current "shortsightedness" in Maven where the
command executed on the serverside are all "gnu linux" and do not map to
BSD, md5 = md5sum. So using the "repository" goals in maven fails to
produce proper md5 checksums.
Nicola Ken Barozzi wrote:
> Some action items:
>
> 1- how can we make mirroring work for both of us? (IIRC Ruper already
> showed it's easy to do, but I need help from Adam that already tried it)
>
> 2- How does Mark think we can proceed in not making it compulsory to
> phisically have jars in a defined location?
>
These two are a "double-whammy", but I think I have a possible solution
to the whole subject. Currently we think of the "Repository" as just
that "A Repository", a physical location for the jars. But what if we
defined the URL's for a "Repository" to simple be pointers or addresses
that when resolved by a client, point to the proper location of that
resource. This in essance, makes the repository into a resolver or a
naming service.
In my line of work (Digital Libraries) we already have a service that
accomplishes this task (actually we have 2 competing/complimentary
naming systems)
PURLS (Persistent Uniform Resource Identifier)
http://www.purl.org
http://www.oclc.org/research/projects/purl/download.htm
Handles (analogous to publicId's, ISBN's, Dewey Decimal System,, etc...)
http://www.handle.net/
http://www.handle.net/download.html
If your wondering how PURLs and Handles stack up, heres some comparison
documentation.
http://www.nclis.gov/govt/assess/handles.html
http://memory.loc.gov/ammem/award/docs/PURL-handle.html
http://web.mit.edu/handle/www/purl-eval.html
So what we are talking about really is a naming system that provides for
the "resolution" of registered names to physical locations. Interesting
ly, I think the lack of this sort of separation of "Resolution" from
"Storage" is exactly the issue that is causing "friction" in our community.
I think its quite possible, that one could completely and transparently
replace the underlying URL based repository syntax in both Maven and
other tools with a resolving layer. to clarify this, heres a few examples.
1.) an example using PURL's.
http://www.ibiblio.org/maven/xerces/jars/xerces.jar
this is currently a URL pointing to physical resource on ibiblio.
if this were not a physical resource but a PURL in the PURL naming
system, then it could (redirect using currently existing PURL server
software) the client to the appropriate resource (mirrored or not).
http://repository.apache.org/maven/xerces/jars/xerces.jar
would actually resolve (through redirection to)
http://www.apache.org/dist/xml/xerces-j/jars/xerces.jar
and
http://repository.apache.org/xml.apache.org/xerces/2.0/jars/xerces.jar
could also point to
http://www.apache.org/dist/xml/xerces-j/jars/xerces.jar
This provides a layer of flexiblity, its solves issues with both the
projects needing to place their content in a specific structure/location
and it also solves issues of name changes over time,
2.) So if we decide that we want to have different "groupID's" in maven
for a specific project, the naming system maintains the old naming
structure pointing to the jars as a means for dependent projects to
still be able to resolve to the resource.
http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-1.0.jar
we are currently planning to adopt a more hierarchical naming approach
http://www.ibiblio.org/maven/jakarta.apache.org/commons-collections/jars/commons-collections-1.0.jar
We could (at little cost in both maintenance and diskspace) , maintain
the old naming resolution and the new one. In fact, this is the very
foundation of the PURL system, the old uri's stay persistent over time.
3.) With such a level of "redirection", we can also maintain archival
and production releases of the content without the actual location
specifier changing. So when Apache retires commons-collection-1.0.jar
from production and removes it from the mirrors, instead placing it onto
archives.apache.org, then that resolver entry in the PURL database can
be adjusted to point at the new location>
http://repository.apache.org/maven/commons-collections/jars/commons-collections-1.0.jar
now points to the following location instead:
http://archive.apache.org/maven/commons-collections/jars/commons-collections-1.0.jar
> 3- We really should see that the md5s are compatible between Ruper and
> Maven (IOW Mark meet Markus, Markus meet Mark :-)
>
4.) I think that as well, the usage of both signatures and md5 checksums
as user metadata in the system can be maintained on the filesystem and
in the database for comparison, the clients can compare the
md5's/signatures in the naming system with those of the filesystem and
as such verify the integrity of the resolved resource is the same as was
intended when the name was registered with the naming system.
5.) Finally, Naming systems can be "Chained" together in such a way that
http://www.ibibilio.org/maven/apache is actually a PURL to the the
Apache Naming resolver http://repository.apache.org so that
http://www.ibiblio.org/maven/apache/commons-collections/jars/...
is actually resolved by ibiblio to:
http://repository.apache.org/apache/commons-collections/jars/...
which is then resolved by repository.apache.org to:
http://<your mirror here>/jakarta/commons/collections/jars/...
It may seem complex at first, but its not really, and it something that
the library community has been working on for years now, so it is well
tested. The examples I've shown are PURL based, but the use of Handles
and Purls is a complimentary and bridges between the to resolving
systems do exist.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
Re: duplicate data
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Markus M. May wrote:
>
> Nicola Ken Barozzi wrote:
>>
>>Mark R. Diggory wrote:
...
>>>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? :-)
>
> Shurly think so! How can we help here?
We have a spec that has come out of this list, but we also have two
implementation (Maven and Ruper) that currently work with the "old" layout.
Hence IMNSHO we should help Mark and others in setting up a
Maven-compatible repository at Apache, and eventually deal with the new
spec later.
Sander has already given a hand in idenifying some points that have to
be addressed, it would be cool if we could come up with concrete
suggestions on going forward and actually helping publishing the jars.
Some action items:
1- how can we make mirroring work for both of us? (IIRC Ruper already
showed it's easy to do, but I need help from Adam that already tried it)
2- How does Mark think we can proceed in not making it compulsory to
phisically have jars in a defined location?
3- We really should see that the md5s are compatible between Ruper and
Maven (IOW Mark meet Markus, Markus meet Mark :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: duplicate data
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Markus M. May wrote:
>
> Nicola Ken Barozzi wrote:
>>
>>Mark R. Diggory wrote:
...
>>>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? :-)
>
> Shurly think so! How can we help here?
We have a spec that has come out of this list, but we also have two
implementation (Maven and Ruper) that currently work with the "old" layout.
Hence IMNSHO we should help Mark and others in setting up a
Maven-compatible repository at Apache, and eventually deal with the new
spec later.
Sander has already given a hand in idenifying some points that have to
be addressed, it would be cool if we could come up with concrete
suggestions on going forward and actually helping publishing the jars.
Some action items:
1- how can we make mirroring work for both of us? (IIRC Ruper already
showed it's easy to do, but I need help from Adam that already tried it)
2- How does Mark think we can proceed in not making it compulsory to
phisically have jars in a defined location?
3- We really should see that the md5s are compatible between Ruper and
Maven (IOW Mark meet Markus, Markus meet Mark :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: duplicate data
Posted by "Markus M. May" <mm...@gmx.net>.
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 nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: duplicate data
Posted by "Markus M. May" <mm...@gmx.net>.
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 nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>