Yeah... seems related (if not the same) to me. Why is specifying a plugin more than once bad? Is there a technical reason? Pushing sections to adjacent phases works but since there are only so many phases it doesn't scale.
On Fri, Feb 22, 2008 at 5:04 PM, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
