You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2014/09/27 22:58:15 UTC

Re: svn commit: r1628003 - /maven/shared/trunk/maven-shared-utils/pom.xml

Hi,

I wonder if this does what we want to achieve: forcing projects using  
maven-shared-utils to be executed with at least Maven 2.2.1.
Right now it is just the preferred version, no problem if the project  
itself redefines it to 2.0.9 for instance.
Is that a problem or should we say [2.2.1,) ?

thanks,
Robert


Op Sat, 27 Sep 2014 22:30:03 +0200 schreef <kh...@apache.org>:

> Author: khmarbaise
> Date: Sat Sep 27 20:30:03 2014
> New Revision: 1628003
>
> URL: http://svn.apache.org/r1628003
> Log:
> [MSHARED-359]
>  - Upgrade to Maven 2.2.1 build and compatibility.
>
> Modified:
>     maven/shared/trunk/maven-shared-utils/pom.xml
>
> Modified: maven/shared/trunk/maven-shared-utils/pom.xml
> URL:  
> http://svn.apache.org/viewvc/maven/shared/trunk/maven-shared-utils/pom.xml?rev=1628003&r1=1628002&r2=1628003&view=diff
> ==============================================================================
> --- maven/shared/trunk/maven-shared-utils/pom.xml (original)
> +++ maven/shared/trunk/maven-shared-utils/pom.xml Sat Sep 27 20:30:03  
> 2014
> @@ -55,7 +55,7 @@
>    </distributionManagement>
>   <properties>
> -    <mavenVersion>2.1.0</mavenVersion>
> +    <mavenVersion>2.2.1</mavenVersion>
>    </properties>
>   <dependencies>
>

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


Re: svn commit: r1628003 - /maven/shared/trunk/maven-shared-utils/pom.xml

Posted by Robert Scholte <rf...@apache.org>.
Hi Karl-Heinz,

*I* think the Jira-issue should be removed. It suggests change in behavior  
which it doesn't and will only confuse users.
In the end it is only a compile-time adjustment, at runtime the dependency  
will always be replaced with the executing Maven version.
For housekeeping I don't mind upgrading it to 2.2.1 by default.

thanks,
Robert


Op Sat, 04 Oct 2014 19:39:32 +0200 schreef Karl Heinz Marbaise  
<kh...@gmx.de>:

