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
> On Thu, Aug 26, 2010 at 8:41 AM, Stephen Connolly
> wrote:
> > Why not have commons-net:commons-net become an empty jar which has a
> > dependency on
On Thu, Aug 26, 2010 at 8:41 AM, Stephen Connolly
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 s
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 wrote:
> Let me recap the pain s
On 26/08/2010 8:10 AM, sebb wrote:
On 26 August 2010 12:42, Ron Wheeler 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.
Dependen
On 26 August 2010 12:42, Ron Wheeler 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
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, s
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
On 25 August 2010 03:47, Wayne Fay 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 w
> 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, pe
On 25 August 2010 01:00, Niall Pemberton wrote:
> On Tue, Aug 24, 2010 at 7:37 PM, sebb wrote:
>> On 24 August 2010 19:17, EJ Ciramella 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/artifac
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
On 2010-08-24 17:00, Wayne Fay wrote:
>> The guide to relocation:
>>
>> http://maven.apache.org/guides/mini/guide-relocation.html
>
> Hmmm 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 "art
> 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
s.g.ham...@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 woul
> From: sebb [mailto:seb...@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 wrote:
> > Yeah, I know - hate to cross-pollinate here but the Nexus bible states
> the repo i
.
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:seb...@gmail.com]
> Sent: Tuesday, August 24, 2010 2:08 PM
> To: Maven Users List
> Subject: Re: Correcting
ssage-
From: sebb [mailto:seb...@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 wrote:
> Yeah, I know - hate to cross-pollinate here but the Nexus bible states the
> repo is for de
4, 2010 2:08 PM
To: Maven Users List
Subject: Re: Correcting a groupID
On 24 August 2010 18:44, EJ Ciramella 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/
wayne...@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
>
> Hmmm I really don't agree with this
n artifact
and all hell broke loose...
-Original Message-
From: Wayne Fay [mailto:wayne...@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-relocati
On 24 August 2010 16:00, Wayne Fay wrote:
>> The guide to relocation:
>>
>> http://maven.apache.org/guides/mini/guide-relocation.html
>
> Hmmm 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 guide to relocation:
>
> http://maven.apache.org/guides/mini/guide-relocation.html
Hmmm 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 e
t: 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 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
On 24 August 2010 08:34, Baptiste MATHUS wrote:
> 2010/8/23 sebb
>
>> 2010/8/23 Arnaud Héritier :
>> > 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
2010/8/23 sebb
> 2010/8/23 Arnaud Héritier :
> > 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 t
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
On 23 August 2010 15:28, Wayne Fay 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 troub
2010/8/23 Arnaud Héritier :
> 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 current
On 23 August 2010 16:07, Brian Fox 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, woul
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 wrote:
> Apache Commons NET currently uses the groupId commons-net. However, it
> should really use the groupId org.apach
> 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
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 u
33 matches
Mail list logo
