+1 on this one
Cheers,
Rahul
Carlos Sanchez wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
