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]
