-----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]
