You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Geoffrey De Smet <ge...@gmail.com> on 2011/01/18 08:58:01 UTC

Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

Hi,

We have a pom.xml for the drools guvnor repository jar, with this 
identification:

<groupId>org.drools</groupId>
<artifactId>drools-repository</artifactId>
<version>5.1.0</version>

Now, for the next version of that jar, we need to change the 
identification to:

<groupId>org.drools.guvnor</groupId>
<artifactId>guvnor-repository</artifactId>
<version>5.2.0</version>

It's the same code in the jar, but the original identification was wrong 
and we're fixing that now.
The problem is, what happens if one of our users has this dependency tree?
- foo
-- foo depends on bar
--- bar depends on org.drools:drools-repository:5.1.0
-- foo depends on org.drools.guvnor:guvnor-repository:5.2.0

Maven will not detect the dependency conflict between
- org.drools:drools-repository:5.1.0
- org.drools.guvnor:guvnor-repository:5.2.0
and it will put both of them in the classpath, instead of just 5.2.0.

Is there any way to tell maven in the 5.2.0 pom.xml, something like this:
<groupId>org.drools.guvnor</groupId>
<artifactId>guvnor-repository</artifactId>
<version>5.2.0</version>
<legacy-identifications>
<legacy-identification>
<groupId>org.drools</groupId>
<artifactId>drools-repository</artifactId>
<legacy-identification>
</legacy-identifications>
So it does detect the dependency conflict and lets just 5.2.0 survive?

-- 
With kind regards,
Geoffrey De Smet



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

Posted by Jörg Schaible <jo...@scalaris.com>.
Hi Geoffry,

Geoffrey De Smet wrote:

> I agree that a global relocations.xml would not scale.
> You can't change the old (5.1.0) pom,
> so the most obvious place is simply adding this meta-data in the new pom
> (5.2.0):
> 
> <groupId>org.drools.guvnor</groupId>
> <artifactId>guvnor-repository</artifactId>
> <version>5.2.0</version>
> 
> <legacy-identifications>
> <legacy-identification>
> <groupId>org.drools</groupId>
> <artifactId>drools-repository</artifactId>
> <legacy-identification>
> </legacy-identifications>
> 
> Then maven knows that guvnor-repository conflicts with drools-repository.
> 
> Exclusions are a mess, in my opinion they are evil (even though I use
> them myself).
> Here's why: you add an exclusion today (after getting hurt because you
> didn't)
> - because of dependency bar forget to declare X as optional
> - because you don't want the transitive dependency drools-repository,
> because you got the newer guvnor-repository
> but tomorrow, when you upgrade to the next version of bar,
> you don't touch the exclusions because if you remove one and the build
> succeeds, it might still be luck (because the classpath order puts
> guvnor-repository 5.2.0 first on your machine).
> So you leave the exclusions in there... even though they might not be
> needed any more.
> 
> A couple of years down the line and you get a build pom.xml like ours :)

Actually I'd like to have a replacements section in the depMgmt to define 
something like:

<depMgmt>
  <replacements>
    <replacement>
      <replace>
        <groupId>org.ow2.spec.ee</groupId>
        <artifactId>ow2-atinject-1.0-spec</artifactId>
        <!-- possible classifier -->
      </replace>
      <with>
        <groupId>javax.inject</groupId>
        <artifactId>javax.inject</artifactId>
        <!-- possible classifier -->
      </with>
    </replacement>
    <replacement>
      <replace>
        <groupId>javax.activation</groupId>
        <artifactId>activation</artifactId>
      </replace>
      <with /> <!-- part of JDK now -->
    </replacement>
  </replacements>
</depMgmt>

Like the dependency definitions, the replacements would also be applied for 
transitive deps. Especially for someone developing with JSF this would be a 
life saver looking at the dependency mess in this area.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

