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]
