Brian Fox wrote:
What is the behavior in an embedded env like M2e? Since it's not going
to execute the full lifecycle, it probably needs to have the same
logic regardless to look at the lifecycle and pick the right version
of a plugin it does run.
Not sure I understand that question. Embedders
On Thu, Nov 19, 2009 at 1:24 PM, Benjamin Bentmann
wrote:
> Brian Fox wrote:
>
>> I guess what I had in mind was given a single reactor build:
>> A : Jar
>> B: War but binds jar to a phase.
>>
>> Will B always get the same version of the jar plugin as A?
>
> No, the projects are handled independen
Brian Fox wrote:
I guess what I had in mind was given a single reactor build:
A : Jar
B: War but binds jar to a phase.
Will B always get the same version of the jar plugin as A?
No, the projects are handled independently regarding their build plugins.
For instance, if B doesn't lock down the
>> 2) what are the impacts to the plugin when it's run in multiple
>> lifecycles, or if the user binds it to a phase of some other
>> lifecycle? Would this cause the version to vary in unpredictable ways?
>
> Good questions, let's look closer at the edge cases:
>
I guess what I had in mind was giv
Brian Fox wrote:
1) we included some plugins that are commonly used but aren't in a
lifecycle such as the dependency and enforcer plugins.
I know, if those are declared in the POM they have to have/inherit a
version or Maven 3.0 will output a warning.
In other words, what we consider "commo
> Apparently, this change would make custom lifecycle mappings that don't
> specify plugin versions subject to automatic plugin version resolution as in
> Maven 2.0.8- unless the consuming POM (or its parents) locked the version
> down. On the hand, Maven 3 will report this situation as a prominent
From a user's Point of View it seems only logical to me that the
lifecycle defines which versions of the Plugins should Be used. The
super pom is no help
Von meinem iPod gesendet
Am 18.11.2009 um 11:58 schrieb "Benjamin Bentmann" >:
Brian Fox wrote:
Second, I always subscribe to the the
Brian Fox wrote:
Second, I always subscribe to the theory that "closest" wins.
[...] I think in this case, the pom is
"closer" than the lifecycle and therefore it should win as is
happening in the 3.x case.
I agree, it's simply a matter of giving the build engineer control over
his build.
S
Personally I didn't even know you could put a version into the
lifecycle, I've never seen that done.
Second, I always subscribe to the theory that "closest" wins. In the
inheritance case, it means things in my pom override my parent pom,
which overrides the grandparent etc. I think in this case, t
Sebastian Annies wrote:
we are using a custom lifecycle and bind the maven-source-plugin in
version 2.1 to the verify phase. In the 2.X branch it always worked
perfectly. But now I tried alpha-3 and 4 and it seems that Maven uses
the maven-source-plugin in version 2.0.4
Confirmed and filled as
Sebastian Annies wrote:
Has anyone of you experienced similar behavior or is intended to work
that way?
Maybe there's some bad interaction with the default versions in the
super POM, I'll have a closer look.
Benjamin
-
T
Hi,
we are using a custom lifecycle and bind the maven-source-plugin in
version 2.1 to the verify phase. In the 2.X branch it always worked
perfectly. But now I tried alpha-3 and 4 and it seems that Maven uses
the maven-source-plugin in version 2.0.4 even though I explicitly
require 2.1 ( 2.0.4 d
12 matches
Mail list logo