Posted by Ron Wheeler <rw...@artifact-software.com>.
On 19/01/2011 4:14 AM, Geoffrey De Smet wrote:
> I agree that a global relocations.xml would not scale.
> You can't change the old (5.1.0) pom,
> so the most obvious place is simply adding this meta-data in the new 
> pom (5.2.0):
>
> <groupId>org.drools.guvnor</groupId>
> <artifactId>guvnor-repository</artifactId>
> <version>5.2.0</version>
>
> <legacy-identifications>
> <legacy-identification>
> <groupId>org.drools</groupId>
> <artifactId>drools-repository</artifactId>
> <legacy-identification>
> </legacy-identifications>
>
> Then maven knows that guvnor-repository conflicts with drools-repository.
>
> Exclusions are a mess, in my opinion they are evil (even though I use 
> them myself).
> Here's why: you add an exclusion today (after getting hurt because you 
> didn't)
> - because of dependency bar forget to declare X as optional
> - because you don't want the transitive dependency drools-repository, 
> because you got the newer guvnor-repository
> but tomorrow, when you upgrade to the next version of bar,
> you don't touch the exclusions because if you remove one and the build 
> succeeds, it might still be luck (because the classpath order puts 
> guvnor-repository 5.2.0 first on your machine).
> So you leave the exclusions in there... even though they might not be 
> needed any more.
>
Solution(for those who have heard this before, ignore the following):
1) Build aggregation POMs for all third party libraries.
2) Projects do not have third party libraries in their dependencies.

Simple. Libraries under control and planned in advance.
No nasty surprises later.

Ron


> A couple of years down the line and you get a build pom.xml like ours :)
>
> Op 18-01-11 18:32, Wayne Fay schreef:
>>> There should be some support for changing the GA.
>>> Getting it right immediately, forever in the beginning is not 
>>> realistic.
>> But how would you implement this? The only way I can think off the top
>> of my head is a global relocations.xml that is stored in Central and
>> is somehow used to manage these moves. But that gets ugly very
>> quickly. And no one really wants to manage that file.
>>
>> No, I think the current approach is the most sane one. People using
>> Maven for their builds should be expected to know what their
>> dependencies (including transitives) are, and manage these kinds of
>> changes with exclusions etc.
>>
>> Wayne
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

Posted by Geoffrey De Smet <ge...@gmail.com>.
I agree that a global relocations.xml would not scale.
You can't change the old (5.1.0) pom,
so the most obvious place is simply adding this meta-data in the new pom 
(5.2.0):

<groupId>org.drools.guvnor</groupId>
<artifactId>guvnor-repository</artifactId>
<version>5.2.0</version>

<legacy-identifications>
<legacy-identification>
<groupId>org.drools</groupId>
<artifactId>drools-repository</artifactId>
<legacy-identification>
</legacy-identifications>

Then maven knows that guvnor-repository conflicts with drools-repository.

Exclusions are a mess, in my opinion they are evil (even though I use 
them myself).
Here's why: you add an exclusion today (after getting hurt because you 
didn't)
- because of dependency bar forget to declare X as optional
- because you don't want the transitive dependency drools-repository, 
because you got the newer guvnor-repository
but tomorrow, when you upgrade to the next version of bar,
you don't touch the exclusions because if you remove one and the build 
succeeds, it might still be luck (because the classpath order puts 
guvnor-repository 5.2.0 first on your machine).
So you leave the exclusions in there... even though they might not be 
needed any more.

A couple of years down the line and you get a build pom.xml like ours :)

Op 18-01-11 18:32, Wayne Fay schreef:
>> There should be some support for changing the GA.
>> Getting it right immediately, forever in the beginning is not realistic.
> But how would you implement this? The only way I can think off the top
> of my head is a global relocations.xml that is stored in Central and
> is somehow used to manage these moves. But that gets ugly very
> quickly. And no one really wants to manage that file.
>
> No, I think the current approach is the most sane one. People using
> Maven for their builds should be expected to know what their
> dependencies (including transitives) are, and manage these kinds of
> changes with exclusions etc.
>
> Wayne

-- 
With kind regards,
Geoffrey De Smet



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

Posted by Wayne Fay <wa...@gmail.com>.
> There should be some support for changing the GA.
> Getting it right immediately, forever in the beginning is not realistic.

But how would you implement this? The only way I can think off the top
of my head is a global relocations.xml that is stored in Central and
is somehow used to manage these moves. But that gets ugly very
quickly. And no one really wants to manage that file.

No, I think the current approach is the most sane one. People using
Maven for their builds should be expected to know what their
dependencies (including transitives) are, and manage these kinds of
changes with exclusions etc.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

