On 2/17/08, simon <[EMAIL PROTECTED]> wrote: > > On Sun, 2008-02-17 at 10:34 +0100, Emmanuel Bourg wrote: > > James Carman a écrit : > > > Well, I'd like to see commons have some consistency to it. I would > > > rather every component within commons follow the same naming > > > conventions w.r.t. packages and I guess now artifactIds (I didn't > > > realize that was an issue within maven until I did my little test > > > tonight). Maybe I'm just too much of a neat freak. :) > > > > Actually my concern with the new name is the number at the end. I'm > > pretty sure this will be confusing for the users, people with the > > commons-configuration2-2.1.jar in their project will believe to have the > > 2.2.1 revision. If we have to change the artifactId I would support > > "commons-config" instead. > > > > I would definitely be against having > commons-configuration:commons-configuration > and > org.apache.commons:commons-configuration > being two incompatible packages. >
Perhaps the 1.5 branch should have a release which just changes the groupId? > There is a slow process of migrating commons libraries from the old > style of groupId to a proper groupId of org.apache.commons. This > migration is also happening for projects where no incompatible changes > are being made, ie is just a "namespace cleanup". > > Yes, I agree that configuration2-2.1 could be misinterpreted by some > people as 2.2.1, but I think it is less likely to cause confusion than > keeping the same artifactId for two incompatible packages. > > Using an artifactId of commons-config is possible, but what if there is > another change at some time in the future that is again so significant > that it is necessary to permit installation of old and new code in > parallel? [Well, by then Java might have a mechanism for handling this > built-in (like .Net), so it might be a moot point..] > Changing it to commons-config could work, but what about all the other commons packages? They really don't have the luxury of just changing their artifactId to avoid the suffix. If we're going to do something like this, we should do it consistently across all commons projects (I'd argue that all ASF Java projects should try to follow some "standard"). > Regards, > Simon > > > --------------------------------------------------------------------- > 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]
