I agree with what Brian has said. FWIW, any organisation can
implement this internally in minutes by configuring any one of the
available repository managers [1].
The only thing I'd add is that in my opinion Maven needs better
support for true mirrors (of central, but also any other repo), as
well as strong support for non-central repositories which is
presumably the source of a problem you are having with right now to
inspire this?
Cheers,
Brett
[1] http://www.devzuz.org/blogs/oching/2007/11/05/1194233400000.html
On 13/11/2007, at 4:07 AM, Brian E. Fox wrote:
This sounds good on paper, but in practicality it could be
troublesome.
First of all, there are many more moving parts and we can't be sure of
or control the reliability of all these remote repos. Recall the
trouble
we had with Ibiblio a few years ago and the instability there. Since
central moved to Contegix, it has been remarkably fast and reliable. I
believe there is also a hot back already available for this.
Additionally, for locations that have restrictive proxy/firewall
policies, this would be a nightmare. They would constantly need to
have
access opened up to new repos and it might be impossible to predict
ahead of time exactly which ones they may need.
For those reasons, I would be -1 on this.
--Brian
-----Original Message-----
From: David Siefert [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 13, 2007 4:36 AM
To: [email protected]
Subject: Proposal for a Maven Dependency Registry
Hi,
I am not sure if anyone has already asked about this, but in case
not I
am
proposing the idea now: a Maven Dependency Registry.
I created a very simple web application (could not attach here--
detected
as
spam) that accepts requests for files (presumably the Maven 2
convention
for
a dependency located in the
repository), looks up a registry of groupId's based on a properties
file,
and sends an HTTP 302 redirect response with the appropriate registry
location's full path. It is not perfect yet--it is just a Proof of
Concept.
I am attempting to solve some issues, namely:
1> Relieves the burden of the Maven projects staff of maintaining the
big,
bloated, disorganized repository. This effort will be handled by
those
who
actually release libraries (such as JBoss.org, Codehaus, Apache
projects,
etc). The repo1.maven.org should eventually die off (dependencies
removed
as others register their groupId with their repository), or only be
left
for
Maven itself and the bundled plugins that are maintained.
2> Since the original authors of the dependencies will maintain their
own
small release/snapshot repository, all the POM information will
automatically be bundled, and nothing has to be fished down
(transitive
dependencies that were not specified because the libraries were loaded
from
a non-Maven project). Transitive dependencies stay on their
respective
repository and don't lose their valuable Maven build information.
3> Speedier access to the Maven core repository, and other
repositories
for
that matter since the repository is smaller and not needed for
everything.
4> Lower maintenance requirements of the Maven team--more time for bug
fixing.
Maybe these aren't good enough reasons, or developers of Maven may
see a
reason NOT to have a registry. That is why I am only proposing the
idea
and
presenting a small proof of concept. If it is not ideal, then I won't
waste
my time developing this any further.
I appreciate any and all feedback.
Thanks,
David Siefert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
