On Thu, 2005-06-16 at 10:10 +1000, Brett Porter wrote:
> Hi,
> 
> Some time ago we agreed that we wanted group IDs to resemble packages. 
> I'd like to start pushing for this. I will come up with a plan for 
> migrating existing stuff without breaking compat and working with our 
> sync partners, however the logic first step is to not allow any new 
> MAVENUPLOADs to come in with a flat group ID, even if it is just a new 
> version of the previous library. We can update the repository upload 
> page accordingly.
> 
> What do others think?

I think we need to grant a grace period on this so that people have a
some notice. A little doco explaining the rational with examples and
such would also be useful as this change in will spawn quite a bit of
POM editing. 

> Also, we need to bear in mind this is more than just Java, potentially, 
> so let's think more about org. structure than package name. eg, I think 
> org/apache/jakarta/commons instead of org/apache/commons is appropriate.
> 
> One thing I'm a little hesitant about is the depth of the group. For 
> example, if commons was the group, and one commons library (jelly) had 
> more than one artifact, it either needs its own group, or it pollutes 
> the commons namespace. If it has its own group, so should others, and 
> that might be more information that we need. ie 
> o/a/j/commons/collections; commons-collections. OF course, having an 
> inconsistency is also an alternative.
> 
> The options, by example (group; artifact):
> i) o/a/j/commons; commons-collections and o/a/j/commons; 
> commons-jelly-tags-ant
> ii) o/a/j/commons/collections; commons-collections and 
> o/a/j/commons/jelly; commons-jelly-tags-ant
> iii) o/a/j/commons; commons-collections and o/a/j/commons/jelly; 
> commons-jelly-tags-ant
> 
> I'm inclined to go with (iii), and maybe even add /tags/ to te group. 
> The inconsistency seems ok to me as long as it is documented on the 
> site, and they all have a common root.
> 
> Any opinions?

I would opt for ii) where each groupId would correspond to a commons sub
project. Being more specific I think is fine and allow for the case when
something like commons-collections splits out into more then one
artifact. I think ii) is more consistent and doesn't provide that much
more of a burden on users and I think it makes direct repo browser a bit
easier.

> - Brett
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
-- 
jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org

Simplex sigillum veri. (Simplicity is the seal of truth.)


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to