Posted by Geoffrey De Smet <ge...@gmail.com>.
There should be some support for changing the GA.
Getting it right immediately, forever in the beginning is not realistic.
Projects names change (hudson -> jenkins, drools-solver -> 
drools-planner), and subprojects graduate away from their parent project 
(turbine-maven -> maven).
There are plenty of big projects that changed their GA's.

Even though we will boradcast it to our users (and hopefully a good 
percentage will hear it),
it will not prevent this scenario for the developers on foo, which are 
not the developers or bar or drools:

- foo
-- foo depends on bar
--- bar depends on org.drools:drools-repository:5.1.0
-- foo depends on org.drools.guvnor:guvnor-repository:5.2.0



Op 18-01-11 10:29, Anders Hammar schreef:
> All this emphasizes how important it is to get the GA right in the
> beginning. As long as no one depends on your artifacts it's not a big deal,
> but when you have lots of users you will cause issues.
>
> If you absolutely do need to change GA, you must broadcast this to your
> users very clearly! The issues that could arise are not easily
> understandable, IMHO, to the normal devs just using Maven as a magic
> dependency management tool.
>
> /Anders
>
> On Tue, Jan 18, 2011 at 09:04, Stephen Connolly<
> stephen.alan.connolly@gmail.com>  wrote:
>
>> The closest you will get is to deploy a relocation pom at the old GA
>> with the new V., e.g. at
>>
>> <groupId>org.drools</groupId>
>> <artifactId>drools-repository</artifactId>
>> <version>5.2.0</version>
>>
>> it's not perfect (i.e. it will only notify people using ranges.... and
>> only fools use ranges!) and it does not do exactly what you want, but
>> it will at least give a bit more of a hint.
>>
>> I should probably add some goals to v-m-p to help trace relocation
>> poms and add exclusions for the old locations to the tree
>>
>> -Stephen
>>
>> On 18 January 2011 07:58, Geoffrey De Smet<ge...@gmail.com>
>> wrote:
>>> Hi,
>>>
>>> We have a pom.xml for the drools guvnor repository jar, with this
>>> identification:
>>>
>>> <groupId>org.drools</groupId>
>>> <artifactId>drools-repository</artifactId>
>>> <version>5.1.0</version>
>>>
>>> Now, for the next version of that jar, we need to change the
>> identification
>>> to:
>>>
>>> <groupId>org.drools.guvnor</groupId>
>>> <artifactId>guvnor-repository</artifactId>
>>> <version>5.2.0</version>
>>>
>>> It's the same code in the jar, but the original identification was wrong
>> and
>>> we're fixing that now.
>>> The problem is, what happens if one of our users has this dependency
>> tree?
>>> - foo
>>> -- foo depends on bar
>>> --- bar depends on org.drools:drools-repository:5.1.0
>>> -- foo depends on org.drools.guvnor:guvnor-repository:5.2.0
>>>
>>> Maven will not detect the dependency conflict between
>>> - org.drools:drools-repository:5.1.0
>>> - org.drools.guvnor:guvnor-repository:5.2.0
>>> and it will put both of them in the classpath, instead of just 5.2.0.
>>>
>>> Is there any way to tell maven in the 5.2.0 pom.xml, something like this:
>>> <groupId>org.drools.guvnor</groupId>
>>> <artifactId>guvnor-repository</artifactId>
>>> <version>5.2.0</version>
>>> <legacy-identifications>
>>> <legacy-identification>
>>> <groupId>org.drools</groupId>
>>> <artifactId>drools-repository</artifactId>
>>> <legacy-identification>
>>> </legacy-identifications>
>>> So it does detect the dependency conflict and lets just 5.2.0 survive?
>>>
>>> --
>>> With kind regards,
>>> Geoffrey De Smet
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>

-- 
With kind regards,
Geoffrey De Smet



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

Posted by Anders Hammar <an...@hammar.net>.
All this emphasizes how important it is to get the GA right in the
beginning. As long as no one depends on your artifacts it's not a big deal,
but when you have lots of users you will cause issues.

If you absolutely do need to change GA, you must broadcast this to your
users very clearly! The issues that could arise are not easily
understandable, IMHO, to the normal devs just using Maven as a magic
dependency management tool.

/Anders

