-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, > 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? I have to think about 1. But 2. is a very good approach that I would agree immediatly. Yep, we should have maintainers for specific groupIds (I think somehow we already have this e.g. for javax, etc. - but it is not really handled properly). And yep, the first candidate for the maintainer of a groupId would be the somebody out of the team that develops the artifacts.
Regards Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGP2YJmPuec2Dcv/8RAsM2AJ41r/n4hRZ4Xq6P48Pk59dZIkyHAACdFctT Do81iANpcc8Sch+OOo0hvgU= =5znd -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