> Hi Robert,
>
>
> how would you change this?
>
> Kind regards
> Karl-Heinz Marbaise
> On 10/2/14 8:22 PM, Robert Scholte wrote:
>> Hi Dennis, Karl-Heinz,
>>
>> the issue mentioned compatibility and based on the changes it looked to
>> me that the intention doesn't match the actual behavior in the end.
>> With plugins it is very easy to force a specific version of Maven: set
>> the prerequisite.
>> *If* the idea was that changing the maven dependency version in
>> shared-utils to 2.2.1 would help us to push users towards newer versions
>> of Maven, then that idea was not correct.
>> It is possible, if you specify the dependency like:
>>       <dependency>
>>         <groupId>org.apache.maven</groupId>
>>         <artifactId>maven-toolchain</artifactId>
>>         <version>[2.2.1,)</version>
>>         <scope>provided</scope>
>>       </dependency>
>> The downside of this construction is that the project using shared-utils
>> is now responsible to specify the preferred version, otherwise the
>> latest will be used.
>>
>> If this change is just about housekeeping, that's fine too. But then the
>> issue text is misleading.
>>
>> I hope this clears things up :)
>>
>> Robert
>>
>>
>> Op Tue, 30 Sep 2014 13:43:06 +0200 schreef Dennis Lundberg
>> <de...@apache.org>:
>>
>>> Hi Robert,
>>>
>>> Isn't the idea of the work Karl-Heinz is doing to unify the version of
>>> maven core libraries in our other components/plugins?
>>>
>>> It is true that the mavenVersion property has a dual meaning:
>>> 1. setting a prerequisite for the version of Maven required to build
>>> the project
>>> 2. setting the version of dependencies on maven core components
>>>
>>> IIUC Karl-Heinz is mainly trying to solve 2 by changing the value of
>>> mavenVersion. We have already in our docs that we require at least
>>> Maven 2.2.1 to build our projects, and in some cases (site) Maven
>>> 3.0.5. I don't see any negative sideeffect of changing the
>>> mavenVersion property. Perhaps I am missing something?
>>>
>>> When Karl-Heinz has finished upgrading to 2.2.1 everywhere, why would
>>> anyone want to redefine the preferred version to an earlier verion
>>> like 2.0.9? I can't think of a way to prevent that.
>>>
>>> Introducing a version range like [2.2.1,) for the prerequisites
>>> doesn't change anything as I understand it.
>>>
>>>
>>> On Sat, Sep 27, 2014 at 10:58 PM, Robert Scholte
>>> <rf...@apache.org> wrote:
>>>> Hi,
>>>>
>>>> I wonder if this does what we want to achieve: forcing projects using
>>>> maven-shared-utils to be executed with at least Maven 2.2.1.
>>>> Right now it is just the preferred version, no problem if the project
>>>> itself
>>>> redefines it to 2.0.9 for instance.
>>>> Is that a problem or should we say [2.2.1,) ?
>>>>
>>>> thanks,
>>>> Robert
>>>>
>>>>
>>>> Op Sat, 27 Sep 2014 22:30:03 +0200 schreef <kh...@apache.org>:
>>>>
>>>>
>>>>> Author: khmarbaise
>>>>> Date: Sat Sep 27 20:30:03 2014
>>>>> New Revision: 1628003
>>>>>
>>>>> URL: http://svn.apache.org/r1628003
>>>>> Log:
>>>>> [MSHARED-359]
>>>>>  - Upgrade to Maven 2.2.1 build and compatibility.
>>>>>
>>>>> Modified:
>>>>>     maven/shared/trunk/maven-shared-utils/pom.xml
>>>>>
>>>>> Modified: maven/shared/trunk/maven-shared-utils/pom.xml
>>>>> URL:
>>>>> http://svn.apache.org/viewvc/maven/shared/trunk/maven-shared-utils/pom.xml?rev=1628003&r1=1628002&r2=1628003&view=diff
>>>>>
>>>>>
>>>>> ==============================================================================
>>>>>
>>>>> --- maven/shared/trunk/maven-shared-utils/pom.xml (original)
>>>>> +++ maven/shared/trunk/maven-shared-utils/pom.xml Sat Sep 27
>>>>> 20:30:03 2014
>>>>> @@ -55,7 +55,7 @@
>>>>>    </distributionManagement>
>>>>>   <properties>
>>>>> -    <mavenVersion>2.1.0</mavenVersion>
>>>>> +    <mavenVersion>2.2.1</mavenVersion>
>>>>>    </properties>
>>>>>   <dependencies>
>>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

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


Re: svn commit: r1628003 - /maven/shared/trunk/maven-shared-utils/pom.xml

Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Robert,


how would you change this?