On Tue, Jan 18, 2011 at 09:04, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> The closest you will get is to deploy a relocation pom at the old GA
> with the new V., e.g. at
>
> <groupId>org.drools</groupId>
> <artifactId>drools-repository</artifactId>
> <version>5.2.0</version>
>
> it's not perfect (i.e. it will only notify people using ranges.... and
> only fools use ranges!) and it does not do exactly what you want, but
> it will at least give a bit more of a hint.
>
> I should probably add some goals to v-m-p to help trace relocation
> poms and add exclusions for the old locations to the tree
>
> -Stephen
>
> On 18 January 2011 07:58, Geoffrey De Smet <ge...@gmail.com>
> wrote:
> > Hi,
> >
> > We have a pom.xml for the drools guvnor repository jar, with this
> > identification:
> >
> > <groupId>org.drools</groupId>
> > <artifactId>drools-repository</artifactId>
> > <version>5.1.0</version>
> >
> > Now, for the next version of that jar, we need to change the
> identification
> > to:
> >
> > <groupId>org.drools.guvnor</groupId>
> > <artifactId>guvnor-repository</artifactId>
> > <version>5.2.0</version>
> >
> > It's the same code in the jar, but the original identification was wrong
> and
> > we're fixing that now.
> > The problem is, what happens if one of our users has this dependency
> tree?
> > - foo
> > -- foo depends on bar
> > --- bar depends on org.drools:drools-repository:5.1.0
> > -- foo depends on org.drools.guvnor:guvnor-repository:5.2.0
> >
> > Maven will not detect the dependency conflict between
> > - org.drools:drools-repository:5.1.0
> > - org.drools.guvnor:guvnor-repository:5.2.0
> > and it will put both of them in the classpath, instead of just 5.2.0.
> >
> > Is there any way to tell maven in the 5.2.0 pom.xml, something like this:
> > <groupId>org.drools.guvnor</groupId>
> > <artifactId>guvnor-repository</artifactId>
> > <version>5.2.0</version>
> > <legacy-identifications>
> > <legacy-identification>
> > <groupId>org.drools</groupId>
> > <artifactId>drools-repository</artifactId>
> > <legacy-identification>
> > </legacy-identifications>
> > So it does detect the dependency conflict and lets just 5.2.0 survive?
> >
> > --
> > With kind regards,
> > Geoffrey De Smet
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

Posted by Stephen Connolly <st...@gmail.com>.
The closest you will get is to deploy a relocation pom at the old GA
with the new V., e.g. at

<groupId>org.drools</groupId>
<artifactId>drools-repository</artifactId>
<version>5.2.0</version>

it's not perfect (i.e. it will only notify people using ranges.... and
only fools use ranges!) and it does not do exactly what you want, but
it will at least give a bit more of a hint.

I should probably add some goals to v-m-p to help trace relocation
poms and add exclusions for the old locations to the tree

-Stephen

On 18 January 2011 07:58, Geoffrey De Smet <ge...@gmail.com> wrote:
> Hi,
>
> We have a pom.xml for the drools guvnor repository jar, with this
> identification:
>
> <groupId>org.drools</groupId>
> <artifactId>drools-repository</artifactId>
> <version>5.1.0</version>
>
> Now, for the next version of that jar, we need to change the identification
> to:
>
> <groupId>org.drools.guvnor</groupId>
> <artifactId>guvnor-repository</artifactId>
> <version>5.2.0</version>
>
> It's the same code in the jar, but the original identification was wrong and
> we're fixing that now.
> The problem is, what happens if one of our users has this dependency tree?
> - foo
> -- foo depends on bar
> --- bar depends on org.drools:drools-repository:5.1.0
> -- foo depends on org.drools.guvnor:guvnor-repository:5.2.0
>
> Maven will not detect the dependency conflict between
> - org.drools:drools-repository:5.1.0
> - org.drools.guvnor:guvnor-repository:5.2.0
> and it will put both of them in the classpath, instead of just 5.2.0.
>
> Is there any way to tell maven in the 5.2.0 pom.xml, something like this:
> <groupId>org.drools.guvnor</groupId>
> <artifactId>guvnor-repository</artifactId>
> <version>5.2.0</version>
> <legacy-identifications>
> <legacy-identification>
> <groupId>org.drools</groupId>
> <artifactId>drools-repository</artifactId>
> <legacy-identification>
> </legacy-identifications>
> So it does detect the dependency conflict and lets just 5.2.0 survive?
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
>
> ---------------------------------------------------------------------
> 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