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 so). 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. WDYT? On 5/6/07, Joerg Hohwiller <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE----- 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 "http://repo1.maven.org/maven2-repoclean-java.net/"; > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGPiyRmPuec2Dcv/8RAjb5AJ4uDZZckEQyvWV/AT8gAH/gm1rxNwCgmEnJ vDMqsJ5z+YpSXaIDIRTkQDU= =uz/V -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
