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
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
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
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
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
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
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,)
