On 26/08/2010 8:10 AM, sebb wrote:
On 26 August 2010 12:42, Ron Wheeler<[email protected]> wrote:
On 25/08/2010 7:13 PM, Benson Margulies wrote:
Let me recap the pain scenario here:
Existing poms reference commons-net under the old group ID.
commons-net releases a new version under a new group ID.
Dependencies under the old group ID won't be seen as 'the same thing'
as the new group ID, so
a project that references the new group ID and has a dependency that
uses the old group ID gets both in the classpath, and probably
experiences chaos until repaired with exclusions.
Unless maven grew a feature whereby the new artifact could explicitly
declare itself a successor of the old one under the other name, this
is unavoidable. Either don't rename or live with this as an annoyance
to the users of the new version. Renaming packages might help, insofar
as the two versions might then coexist happily.
A way to deal with this is to do what we do at the application level and use
aggregate POMs to specify dependencies on third party software.
Once we shift to the new version with the new group id, we will have to add
an exclusion to each of our aggregation POMs to prevent third party packages
from pulling in the old group id.
But again, this is extra work for the user.
But it is only 1 or 2 POMs to look at and possibly change rather than 60
and we will not get caught up in the problem by accident.
It also affects only 1 person not the whole team.
We still have to be mindful of the issue when upgrading a version of a
third party library or adding a new one. It is hard to detect.
I'll say it again - unless and until Maven can transparently handle
such changes, getting the groupId etc correct in the first place is
very important, especially for libraries.
It does look like something that Maven should handle since there appears
to be a lot of effort to clean up groupIds at Apache and other places.
This will only get worse as Maven gets more popular and projects that
were early into Maven start to improve their groupId structure.
Ron
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