Kind regards
Karl-Heinz Marbaise
On 10/2/14 8:22 PM, Robert Scholte wrote:
> Hi Dennis, Karl-Heinz,
>
> the issue mentioned compatibility and based on the changes it looked to
> me that the intention doesn't match the actual behavior in the end.
> With plugins it is very easy to force a specific version of Maven: set
> the prerequisite.
> *If* the idea was that changing the maven dependency version in
> shared-utils to 2.2.1 would help us to push users towards newer versions
> of Maven, then that idea was not correct.
> It is possible, if you specify the dependency like:
>       <dependency>
>         <groupId>org.apache.maven</groupId>
>         <artifactId>maven-toolchain</artifactId>
>         <version>[2.2.1,)</version>
>         <scope>provided</scope>
>       </dependency>
> The downside of this construction is that the project using shared-utils
> is now responsible to specify the preferred version, otherwise the
> latest will be used.
>
> If this change is just about housekeeping, that's fine too. But then the
> issue text is misleading.
>
> I hope this clears things up :)
>
> Robert
>
>
> Op Tue, 30 Sep 2014 13:43:06 +0200 schreef Dennis Lundberg
> <de...@apache.org>:
>
>> Hi Robert,
>>
>> Isn't the idea of the work Karl-Heinz is doing to unify the version of
>> maven core libraries in our other components/plugins?
>>
>> It is true that the mavenVersion property has a dual meaning:
>> 1. setting a prerequisite for the version of Maven required to build
>> the project
>> 2. setting the version of dependencies on maven core components
>>
>> IIUC Karl-Heinz is mainly trying to solve 2 by changing the value of
>> mavenVersion. We have already in our docs that we require at least
>> Maven 2.2.1 to build our projects, and in some cases (site) Maven
>> 3.0.5. I don't see any negative sideeffect of changing the
>> mavenVersion property. Perhaps I am missing something?
>>
>> When Karl-Heinz has finished upgrading to 2.2.1 everywhere, why would
>> anyone want to redefine the preferred version to an earlier verion
>> like 2.0.9? I can't think of a way to prevent that.
>>
>> Introducing a version range like [2.2.1,) for the prerequisites
>> doesn't change anything as I understand it.
>>
>>
>> On Sat, Sep 27, 2014 at 10:58 PM, Robert Scholte
>> <rf...@apache.org> wrote:
>>> Hi,
>>>
>>> I wonder if this does what we want to achieve: forcing projects using
>>> maven-shared-utils to be executed with at least Maven 2.2.1.
>>> Right now it is just the preferred version, no problem if the project
>>> itself
>>> redefines it to 2.0.9 for instance.
>>> Is that a problem or should we say [2.2.1,) ?
>>>
>>> thanks,
>>> Robert
>>>
>>>
>>> Op Sat, 27 Sep 2014 22:30:03 +0200 schreef <kh...@apache.org>:
>>>
>>>
>>>> Author: khmarbaise
>>>> Date: Sat Sep 27 20:30:03 2014
>>>> New Revision: 1628003
>>>>
>>>> URL: http://svn.apache.org/r1628003
>>>> Log:
>>>> [MSHARED-359]
>>>>  - Upgrade to Maven 2.2.1 build and compatibility.
>>>>
>>>> Modified:
>>>>     maven/shared/trunk/maven-shared-utils/pom.xml
>>>>
>>>> Modified: maven/shared/trunk/maven-shared-utils/pom.xml
>>>> URL:
>>>> http://svn.apache.org/viewvc/maven/shared/trunk/maven-shared-utils/pom.xml?rev=1628003&r1=1628002&r2=1628003&view=diff
>>>>
>>>>
>>>> ==============================================================================
>>>>
>>>> --- maven/shared/trunk/maven-shared-utils/pom.xml (original)
>>>> +++ maven/shared/trunk/maven-shared-utils/pom.xml Sat Sep 27
>>>> 20:30:03 2014
>>>> @@ -55,7 +55,7 @@
>>>>    </distributionManagement>
>>>>   <properties>
>>>> -    <mavenVersion>2.1.0</mavenVersion>
>>>> +    <mavenVersion>2.2.1</mavenVersion>
>>>>    </properties>
>>>>   <dependencies>
>>>>

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


Re: svn commit: r1628003 - /maven/shared/trunk/maven-shared-utils/pom.xml

Posted by Robert Scholte <rf...@apache.org>.
Hi Dennis, Karl-Heinz,

the issue mentioned compatibility and based on the changes it looked to me  
that the intention doesn't match the actual behavior in the end.
With plugins it is very easy to force a specific version of Maven: set the  
prerequisite.
*If* the idea was that changing the maven dependency version in  
shared-utils to 2.2.1 would help us to push users towards newer versions  
of Maven, then that idea was not correct.
It is possible, if you specify the dependency like:
      <dependency>
        <groupId>org.apache.maven</groupId>
        <artifactId>maven-toolchain</artifactId>
        <version>[2.2.1,)</version>
        <scope>provided</scope>
      </dependency>
The downside of this construction is that the project using shared-utils  
is now responsible to specify the preferred version, otherwise the latest  
will be used.

If this change is just about housekeeping, that's fine too. But then the  
issue text is misleading.

I hope this clears things up :)

Robert


Op Tue, 30 Sep 2014 13:43:06 +0200 schreef Dennis Lundberg  
<de...@apache.org>:

