related to MNG-1701 ?

On Fri, Feb 22, 2008 at 1:15 PM, Ryan Ovrevik <[EMAIL PROTECTED]> wrote:
> Thanks! You reiterated my thoughts almost exactly.
>
>  Forcing executions into arbitrary adjacent phases will work fine… it
>  just seems ugly.
>
>  thanks,
>  rovrevik
>
>
>
>  On Fri, Feb 22, 2008 at 3:35 AM, [EMAIL PROTECTED]
>  <[EMAIL PROTECTED]> wrote:
>  > 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: dev@maven.apache.org
>  >  >>
>  >  >>
>  >  >> 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: dev@maven.apache.org
>  >  >>  >> 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]
>  >
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to