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]
