I think we should enforce only the root groupIds and then it's up to each project the number of subgroups they made. They will always be able to refactor new versions and split them in subgroups if they want. eg. we require that if you have a foo.com domain your groupId is com.foo but after that it's up to you. If you have a foo.sf.net we require net.sf.foo but no more than that.
Also I agree with providing some kind of deprecation info in m2 poms, and probably it will be a better option to update always the m2 repo and autogenerate everything in the m1, because the m2 one has more metadata. Regards On 6/15/05, Brett Porter <[EMAIL PROTECTED]> 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? > > 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? > > - Brett > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
