You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by sebb <se...@gmail.com> on 2010/08/23 14:20:21 UTC
Correcting a groupID
Apache Commons NET currently uses the groupId commons-net. However, it
should really use the groupId org.apache.commons.
Is it possible to set up the Maven repos so that this change is
transparent to users?
Or does changing a groupId necessarily involve change for end-users?
==
AIUI, a redirect pom can be created, which will cause references to
commons-net to be seen as org.apache.commons, at least when
downloading.
For example:
NET 2.0 groupId = commons-net
Create NET 2.x with groupId org.apache.commons
Then a project that references commons-net:commons-net:2.x will
download org.apache.commons:commons-net:2.x
(though there will be a warning logged)
[For example, see JDom 1.1, which changed groupId jdom => org.jdom]
However, what happens if a project has (transitive) dependencies on
both versions of Net?
Does Maven know how to resolve these correctly so that only the 2.x
release of Net is used?
Or is it necessary to change the Net package name in order to avoid conflict?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Benson Margulies <bi...@gmail.com>.
How about this: next time you make a release, publish both a dummy
version on the old groupId and the new one? That won't help people
whose dependency graph reaches both a 'live' version of the old one
and the new one, but it will help some people.
Other projects have switched and survived, though perhaps the carnage was great.
On Mon, Aug 23, 2010 at 12:12 PM, sebb <se...@gmail.com> wrote:
> On 23 August 2010 15:28, Wayne Fay <wa...@gmail.com> wrote:
>>> Apache Commons NET currently uses the groupId commons-net. However, it
>>> should really use the groupId org.apache.commons.
>>
>> Unless you're responsible for these artifacts (a member of the Apache
>> Commons NET PMC), you're going to have a lot of trouble doing anything
>> about this. Appeal to them. Make sure that all future releases use
>> what you are saying is the "proper" groupId.
>
> I am on the Commons PMC and proposed releasing Net with the new
> groupId, but was told that it was necessary to change the package name
> to prevent problems.
>
> That seemed like a serious restriction so I thought I would ask on the
> Maven list for a second opinion.
>
>> Until then, use dependency exclusions to block the commons-net grouped
>> artifacts that are coming in via other dependencies in your project.
>
> Thanks, that's useful to know - but not necessary here.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by sebb <se...@gmail.com>.
On 23 August 2010 15:28, Wayne Fay <wa...@gmail.com> wrote:
>> Apache Commons NET currently uses the groupId commons-net. However, it
>> should really use the groupId org.apache.commons.
>
> Unless you're responsible for these artifacts (a member of the Apache
> Commons NET PMC), you're going to have a lot of trouble doing anything
> about this. Appeal to them. Make sure that all future releases use
> what you are saying is the "proper" groupId.
I am on the Commons PMC and proposed releasing Net with the new
groupId, but was told that it was necessary to change the package name
to prevent problems.
That seemed like a serious restriction so I thought I would ask on the
Maven list for a second opinion.
> Until then, use dependency exclusions to block the commons-net grouped
> artifacts that are coming in via other dependencies in your project.
Thanks, that's useful to know - but not necessary here.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Wayne Fay <wa...@gmail.com>.
> Apache Commons NET currently uses the groupId commons-net. However, it
> should really use the groupId org.apache.commons.
Unless you're responsible for these artifacts (a member of the Apache
Commons NET PMC), you're going to have a lot of trouble doing anything
about this. Appeal to them. Make sure that all future releases use
what you are saying is the "proper" groupId.
Until then, use dependency exclusions to block the commons-net grouped
artifacts that are coming in via other dependencies in your project.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Dennis Lundberg <de...@apache.org>.
Cross posting from users@, since this is something we need to address.
Can someone volunteer to rewrite that page to reflect today's reality.
On 2010-08-24 17:00, Wayne Fay wrote:
>> The guide to relocation:
>>
>> http://maven.apache.org/guides/mini/guide-relocation.html
>
> Hmmmmmmm I really don't agree with this approach, and don't believe it
> would pass muster today. This documentation is most likely old.
>
> Today's mantra is "artifacts don't change". This includes poms and
> jars etc. I believe the correct approach today would be to put
> relocation poms in the old groupId for the new artifact for any new
> artifacts for a few releases, while putting the artifacts themselves
> in the new groupId, and then stop putting the relocation poms in
> completely after some period of time.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Correcting a groupID
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 26/08/2010 8:10 AM, sebb wrote:
> On 26 August 2010 12:42, Ron Wheeler<rw...@artifact-software.com> 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by sebb <se...@gmail.com>.
On 26 August 2010 12:42, Ron Wheeler <rw...@artifact-software.com> 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.
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.
>
> Ron
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Ron Wheeler <rw...@artifact-software.com>.
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.
Ron
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Vincent Latombe <vi...@gmail.com>.
You'll need a dependencyManagement to force A to use c-n:c-n:12 which will
depends on org.apache.commons.net:c-n:12.
2010/8/26 Benson Margulies <bi...@gmail.com>
> On Thu, Aug 26, 2010 at 8:41 AM, Stephen Connolly
> <st...@gmail.com> wrote:
> > Why not have commons-net:commons-net become an empty jar which has a
> > dependency on org.apache.commons:net
> >
> > that way, anyone with the old GA coords will just have an empty jar on
> their
> > classpath and the correct jar as well
>
> i don't see it.
>
> Component A is sitting out there with a dependency on c-n:c-n:1
>
> Component B has a dependency on A and also on c-n:c-n:1
>
> Sebb changes the group ID.
>
> Now, A still depends on c-n:c-n:1
> B depends on org.apache.commons.net:c-n:12, and on A
> And we've got two dueling versions in classpath.
>
> It doesn't help to release a new version c-n:c-n:12, since A isn't
> using a range, it's pointing at '1'.
>
> Am I missing something?
>
>
>
>
>
>
> >
> > On 26 August 2010 00:13, Benson Margulies <bi...@gmail.com> 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.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Vincent
Re: Correcting a groupID
Posted by Benson Margulies <bi...@gmail.com>.
On Thu, Aug 26, 2010 at 8:41 AM, Stephen Connolly
<st...@gmail.com> wrote:
> Why not have commons-net:commons-net become an empty jar which has a
> dependency on org.apache.commons:net
>
> that way, anyone with the old GA coords will just have an empty jar on their
> classpath and the correct jar as well
i don't see it.
Component A is sitting out there with a dependency on c-n:c-n:1
Component B has a dependency on A and also on c-n:c-n:1
Sebb changes the group ID.
Now, A still depends on c-n:c-n:1
B depends on org.apache.commons.net:c-n:12, and on A
And we've got two dueling versions in classpath.
It doesn't help to release a new version c-n:c-n:12, since A isn't
using a range, it's pointing at '1'.
Am I missing something?
>
> On 26 August 2010 00:13, Benson Margulies <bi...@gmail.com> 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.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Stephen Connolly <st...@gmail.com>.
Why not have commons-net:commons-net become an empty jar which has a
dependency on org.apache.commons:net
that way, anyone with the old GA coords will just have an empty jar on their
classpath and the correct jar as well
On 26 August 2010 00:13, Benson Margulies <bi...@gmail.com> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Correcting a groupID
Posted by Benson Margulies <bi...@gmail.com>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by sebb <se...@gmail.com>.
On 25 August 2010 03:47, Wayne Fay <wa...@gmail.com> wrote:
>> If a project uses the old groupId to download the release with the new
>> groupId then it will find the relocation POM, and Maven can
>> potentially correlate the old and new groupIds. However if the project
>> uses the new groupId, the relocation POM will not necessarily be read.
>
> Realistically, people should simply expect that they will need to be a
> little bit hands-on with their pom files and dependencies -- even the
> transitive ones. Using Maven should not be viewed as entirely "free"
> -- you will occasionally need to get your hands dirty and actually
> look at the dependency graph for your artifacts.
>
> You can use dependency exclusions to eliminate unwanted artifacts
> under the "old" groupId without much trouble. You can also encourage
> your own dependencies (direct and transitive) to update to the new
> groupId the next time they push a new release etc.
Unfortunately that is not feasible in general.
>> It should also be made very clear that choosing the groupId (etc.)
>> needs to be done very carefully, as it is difficult to change later
>
> Its not so much difficult (for you) to change as it is a pain for your
> users (assuming you're a library) since they will need to use
> dependency exclusions etc.
Exactly - Commons is keen to minimise causing pain for users.
Imagine the work that would be required if Commons Logging or Lang
changed groupId.
In the case of Commons Net there are probably fewer dependencies, but
it is still a low-level library.
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Wayne Fay <wa...@gmail.com>.
> If a project uses the old groupId to download the release with the new
> groupId then it will find the relocation POM, and Maven can
> potentially correlate the old and new groupIds. However if the project
> uses the new groupId, the relocation POM will not necessarily be read.
Realistically, people should simply expect that they will need to be a
little bit hands-on with their pom files and dependencies -- even the
transitive ones. Using Maven should not be viewed as entirely "free"
-- you will occasionally need to get your hands dirty and actually
look at the dependency graph for your artifacts.
You can use dependency exclusions to eliminate unwanted artifacts
under the "old" groupId without much trouble. You can also encourage
your own dependencies (direct and transitive) to update to the new
groupId the next time they push a new release etc.
> It should also be made very clear that choosing the groupId (etc.)
> needs to be done very carefully, as it is difficult to change later
Its not so much difficult (for you) to change as it is a pain for your
users (assuming you're a library) since they will need to use
dependency exclusions etc.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by sebb <se...@gmail.com>.
On 25 August 2010 01:00, Niall Pemberton <ni...@gmail.com> wrote:
> On Tue, Aug 24, 2010 at 7:37 PM, sebb <se...@gmail.com> wrote:
>> On 24 August 2010 19:17, EJ Ciramella <ec...@casenetinc.com> wrote:
>>> No, we didn't realize the relocation poms existed until it was too late.
>>>
>>> We wanted to match up in source control/java package/groupId/artifactId so that they were uniform. Which is great because from just about any angle (stacktrace, source path, package name in IDE) you know exactly where to look elsewhere to find something (say, you wanna look at local disk or source browser, etc).
>>>
>>> The main problem was communication. There was a lot of hate mail as older modules that hadn't been touched in a long time were dredged up for something or another and when people tried to point at newer version of the relocated libraries, things were missing, etc.
>>>
>>> There were maybe, 50 or more versions for any of the moved modules floating around that all would need these silly "relocation" poms to support older builds.
>>
>> What do you mean here?
>> Are you saying that if the groupId is changed for a new release, one
>> also needs to change all existing releases to add relocation poms?
>> I thought one only had to add the relocation POMs for the new releases?
>>
>>> Everything is possible given an endless amount of time/energy/etc. We wound up having to branch things just to update groupIds, blah blah blah - it was a mess.
>>>
>>> This is a massive generalization.
>>>
>>> Keep it stupid simple, right? Don't move things around...
>>
>> I'm not proposing moving anything around; just changing the groupId
>> going forward.
>>
>> Is that likely to cause any problems?
>
> Yes - the problem is going to be users getting more than one copy of
> an artefact on their classpath. its been discussed a few times on the
> Commons dev list - I found the following thread.
>
> http://markmail.org/message/tky6c734r2dia2gd
>
> AIUI relocation can't really help with this
I think I see now.
If a project uses the old groupId to download the release with the new
groupId then it will find the relocation POM, and Maven can
potentially correlate the old and new groupIds. However if the project
uses the new groupId, the relocation POM will not necessarily be read.
Seems to me that this is a problem that Maven should solve, e.g. by
providing reverse relocation information in the poms which have the
new groupId.
That would then allow Maven to correlate the old and new Ids,
regardless of which groupId was used to reference the artifacts.
The other issue here is that the documentation does not point out
these problems, indeed appears to suggest that relocation POMs will
solve the problem.
It should also be made very clear that choosing the groupId (etc.)
needs to be done very carefully, as it is difficult to change later
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Aug 24, 2010 at 7:37 PM, sebb <se...@gmail.com> wrote:
> On 24 August 2010 19:17, EJ Ciramella <ec...@casenetinc.com> wrote:
>> No, we didn't realize the relocation poms existed until it was too late.
>>
>> We wanted to match up in source control/java package/groupId/artifactId so that they were uniform. Which is great because from just about any angle (stacktrace, source path, package name in IDE) you know exactly where to look elsewhere to find something (say, you wanna look at local disk or source browser, etc).
>>
>> The main problem was communication. There was a lot of hate mail as older modules that hadn't been touched in a long time were dredged up for something or another and when people tried to point at newer version of the relocated libraries, things were missing, etc.
>>
>> There were maybe, 50 or more versions for any of the moved modules floating around that all would need these silly "relocation" poms to support older builds.
>
> What do you mean here?
> Are you saying that if the groupId is changed for a new release, one
> also needs to change all existing releases to add relocation poms?
> I thought one only had to add the relocation POMs for the new releases?
>
>> Everything is possible given an endless amount of time/energy/etc. We wound up having to branch things just to update groupIds, blah blah blah - it was a mess.
>>
>> This is a massive generalization.
>>
>> Keep it stupid simple, right? Don't move things around...
>
> I'm not proposing moving anything around; just changing the groupId
> going forward.
>
> Is that likely to cause any problems?
Yes - the problem is going to be users getting more than one copy of
an artefact on their classpath. its been discussed a few times on the
Commons dev list - I found the following thread.
http://markmail.org/message/tky6c734r2dia2gd
AIUI relocation can't really help with this
Niall
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> Sent: Tuesday, August 24, 2010 2:08 PM
>> To: Maven Users List
>> Subject: Re: Correcting a groupID
>>
>> On 24 August 2010 18:44, EJ Ciramella <ec...@casenetinc.com> wrote:
>>> Yeah, I know - hate to cross-pollinate here but the Nexus bible states the repo is for deposits only.
>>>
>>> Essentially backing up the "just change NEW snapshots/releases, leave the old ones where they are" sentiment.
>>
>> OK
>>
>>> In another life, I casually agreed we should change the groupId of an artifact and all hell broke loose...
>>
>> Did you use relocation POMs?
>>
>> What were the exact problems?
>> Could they have been avoided, and if so, how?
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by sebb <se...@gmail.com>.
On 24 August 2010 19:17, EJ Ciramella <ec...@casenetinc.com> wrote:
> No, we didn't realize the relocation poms existed until it was too late.
>
> We wanted to match up in source control/java package/groupId/artifactId so that they were uniform. Which is great because from just about any angle (stacktrace, source path, package name in IDE) you know exactly where to look elsewhere to find something (say, you wanna look at local disk or source browser, etc).
>
> The main problem was communication. There was a lot of hate mail as older modules that hadn't been touched in a long time were dredged up for something or another and when people tried to point at newer version of the relocated libraries, things were missing, etc.
>
> There were maybe, 50 or more versions for any of the moved modules floating around that all would need these silly "relocation" poms to support older builds.
What do you mean here?
Are you saying that if the groupId is changed for a new release, one
also needs to change all existing releases to add relocation poms?
I thought one only had to add the relocation POMs for the new releases?
> Everything is possible given an endless amount of time/energy/etc. We wound up having to branch things just to update groupIds, blah blah blah - it was a mess.
>
> This is a massive generalization.
>
> Keep it stupid simple, right? Don't move things around...
I'm not proposing moving anything around; just changing the groupId
going forward.
Is that likely to cause any problems?
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Tuesday, August 24, 2010 2:08 PM
> To: Maven Users List
> Subject: Re: Correcting a groupID
>
> On 24 August 2010 18:44, EJ Ciramella <ec...@casenetinc.com> wrote:
>> Yeah, I know - hate to cross-pollinate here but the Nexus bible states the repo is for deposits only.
>>
>> Essentially backing up the "just change NEW snapshots/releases, leave the old ones where they are" sentiment.
>
> OK
>
>> In another life, I casually agreed we should change the groupId of an artifact and all hell broke loose...
>
> Did you use relocation POMs?
>
> What were the exact problems?
> Could they have been avoided, and if so, how?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Correcting a groupID
Posted by EJ Ciramella <ec...@casenetinc.com>.
No, we didn't realize the relocation poms existed until it was too late.
We wanted to match up in source control/java package/groupId/artifactId so that they were uniform. Which is great because from just about any angle (stacktrace, source path, package name in IDE) you know exactly where to look elsewhere to find something (say, you wanna look at local disk or source browser, etc).
The main problem was communication. There was a lot of hate mail as older modules that hadn't been touched in a long time were dredged up for something or another and when people tried to point at newer version of the relocated libraries, things were missing, etc.
There were maybe, 50 or more versions for any of the moved modules floating around that all would need these silly "relocation" poms to support older builds. Everything is possible given an endless amount of time/energy/etc. We wound up having to branch things just to update groupIds, blah blah blah - it was a mess.
This is a massive generalization.
Keep it stupid simple, right? Don't move things around...
-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com]
Sent: Tuesday, August 24, 2010 2:08 PM
To: Maven Users List
Subject: Re: Correcting a groupID
On 24 August 2010 18:44, EJ Ciramella <ec...@casenetinc.com> wrote:
> Yeah, I know - hate to cross-pollinate here but the Nexus bible states the repo is for deposits only.
>
> Essentially backing up the "just change NEW snapshots/releases, leave the old ones where they are" sentiment.
OK
> In another life, I casually agreed we should change the groupId of an artifact and all hell broke loose...
Did you use relocation POMs?
What were the exact problems?
Could they have been avoided, and if so, how?
>
>
> -----Original Message-----
> From: Wayne Fay [mailto:waynefay@gmail.com]
> Sent: Tuesday, August 24, 2010 11:00 AM
> To: Maven Users List
> Subject: Re: Correcting a groupID
>
>> The guide to relocation:
>>
>> http://maven.apache.org/guides/mini/guide-relocation.html
>
> Hmmmmmmm I really don't agree with this approach, and don't believe it
> would pass muster today. This documentation is most likely old.
>
> Today's mantra is "artifacts don't change". This includes poms and
> jars etc. I believe the correct approach today would be to put
> relocation poms in the old groupId for the new artifact for any new
> artifacts for a few releases, while putting the artifacts themselves
> in the new groupId, and then stop putting the relocation poms in
> completely after some period of time.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within including any attachments is only for the recipient(s) to which it is intended and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back by replying to the sender and permanently delete the entire message and its attachments from all computers and network systems involved in its receipt.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within including any attachments is only for the recipient(s) to which it is intended and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back by replying to the sender and permanently delete the entire message and its attachments from all computers and network systems involved in its receipt.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Wayne Fay <wa...@gmail.com>.
> I think the general consensus is - don't do this.
>
> Just don't.
I think its OK for a project to "move" groupIds and then use that new
groupId for all future releases. But I don't think it should ever be
OK for a project to "move" groupIds for past releases -- that breaks
the "don't ever change stuff once released" rule
Leave old stuff where it is, put relocation poms in the old place
pointing to the new stuff for a while, and put the new stuff directly
in the new place. This is how groupId should be "corrected."
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Correcting a groupID
Posted by EJ Ciramella <ec...@casenetinc.com>.
I think the general consensus is - don't do this.
Just don't.
(that "move" is moving from one repository to another, not moving groupIds btw - my bad - but I coulda sworn they do offer a move feature)
-----Original Message-----
From: anders.g.hammar@gmail.com [mailto:anders.g.hammar@gmail.com] On Behalf Of Anders Hammar
Sent: Tuesday, August 24, 2010 4:07 PM
To: Maven Users List
Subject: Re: Correcting a groupID
I'm wondering how they handle the pgp signatures. If the groupId changes,
the pom changes, and then the signature won't be correct.
I would never mess with old releases.
/Anders
On Tue, Aug 24, 2010 at 20:27, EJ Ciramella <ec...@casenetinc.com>wrote:
> Additionally, when I was done crying myself to sleep over this failure, I
> went in search of a repo manager that allowed an easy way to do this in the
> future:
>
> http://wiki.jfrog.org/confluence/display/RTF/Moving+Artifacts
>
> But I'm sticking with Nexus until it bites me...
>
>
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Tuesday, August 24, 2010 2:08 PM
> To: Maven Users List
> Subject: Re: Correcting a groupID
>
> On 24 August 2010 18:44, EJ Ciramella <ec...@casenetinc.com> wrote:
> > Yeah, I know - hate to cross-pollinate here but the Nexus bible states
> the repo is for deposits only.
> >
> > Essentially backing up the "just change NEW snapshots/releases, leave the
> old ones where they are" sentiment.
>
> OK
>
> > In another life, I casually agreed we should change the groupId of an
> artifact and all hell broke loose...
>
> Did you use relocation POMs?
>
> What were the exact problems?
> Could they have been avoided, and if so, how?
>
> >
> >
> > -----Original Message-----
> > From: Wayne Fay [mailto:waynefay@gmail.com]
> > Sent: Tuesday, August 24, 2010 11:00 AM
> > To: Maven Users List
> > Subject: Re: Correcting a groupID
> >
> >> The guide to relocation:
> >>
> >> http://maven.apache.org/guides/mini/guide-relocation.html
> >
> > Hmmmmmmm I really don't agree with this approach, and don't believe it
> > would pass muster today. This documentation is most likely old.
> >
> > Today's mantra is "artifacts don't change". This includes poms and
> > jars etc. I believe the correct approach today would be to put
> > relocation poms in the old groupId for the new artifact for any new
> > artifacts for a few releases, while putting the artifacts themselves
> > in the new groupId, and then stop putting the relocation poms in
> > completely after some period of time.
> >
> > Wayne
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > CONFIDENTIALITY NOTICE: This e-mail and the information transmitted
> within including any attachments is only for the recipient(s) to which it is
> intended and may contain confidential and/or privileged material. Any
> review, retransmission, dissemination or other use of; or taking of any
> action in reliance upon this information by persons or entities other than
> the intended recipient is prohibited. If you received this in error, please
> send the e-mail back by replying to the sender and permanently delete the
> entire message and its attachments from all computers and network systems
> involved in its receipt.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within
> including any attachments is only for the recipient(s) to which it is
> intended and may contain confidential and/or privileged material. Any
> review, retransmission, dissemination or other use of; or taking of any
> action in reliance upon this information by persons or entities other than
> the intended recipient is prohibited. If you received this in error, please
> send the e-mail back by replying to the sender and permanently delete the
> entire message and its attachments from all computers and network systems
> involved in its receipt.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within including any attachments is only for the recipient(s) to which it is intended and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back by replying to the sender and permanently delete the entire message and its attachments from all computers and network systems involved in its receipt.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Anders Hammar <an...@hammar.net>.
I'm wondering how they handle the pgp signatures. If the groupId changes,
the pom changes, and then the signature won't be correct.
I would never mess with old releases.
/Anders
On Tue, Aug 24, 2010 at 20:27, EJ Ciramella <ec...@casenetinc.com>wrote:
> Additionally, when I was done crying myself to sleep over this failure, I
> went in search of a repo manager that allowed an easy way to do this in the
> future:
>
> http://wiki.jfrog.org/confluence/display/RTF/Moving+Artifacts
>
> But I'm sticking with Nexus until it bites me...
>
>
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Tuesday, August 24, 2010 2:08 PM
> To: Maven Users List
> Subject: Re: Correcting a groupID
>
> On 24 August 2010 18:44, EJ Ciramella <ec...@casenetinc.com> wrote:
> > Yeah, I know - hate to cross-pollinate here but the Nexus bible states
> the repo is for deposits only.
> >
> > Essentially backing up the "just change NEW snapshots/releases, leave the
> old ones where they are" sentiment.
>
> OK
>
> > In another life, I casually agreed we should change the groupId of an
> artifact and all hell broke loose...
>
> Did you use relocation POMs?
>
> What were the exact problems?
> Could they have been avoided, and if so, how?
>
> >
> >
> > -----Original Message-----
> > From: Wayne Fay [mailto:waynefay@gmail.com]
> > Sent: Tuesday, August 24, 2010 11:00 AM
> > To: Maven Users List
> > Subject: Re: Correcting a groupID
> >
> >> The guide to relocation:
> >>
> >> http://maven.apache.org/guides/mini/guide-relocation.html
> >
> > Hmmmmmmm I really don't agree with this approach, and don't believe it
> > would pass muster today. This documentation is most likely old.
> >
> > Today's mantra is "artifacts don't change". This includes poms and
> > jars etc. I believe the correct approach today would be to put
> > relocation poms in the old groupId for the new artifact for any new
> > artifacts for a few releases, while putting the artifacts themselves
> > in the new groupId, and then stop putting the relocation poms in
> > completely after some period of time.
> >
> > Wayne
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > CONFIDENTIALITY NOTICE: This e-mail and the information transmitted
> within including any attachments is only for the recipient(s) to which it is
> intended and may contain confidential and/or privileged material. Any
> review, retransmission, dissemination or other use of; or taking of any
> action in reliance upon this information by persons or entities other than
> the intended recipient is prohibited. If you received this in error, please
> send the e-mail back by replying to the sender and permanently delete the
> entire message and its attachments from all computers and network systems
> involved in its receipt.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within
> including any attachments is only for the recipient(s) to which it is
> intended and may contain confidential and/or privileged material. Any
> review, retransmission, dissemination or other use of; or taking of any
> action in reliance upon this information by persons or entities other than
> the intended recipient is prohibited. If you received this in error, please
> send the e-mail back by replying to the sender and permanently delete the
> entire message and its attachments from all computers and network systems
> involved in its receipt.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Correcting a groupID
Posted by EJ Ciramella <ec...@casenetinc.com>.
Additionally, when I was done crying myself to sleep over this failure, I went in search of a repo manager that allowed an easy way to do this in the future:
http://wiki.jfrog.org/confluence/display/RTF/Moving+Artifacts
But I'm sticking with Nexus until it bites me...
-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com]
Sent: Tuesday, August 24, 2010 2:08 PM
To: Maven Users List
Subject: Re: Correcting a groupID
On 24 August 2010 18:44, EJ Ciramella <ec...@casenetinc.com> wrote:
> Yeah, I know - hate to cross-pollinate here but the Nexus bible states the repo is for deposits only.
>
> Essentially backing up the "just change NEW snapshots/releases, leave the old ones where they are" sentiment.
OK
> In another life, I casually agreed we should change the groupId of an artifact and all hell broke loose...
Did you use relocation POMs?
What were the exact problems?
Could they have been avoided, and if so, how?
>
>
> -----Original Message-----
> From: Wayne Fay [mailto:waynefay@gmail.com]
> Sent: Tuesday, August 24, 2010 11:00 AM
> To: Maven Users List
> Subject: Re: Correcting a groupID
>
>> The guide to relocation:
>>
>> http://maven.apache.org/guides/mini/guide-relocation.html
>
> Hmmmmmmm I really don't agree with this approach, and don't believe it
> would pass muster today. This documentation is most likely old.
>
> Today's mantra is "artifacts don't change". This includes poms and
> jars etc. I believe the correct approach today would be to put
> relocation poms in the old groupId for the new artifact for any new
> artifacts for a few releases, while putting the artifacts themselves
> in the new groupId, and then stop putting the relocation poms in
> completely after some period of time.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within including any attachments is only for the recipient(s) to which it is intended and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back by replying to the sender and permanently delete the entire message and its attachments from all computers and network systems involved in its receipt.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within including any attachments is only for the recipient(s) to which it is intended and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back by replying to the sender and permanently delete the entire message and its attachments from all computers and network systems involved in its receipt.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by sebb <se...@gmail.com>.
On 24 August 2010 18:44, EJ Ciramella <ec...@casenetinc.com> wrote:
> Yeah, I know - hate to cross-pollinate here but the Nexus bible states the repo is for deposits only.
>
> Essentially backing up the "just change NEW snapshots/releases, leave the old ones where they are" sentiment.
OK
> In another life, I casually agreed we should change the groupId of an artifact and all hell broke loose...
Did you use relocation POMs?
What were the exact problems?
Could they have been avoided, and if so, how?
>
>
> -----Original Message-----
> From: Wayne Fay [mailto:waynefay@gmail.com]
> Sent: Tuesday, August 24, 2010 11:00 AM
> To: Maven Users List
> Subject: Re: Correcting a groupID
>
>> The guide to relocation:
>>
>> http://maven.apache.org/guides/mini/guide-relocation.html
>
> Hmmmmmmm I really don't agree with this approach, and don't believe it
> would pass muster today. This documentation is most likely old.
>
> Today's mantra is "artifacts don't change". This includes poms and
> jars etc. I believe the correct approach today would be to put
> relocation poms in the old groupId for the new artifact for any new
> artifacts for a few releases, while putting the artifacts themselves
> in the new groupId, and then stop putting the relocation poms in
> completely after some period of time.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within including any attachments is only for the recipient(s) to which it is intended and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back by replying to the sender and permanently delete the entire message and its attachments from all computers and network systems involved in its receipt.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Correcting a groupID
Posted by EJ Ciramella <ec...@casenetinc.com>.
Yeah, I know - hate to cross-pollinate here but the Nexus bible states the repo is for deposits only.
Essentially backing up the "just change NEW snapshots/releases, leave the old ones where they are" sentiment.
In another life, I casually agreed we should change the groupId of an artifact and all hell broke loose...
-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com]
Sent: Tuesday, August 24, 2010 11:00 AM
To: Maven Users List
Subject: Re: Correcting a groupID
> The guide to relocation:
>
> http://maven.apache.org/guides/mini/guide-relocation.html
Hmmmmmmm I really don't agree with this approach, and don't believe it
would pass muster today. This documentation is most likely old.
Today's mantra is "artifacts don't change". This includes poms and
jars etc. I believe the correct approach today would be to put
relocation poms in the old groupId for the new artifact for any new
artifacts for a few releases, while putting the artifacts themselves
in the new groupId, and then stop putting the relocation poms in
completely after some period of time.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within including any attachments is only for the recipient(s) to which it is intended and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back by replying to the sender and permanently delete the entire message and its attachments from all computers and network systems involved in its receipt.
Re: Correcting a groupID
Posted by sebb <se...@gmail.com>.
On 24 August 2010 16:00, Wayne Fay <wa...@gmail.com> wrote:
>> The guide to relocation:
>>
>> http://maven.apache.org/guides/mini/guide-relocation.html
>
> Hmmmmmmm I really don't agree with this approach, and don't believe it
> would pass muster today. This documentation is most likely old.
Maybe so, but that is the link I was given earlier in the thread.
> Today's mantra is "artifacts don't change". This includes poms and
> jars etc. I believe the correct approach today would be to put
> relocation poms in the old groupId for the new artifact for any new
> artifacts for a few releases, while putting the artifacts themselves
> in the new groupId, and then stop putting the relocation poms in
> completely after some period of time.
Seems sensible to me, but that is not what the "official"
documentation currently says.
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-08-24 17:00, Wayne Fay wrote:
>> The guide to relocation:
>>
>> http://maven.apache.org/guides/mini/guide-relocation.html
>
> Hmmmmmmm I really don't agree with this approach, and don't believe it
> would pass muster today. This documentation is most likely old.
>
> Today's mantra is "artifacts don't change". This includes poms and
> jars etc. I believe the correct approach today would be to put
> relocation poms in the old groupId for the new artifact for any new
> artifacts for a few releases, while putting the artifacts themselves
> in the new groupId, and then stop putting the relocation poms in
> completely after some period of time.
Yes, we need to update the documentation.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Wayne Fay <wa...@gmail.com>.
> The guide to relocation:
>
> http://maven.apache.org/guides/mini/guide-relocation.html
Hmmmmmmm I really don't agree with this approach, and don't believe it
would pass muster today. This documentation is most likely old.
Today's mantra is "artifacts don't change". This includes poms and
jars etc. I believe the correct approach today would be to put
relocation poms in the old groupId for the new artifact for any new
artifacts for a few releases, while putting the artifacts themselves
in the new groupId, and then stop putting the relocation poms in
completely after some period of time.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Correcting a groupID
Posted by EJ Ciramella <ec...@casenetinc.com>.
<snip>
That is definitely NOT the way to handle it. Once released, artifacts
(including pom files) must not change. Why do you think this
should/must be done?? Is it merely a poor assumption on your part, or
were you told this or read it somewhere?
</snip>
I too have read these EXACT steps before.
The guide to relocation:
http://maven.apache.org/guides/mini/guide-relocation.html
and here:
http://maven.apache.org/ref/2.2.1/maven-model/maven.html#class_relocation
"Describes where an artifact has moved to."
-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com]
Sent: Tuesday, August 24, 2010 9:35 AM
To: Maven Users List
Subject: Re: Correcting a groupID
> # Copy all foo-related files from /bar/foo/ in your Maven 2 repository
> to a temporary location.
> # Change the groupId to org.bar in all foo-related pom files in the
> temporary location.
> # Copy all files from the temporary location to /org/bar/foo/ in your
> Maven 2 repository.
> # Create a minimal Maven 2 pom file for every old release of foo in
> your Maven 2 repository.
That is definitely NOT the way to handle it. Once released, artifacts
(including pom files) must not change. Why do you think this
should/must be done?? Is it merely a poor assumption on your part, or
were you told this or read it somewhere?
You simply leave the old files where they are. And slowly migrate to
the new groupId, just as you were previously told, by using the
relocation poms for new releases in the old groupId and then actually
pushing the new artifacts and poms to the new groupId.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within including any attachments is only for the recipient(s) to which it is intended and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back by replying to the sender and permanently delete the entire message and its attachments from all computers and network systems involved in its receipt.
Re: Correcting a groupID
Posted by Wayne Fay <wa...@gmail.com>.
> # Copy all foo-related files from /bar/foo/ in your Maven 2 repository
> to a temporary location.
> # Change the groupId to org.bar in all foo-related pom files in the
> temporary location.
> # Copy all files from the temporary location to /org/bar/foo/ in your
> Maven 2 repository.
> # Create a minimal Maven 2 pom file for every old release of foo in
> your Maven 2 repository.
That is definitely NOT the way to handle it. Once released, artifacts
(including pom files) must not change. Why do you think this
should/must be done?? Is it merely a poor assumption on your part, or
were you told this or read it somewhere?
You simply leave the old files where they are. And slowly migrate to
the new groupId, just as you were previously told, by using the
relocation poms for new releases in the old groupId and then actually
pushing the new artifacts and poms to the new groupId.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by sebb <se...@gmail.com>.
On 24 August 2010 08:34, Baptiste MATHUS <ml...@batmat.net> wrote:
> 2010/8/23 sebb <se...@gmail.com>
>
>> 2010/8/23 Arnaud Héritier <ah...@gmail.com>:
>> > I think it could help you :
>> > http://maven.apache.org/guides/mini/guide-relocation.html
>>
>> Thanks - but it does not really cover the Apache case where a shared
>> repo is used.
>
>
> Sorry. I don't know Apache infra well, but I don't understand why the
> relocation won't suit your needs. Could you clarify?
>
> The principle is simple :
> * change whatever you want in your pom groupId/artifactId
> * publish both the resulting new artifact, and only a pom in the old place,
> so that maven will find it, display a warning and continue gracefully.
> * Do that for two or three releases for examples, to give users time to
> update
> * Finally, continue releasing on the new place, and no more in the old one.
That makes sense, however as I read it one also has to do the following:
# Copy all foo-related files from /bar/foo/ in your Maven 2 repository
to a temporary location.
# Change the groupId to org.bar in all foo-related pom files in the
temporary location.
# Copy all files from the temporary location to /org/bar/foo/ in your
Maven 2 repository.
# Create a minimal Maven 2 pom file for every old release of foo in
your Maven 2 repository.
etc.
before the steps that you suggest.
This would be difficult / tedious with Nexus, as it would mean
registering the old groupId as well as the new one.
Are those steps really necessary?
If not, why are they documented?
> Cheers
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Baptiste MATHUS <ml...@batmat.net>.
2010/8/23 sebb <se...@gmail.com>
> 2010/8/23 Arnaud Héritier <ah...@gmail.com>:
> > I think it could help you :
> > http://maven.apache.org/guides/mini/guide-relocation.html
>
> Thanks - but it does not really cover the Apache case where a shared
> repo is used.
Sorry. I don't know Apache infra well, but I don't understand why the
relocation won't suit your needs. Could you clarify?
The principle is simple :
* change whatever you want in your pom groupId/artifactId
* publish both the resulting new artifact, and only a pom in the old place,
so that maven will find it, display a warning and continue gracefully.
* Do that for two or three releases for examples, to give users time to
update
* Finally, continue releasing on the new place, and no more in the old one.
Cheers
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: Correcting a groupID
Posted by sebb <se...@gmail.com>.
2010/8/23 Arnaud Héritier <ah...@gmail.com>:
> I think it could help you :
> http://maven.apache.org/guides/mini/guide-relocation.html
Thanks - but it does not really cover the Apache case where a shared
repo is used.
> Cheers
>
> Arnaud
>
> On Aug 23, 2010, at 2:20 PM, sebb wrote:
>
>> Apache Commons NET currently uses the groupId commons-net. However, it
>> should really use the groupId org.apache.commons.
>>
>> Is it possible to set up the Maven repos so that this change is
>> transparent to users?
>>
>> Or does changing a groupId necessarily involve change for end-users?
>>
>> ==
>>
>> AIUI, a redirect pom can be created, which will cause references to
>> commons-net to be seen as org.apache.commons, at least when
>> downloading.
>>
>> For example:
>> NET 2.0 groupId = commons-net
>> Create NET 2.x with groupId org.apache.commons
>>
>> Then a project that references commons-net:commons-net:2.x will
>> download org.apache.commons:commons-net:2.x
>> (though there will be a warning logged)
>>
>> [For example, see JDom 1.1, which changed groupId jdom => org.jdom]
>>
>> However, what happens if a project has (transitive) dependencies on
>> both versions of Net?
>> Does Maven know how to resolve these correctly so that only the 2.x
>> release of Net is used?
>>
>> Or is it necessary to change the Net package name in order to avoid conflict?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Arnaud Héritier <ah...@gmail.com>.
I think it could help you :
http://maven.apache.org/guides/mini/guide-relocation.html
Cheers
Arnaud
On Aug 23, 2010, at 2:20 PM, sebb wrote:
> Apache Commons NET currently uses the groupId commons-net. However, it
> should really use the groupId org.apache.commons.
>
> Is it possible to set up the Maven repos so that this change is
> transparent to users?
>
> Or does changing a groupId necessarily involve change for end-users?
>
> ==
>
> AIUI, a redirect pom can be created, which will cause references to
> commons-net to be seen as org.apache.commons, at least when
> downloading.
>
> For example:
> NET 2.0 groupId = commons-net
> Create NET 2.x with groupId org.apache.commons
>
> Then a project that references commons-net:commons-net:2.x will
> download org.apache.commons:commons-net:2.x
> (though there will be a warning logged)
>
> [For example, see JDom 1.1, which changed groupId jdom => org.jdom]
>
> However, what happens if a project has (transitive) dependencies on
> both versions of Net?
> Does Maven know how to resolve these correctly so that only the 2.x
> release of Net is used?
>
> Or is it necessary to change the Net package name in order to avoid conflict?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by sebb <se...@gmail.com>.
On 23 August 2010 16:07, Brian Fox <br...@infinity.nu> wrote:
> The relocation poms will help prevent collisions of different
> versions,
"Help prevent collisions" - is the collision detection the same, or is
it weakened by the change of groupId?
i.e. suppose one releases Net 2.2 as groupId org.apache.commons, would
the collision detection work the same as if Net 2.2 had stayed with
groupId commons-net?
> but eventually the users would want to update to the new
> groupId.
That's to be expected and acceptable - it is an optional step.
> On Mon, Aug 23, 2010 at 8:20 AM, sebb <se...@gmail.com> wrote:
>> Apache Commons NET currently uses the groupId commons-net. However, it
>> should really use the groupId org.apache.commons.
>>
>> Is it possible to set up the Maven repos so that this change is
>> transparent to users?
>>
>> Or does changing a groupId necessarily involve change for end-users?
>>
>> ==
>>
>> AIUI, a redirect pom can be created, which will cause references to
>> commons-net to be seen as org.apache.commons, at least when
>> downloading.
>>
>> For example:
>> NET 2.0 groupId = commons-net
>> Create NET 2.x with groupId org.apache.commons
>>
>> Then a project that references commons-net:commons-net:2.x will
>> download org.apache.commons:commons-net:2.x
>> (though there will be a warning logged)
>>
>> [For example, see JDom 1.1, which changed groupId jdom => org.jdom]
>>
>> However, what happens if a project has (transitive) dependencies on
>> both versions of Net?
>> Does Maven know how to resolve these correctly so that only the 2.x
>> release of Net is used?
>>
>> Or is it necessary to change the Net package name in order to avoid conflict?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Correcting a groupID
Posted by Brian Fox <br...@infinity.nu>.
The relocation poms will help prevent collisions of different
versions, but eventually the users would want to update to the new
groupId.
On Mon, Aug 23, 2010 at 8:20 AM, sebb <se...@gmail.com> wrote:
> Apache Commons NET currently uses the groupId commons-net. However, it
> should really use the groupId org.apache.commons.
>
> Is it possible to set up the Maven repos so that this change is
> transparent to users?
>
> Or does changing a groupId necessarily involve change for end-users?
>
> ==
>
> AIUI, a redirect pom can be created, which will cause references to
> commons-net to be seen as org.apache.commons, at least when
> downloading.
>
> For example:
> NET 2.0 groupId = commons-net
> Create NET 2.x with groupId org.apache.commons
>
> Then a project that references commons-net:commons-net:2.x will
> download org.apache.commons:commons-net:2.x
> (though there will be a warning logged)
>
> [For example, see JDom 1.1, which changed groupId jdom => org.jdom]
>
> However, what happens if a project has (transitive) dependencies on
> both versions of Net?
> Does Maven know how to resolve these correctly so that only the 2.x
> release of Net is used?
>
> Or is it necessary to change the Net package name in order to avoid conflict?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org