Hi Ryan,
So what you are trying to achieve is control the ordering of executions
within a single phase?
Ie you want:
Phase X:
(1) plugin A
(2) plugin B
(3) plugin A again
Yes, I think this is not currently possible to achieve with <execution>
blocks.
There is some discussion about providing better control over plugin
ordering for maven2.1. Maybe this needs to go on the list of use-cases.
If the second execution of A was actually done via a different plugin,
then achieving this would be simple; the order of plugins in the pom is
the order of bindings to the phase. It does seem a little odd that
simply because step 3 happens to use a plugin that has already been used
in the pom that the mechanism for configuring it is suddenly radically
different (multiple execution tags, not multiple plugin tags).
An alternative that stays with the executions approach could be to add
an extra property of an execution declaration that says whether to add
it to the "tail" of the plugin-list for the phase (default) or the
"head". Then for your case, first declare plugin B then mark the first
execution of plugin A "head" and the second "tail" (default). Perhaps
this could be done by something like:
<phase>integration-test;head</phase>
without needing a POM format change? This still
Or perhaps an execution could be marked as "before the execution with id
X" which might be a more explicit way of declaring inter-execution
dependencies. Then plugin B could be declared as being "before" the
excution for (3).
Cramming this into the existing execution configuration elements doesn't
seem easy though. Maybe
<phase>integration-test;before=maven-A-plugin:execStep3</phase>
although that syntax is rather ugly...
To me, the approach of simply allowing multiple plugin declarations
looks at least as simple as the above suggestions though. And can be
implemented (as you show) without POM syntax changes.
But for now it seems to me that using different phases is your best
solution..and hoping that there are suitable phases in the lifecycle
available to be used. In your case, are pre-integration-test and
post-integration-test suitable?
Regards,
Simon
(PS: I'm just a maven user, not a developer..)
Ryan Ovrevik schrieb:
> Yeah, thanks, I know about using multiple executions.
>
> It is a shame that you have to put an execution in an arbitrary phase
> just to make the configuration behave (at least it seems that way to
> me). The use case that I have fits very nicely into
> generate-test-resources to export date from a source database and
> process-test-resources to import the data into the target database. If
> using additional phases is the way that it has to be… oh well.
>
> For what it is worth… The patch is trivial and has not broken any of
> the other maven projects that I have built with it.
>
> Thanks,
> rovrevik
>
> On Thu, Feb 21, 2008 at 11:00 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
>> Put multiple <execution> blocks inside the <executions>. You would
>> probably need to use two phases though.
>>
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>> Ryan Ovrevik
>>
>> Sent: Thursday, February 21, 2008 10:19 PM
>> To: [email protected]
>>
>>
>> Subject: Re: Configuration not selected properly when a plugin is
>> specified multiple times in the pom.
>>
>> I was specifying a plugin twice with-in a profile to control the order
>> of operations across two plugins with in a particular phase. The
>> scenario is as follows (simplified):
>> * Use sql-maven to drop and create a database.
>> * Use dbunit to import some data.
>> * Use sql-unit again to drop some columns on the imported data.
>>
>> If you do not specify the plugin twice, how would you do this?
>>
>> rovrevik
>>
>>
>>
>>
>> IIRC, model validation happens after inheritance and profile
>> injection, to ensure the project has every opportunity to fill in
>> missing sections.
>>
>> So, performing this sort of check in the model validator would be
>> appropriate. I added a check for duplicate dependencies recently,
>> IIRC, and this is similar.
>>
>> -john
>>
>> On Feb 21, 2008, at 10:26 AM, Brian E. Fox wrote:
>>
>> > I was thinking this was across multiple poms (inheritance) but yes in
>> > the same pom that's not good.
>> >
>> > -----Original Message-----
>> > From: John Casey [mailto:[EMAIL PROTECTED]
>> > Sent: Thursday, February 21, 2008 10:19 AM
>> > To: Maven Developers List
>> > Subject: Re: Configuration not selected properly when a plugin is
>> > specified multiple times in the pom.
>> >
>> > We should probably add some logic to the project/POM validator to
>> > detect duplicated plugin entries (by the plugin's
>> > groupId:artifactId:version) and fail the build with a useful error
>> > message. That would prompt users to consolidate multiple plugin
>> > sections that refer to the same plugin.
>> >
>> > -john
>> >
>> > On Feb 20, 2008, at 11:42 PM, Brian E. Fox wrote:
>> >
>> >> Yep, I think this is related to it only picking the first version it
>> >> comes across, regardless of future version declarations.
>> >>
>> >> -----Original Message-----
>> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>> >> Ryan Ovrevik
>> >> Sent: Wednesday, February 20, 2008 10:25 PM
>> >> To: [email protected]
>> >> Subject: Configuration not selected properly when a plugin is
>> >> specified
>> >> multiple times in the pom.
>> >>
>> >> Only the first plugin configuration is applied when a plugin is used
>> >> multiple times within a profile. Following plug in configurations do
>> >> not use their specified configuration. Instead, configuration is
>> >> based
>> >> on what appears to be a combination of the configuration specified in
>> >> the first plugin configuration and some sort of default
>> >> configuration.
>> >>
>> >> I searched the jira issues for a similar reported issue with no
>> >> success. The code does have a big comment about a "limitation in
>> >> modello" if that helps. It seems that this must be a known issue.
>> >> But,
>> >> if it is new, I will enter a new jira issue and supply the patch that
>> >> I came up with (It is small).
>> >>
>> >> I have observed this behavior using the sql-maven-plugin. I believe
>> >> that I have traced the problem down to the implementation of
>> >> MavenProject.getGoalConfiguration. The logic iterates over all
>> >> plugins
>> >> searching for plugins that match the specified group and plugin id
>> >> along with a matching execution id. The problem appears to be that
>> >> the
>> >> iteration is stopped at the matching group and plugin id even if the
>> >> execution id does not match. This results in all future plugin
>> >> definitions not having the opportunity for consideration.
>> >>
>> >> Thanks,
>> >> Ryan Ovrevik
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