> Hi Robert,
>
> Isn't the idea of the work Karl-Heinz is doing to unify the version of
> maven core libraries in our other components/plugins?
>
> It is true that the mavenVersion property has a dual meaning:
> 1. setting a prerequisite for the version of Maven required to build the  
> project
> 2. setting the version of dependencies on maven core components
>
> IIUC Karl-Heinz is mainly trying to solve 2 by changing the value of
> mavenVersion. We have already in our docs that we require at least
> Maven 2.2.1 to build our projects, and in some cases (site) Maven
> 3.0.5. I don't see any negative sideeffect of changing the
> mavenVersion property. Perhaps I am missing something?
>
> When Karl-Heinz has finished upgrading to 2.2.1 everywhere, why would
> anyone want to redefine the preferred version to an earlier verion
> like 2.0.9? I can't think of a way to prevent that.
>
> Introducing a version range like [2.2.1,) for the prerequisites
> doesn't change anything as I understand it.
>
>
> On Sat, Sep 27, 2014 at 10:58 PM, Robert Scholte <rf...@apache.org>  
> wrote:
>> Hi,
>>
>> I wonder if this does what we want to achieve: forcing projects using
>> maven-shared-utils to be executed with at least Maven 2.2.1.
>> Right now it is just the preferred version, no problem if the project  
>> itself
>> redefines it to 2.0.9 for instance.
>> Is that a problem or should we say [2.2.1,) ?
>>
>> thanks,
>> Robert
>>
>>
>> Op Sat, 27 Sep 2014 22:30:03 +0200 schreef <kh...@apache.org>:
>>
>>
>>> Author: khmarbaise
>>> Date: Sat Sep 27 20:30:03 2014
>>> New Revision: 1628003
>>>
>>> URL: http://svn.apache.org/r1628003
>>> Log:
>>> [MSHARED-359]
>>>  - Upgrade to Maven 2.2.1 build and compatibility.
>>>
>>> Modified:
>>>     maven/shared/trunk/maven-shared-utils/pom.xml
>>>
>>> Modified: maven/shared/trunk/maven-shared-utils/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/maven/shared/trunk/maven-shared-utils/pom.xml?rev=1628003&r1=1628002&r2=1628003&view=diff
>>>
>>> ==============================================================================
>>> --- maven/shared/trunk/maven-shared-utils/pom.xml (original)
>>> +++ maven/shared/trunk/maven-shared-utils/pom.xml Sat Sep 27 20:30:03  
>>> 2014
>>> @@ -55,7 +55,7 @@
>>>    </distributionManagement>
>>>   <properties>
>>> -    <mavenVersion>2.1.0</mavenVersion>
>>> +    <mavenVersion>2.2.1</mavenVersion>
>>>    </properties>
>>>   <dependencies>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>

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


Re: svn commit: r1628003 - /maven/shared/trunk/maven-shared-utils/pom.xml

Posted by Dennis Lundberg <de...@apache.org>.
Hi Robert,

Isn't the idea of the work Karl-Heinz is doing to unify the version of
maven core libraries in our other components/plugins?

It is true that the mavenVersion property has a dual meaning:
1. setting a prerequisite for the version of Maven required to build the project
2. setting the version of dependencies on maven core components

IIUC Karl-Heinz is mainly trying to solve 2 by changing the value of
mavenVersion. We have already in our docs that we require at least
Maven 2.2.1 to build our projects, and in some cases (site) Maven
3.0.5. I don't see any negative sideeffect of changing the
mavenVersion property. Perhaps I am missing something?

When Karl-Heinz has finished upgrading to 2.2.1 everywhere, why would
anyone want to redefine the preferred version to an earlier verion
like 2.0.9? I can't think of a way to prevent that.

Introducing a version range like [2.2.1,) for the prerequisites
doesn't change anything as I understand it.


On Sat, Sep 27, 2014 at 10:58 PM, Robert Scholte <rf...@apache.org> wrote:
> Hi,
>
> I wonder if this does what we want to achieve: forcing projects using
> maven-shared-utils to be executed with at least Maven 2.2.1.
> Right now it is just the preferred version, no problem if the project itself
> redefines it to 2.0.9 for instance.
> Is that a problem or should we say [2.2.1,) ?
>
> thanks,
> Robert
>
>
> Op Sat, 27 Sep 2014 22:30:03 +0200 schreef <kh...@apache.org>:
>
>
>> Author: khmarbaise
>> Date: Sat Sep 27 20:30:03 2014
>> New Revision: 1628003
>>
>> URL: http://svn.apache.org/r1628003
>> Log:
>> [MSHARED-359]
>>  - Upgrade to Maven 2.2.1 build and compatibility.
>>
>> Modified:
>>     maven/shared/trunk/maven-shared-utils/pom.xml
>>
>> Modified: maven/shared/trunk/maven-shared-utils/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/maven/shared/trunk/maven-shared-utils/pom.xml?rev=1628003&r1=1628002&r2=1628003&view=diff
>>
>> ==============================================================================
>> --- maven/shared/trunk/maven-shared-utils/pom.xml (original)
>> +++ maven/shared/trunk/maven-shared-utils/pom.xml Sat Sep 27 20:30:03 2014
>> @@ -55,7 +55,7 @@
>>    </distributionManagement>
>>   <properties>
>> -    <mavenVersion>2.1.0</mavenVersion>
>> +    <mavenVersion>2.2.1</mavenVersion>
>>    </properties>
>>   <dependencies>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-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: svn commit: r1628003 - /maven/shared/trunk/maven-shared-utils/pom.xml

Posted by Robert Scholte <rf...@apache.org>.
Hi Karl-Heinz,

Prerequisites are only used for plugins at runtime, specifying with which  
Maven version it should at least be executed.
When Maven builds the dependency-tree, the prerequisites are ignored.

