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] > >> > > > > --- > > John Casey > > Committer and PMC Member, Apache Maven > > mail: jdcasey at commonjava dot org > > blog: http://www.ejlife.net/blogs/john > > rss: http://feeds.feedburner.com/ejlife/john > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --- > John Casey > Committer and PMC Member, Apache Maven > mail: jdcasey at commonjava dot org > blog: http://www.ejlife.net/blogs/john > rss: http://feeds.feedburner.com/ejlife/john > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
