We already do 2, it should be easier, but we already have that with
the synced repositories.
Central ideally is an aggregation of other repos, if anybody wants to
pick up a group, just ask for.
On 5/7/07, Joerg Hohwiller <[EMAIL PROTECTED]> wrote:
-----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]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