So your latest change has no effect.

It's very rare when I use version ranges, but this might be a situation  
where we want it.

thanks,
Robert


Op Sun, 28 Sep 2014 09:38:19 +0200 schreef Karl Heinz Marbaise  
<kh...@gmx.de>:

> Hi Robert,
>
>  > I wonder if this does what we want to achieve: forcing projects using
>> maven-shared-utils to be executed with at least Maven 2.2.1.
>> Right now it is just the preferred version, no problem if the project
>> itself redefines it to 2.0.9 for instance.
>> Is that a problem or should we say [2.2.1,) ?
>
> Well spotted...The problem with this property is that this will be used  
> for an artifact dependency maven-toolchain as well...
>
> Apart from that it had been on 2.1.0 before....
>
> So i think it's best to separate these to things...
>
> So defining an version range might be not the best idea...in my  
> opinion...or only for prerequisites...which is ok...
>
> I have made a change you might take a look on it and say if you are fine  
> with it...or not...
>
> Kind regards
> Karl-Heinz Marbaise
>
>>
>> thanks,
>> Robert
>>
>>
>> Op Sat, 27 Sep 2014 22:30:03 +0200 schreef <kh...@apache.org>:
>>
>>> Author: khmarbaise
>>> Date: Sat Sep 27 20:30:03 2014
>>> New Revision: 1628003
>>>
>>> URL: http://svn.apache.org/r1628003
>>> Log:
>>> [MSHARED-359]
>>>  - Upgrade to Maven 2.2.1 build and compatibility.
>>>
>>> Modified:
>>>     maven/shared/trunk/maven-shared-utils/pom.xml
>>>
>>> Modified: maven/shared/trunk/maven-shared-utils/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/maven/shared/trunk/maven-shared-utils/pom.xml?rev=1628003&r1=1628002&r2=1628003&view=diff
>>>
>>> ==============================================================================
>>>
>>> --- maven/shared/trunk/maven-shared-utils/pom.xml (original)
>>> +++ maven/shared/trunk/maven-shared-utils/pom.xml Sat Sep 27 20:30:03
>>> 2014
>>> @@ -55,7 +55,7 @@
>>>    </distributionManagement>
>>>   <properties>
>>> -    <mavenVersion>2.1.0</mavenVersion>
>>> +    <mavenVersion>2.2.1</mavenVersion>
>>>    </properties>
>>>   <dependencies>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

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


Re: svn commit: r1628003 - /maven/shared/trunk/maven-shared-utils/pom.xml

Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Robert,

 > I wonder if this does what we want to achieve: forcing projects using
> maven-shared-utils to be executed with at least Maven 2.2.1.
> Right now it is just the preferred version, no problem if the project
> itself redefines it to 2.0.9 for instance.
> Is that a problem or should we say [2.2.1,) ?

Well spotted...The problem with this property is that this will be used 
for an artifact dependency maven-toolchain as well...

Apart from that it had been on 2.1.0 before....

So i think it's best to separate these to things...

So defining an version range might be not the best idea...in my 
opinion...or only for prerequisites...which is ok...

I have made a change you might take a look on it and say if you are fine 
with it...or not...

Kind regards
Karl-Heinz Marbaise

>
> thanks,
> Robert
>
>
> Op Sat, 27 Sep 2014 22:30:03 +0200 schreef <kh...@apache.org>:
>
>> Author: khmarbaise
>> Date: Sat Sep 27 20:30:03 2014
>> New Revision: 1628003
>>
>> URL: http://svn.apache.org/r1628003
>> Log:
>> [MSHARED-359]
>>  - Upgrade to Maven 2.2.1 build and compatibility.
>>
>> Modified:
>>     maven/shared/trunk/maven-shared-utils/pom.xml
>>
>> Modified: maven/shared/trunk/maven-shared-utils/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/maven/shared/trunk/maven-shared-utils/pom.xml?rev=1628003&r1=1628002&r2=1628003&view=diff
>>
>> ==============================================================================
>>
>> --- maven/shared/trunk/maven-shared-utils/pom.xml (original)
>> +++ maven/shared/trunk/maven-shared-utils/pom.xml Sat Sep 27 20:30:03
>> 2014
>> @@ -55,7 +55,7 @@
>>    </distributionManagement>
>>   <properties>
>> -    <mavenVersion>2.1.0</mavenVersion>
>> +    <mavenVersion>2.2.1</mavenVersion>
>>    </properties>
>>   <dependencies>
>>

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