maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arik Kfir" <>
Subject Re: avoid that central repo gets garbage dump
Date Sun, 06 May 2007 20:16:32 GMT
The biggest problem as I see it is not the groupId structures (although it
DOES bother me...) but rather the dependencies metadata which is often
incorrect, or atleast not quite right. Examples are numerous and range from
optional dependencies marked as required, testing dependencies in compile
scope, missing dependencies, etc. Not to mention informative metadata which
is often missing.

The problem is, many times we allow poms in the repo about projects we know
nothing about, or at least not enough. For instance, I could post an upload
request to Carlos for a private project of mine; Carlos has no idea (nor
should he have, of course) about my project, the dependencies it needs, etc.
So if I wrote a crappy pom, that's what goes in the repository.

Now think what happens when it's not a private project, but I was simply the
first person to post the upload request. The (bad) metadata is there for
good, due to backwards compatibility which Carlos guards (and rightfully

I see the solution in two layers:
1. Start over with a fresh repository (optional; we could go to an
incremental solution instead)
2. Start creating a federated repository maintainers network for select
projects/groups. For instance, say I know Hibernate very good and I request
the maven team to make me the repo maintainer for the "org.hibernate"
groupId. Now, if I know Hibernate better than Carlos (no offense - just an
example, I don't really know Hibernate that much), and Hibernate is my main
bread and water, I will probably do a better job at mainaining the metadata.

Note that having the actual project committers maintain their own pom is
always the best solution, of course; so if the Hibernate team wants to do so
- that always was and should stay the preferred solution.


On 5/6/07, Joerg Hohwiller <> wrote:
> Hash: SHA1
> > Hi,
> Hello,
> >
> > I'd like to throw in my 2 cents. The maven repository was (as I recall)
> > started back in the Maven 1.x days, when people didn't REALLY do ANY
> > dependency management. Since then, the repository grew, Maven1.x grew
> and
> > grew. A while later, Maven 2.x was released, and AFAIK the Maven
> > 2.xrepository is a conversion of m1's repository. One of the biggest
> > advantages
> > and DRAWBACKS of the m2 repo is that *there is no removal or
> > modification of
> > existing artifact versions" to preserve backward compatibility. This is
> a
> > valid argument - but it is also our achiles' heel, due to the amount of
> bad
> > metadata already there.
> >
> > Perhaps it is time we put all our knowledge we at the maven community
> have
> > acquired over time regarding PROPER dependency management and
> declaration,
> > in order to create a new project CLEAN repository, where all groups are
> > really mapped to actually owned domain names (no more "xerces" groupId,
> for
> > instance) and all metadata is validated and agreed upon.
> >
> > Start afresh.
> >
> > I've noticed the ""
> > repository, which seems like a nice starting place, though I'm not sure
> > what
> > it's for, really.
> >
> > What do you think?
> Well generally this sounds like a good plan to create a clean repository.
> Anyways I doubt how this finally solves the problem... Can we then just
> deprecate the current central repo? I have done big migrations in business
> tasks
> and from my point of view we have better chances if we take smaller steps
> and
> live with some legacy.
> Anyways a very easy idea for old groupIds could be to serve them as
> server-redirects. So "lucene" could automatically redirect to
> "org/apache/lucene" so it would be possible to gracefully migrate the
> deprecated
> groupIds in exsiting projects. The technical challange will just be the
> way to
> sync such information to all mirrors (might work via .htaccess files but
> they
> can be a security problem).
> A very little but still helpful thing to do, would be to put some "
> index.html"
> files in the deprecated groupId folders that point out to the problem and
> give a link to the new location. A lot of people just dig in the
> repository with
> their web-browser and sometimes people get lost in some folder like
> "springframework" and wonder why there is no up-to-date version.
> Additionally some metadata could be made available so that maven dumps a
> deprecation warning whenever such obsolete groupId is used in a POM.
> Best regards
>   Jörg
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> iD8DBQFGPiyRmPuec2Dcv/8RAjb5AJ4uDZZckEQyvWV/AT8gAH/gm1rxNwCgmEnJ
> =uz/V
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message