[30/05/2005 23:11:28] jason: brett: are there any other example that come to mind with multiple invocations of the same mojo?
[30/05/2005 23:11:37] jason: like xdoclet in different phases
[30/05/2005 23:11:41] brett: modello with two versions was the one I used
[30/05/2005 23:11:49] brett: basically, we previously decided to declare a goal multiple times if it needed to be run again with new parameters
[30/05/2005 23:11:53] brett: the alternatives are to
[30/05/2005 23:12:00] brett: - not allow it, and make the plugin configure around it
[30/05/2005 23:12:33] brett: - do what we planned, but figure out some way to effectively merge configurations in inheritence/profiles
[30/05/2005 23:12:44] brett: pretty sure we want the latter?
[30/05/2005 23:13:52] jdcasey: I think I like your preferred soln from that page...but the thing that gets to me about it is that you're essentially putting in duplicate declarations of a plugin for a project.
[30/05/2005 23:14:06] trygvis: I think your preferred solution sounds the best
[30/05/2005 23:14:15] brett: or duplicate goals, I figured supporting either made sense
[30/05/2005 23:14:17] jdcasey: the plugin element does two things: binds a plugin to the project, and defines the execution params for that plugin
[30/05/2005 23:14:52] jdcasey: the problem with duplicate goals/config is that you lose the ability to specify plugin-level configuration for multiple sets of goals...
[30/05/2005 23:15:26] jdcasey: what about having an <execution/> element (or several) inside a plugin that defines an execution profile for that plugin?
[30/05/2005 23:15:31] brett: that was the reason to propose the later option
[30/05/2005 23:15:47] brett: just have multiple configurations
[30/05/2005 23:16:05] jdcasey: the last soln means you'd have to match configs and goal lists based on key, right?
[30/05/2005 23:16:19] brett: thats for inheritence
[30/05/2005 23:16:21] jdcasey: so you'd also have <goals key="v3">...</goals>
[30/05/2005 23:16:29] brett: no
[30/05/2005 23:16:40] brett: that's a listed downside
[30/05/2005 23:16:47] jdcasey: but in the last soln you cannot change the goals that are defined per execution...
[30/05/2005 23:16:48] brett: whether goals become part of the configuration or not
[30/05/2005 23:16:51] jdcasey: right
[30/05/2005 23:17:56] jdcasey: I think goals are definitely part of the execution config...in the xdoclet example, especially...
[30/05/2005 23:18:57] brett: but you still need to key it to make merging possible
[30/05/2005 23:19:00] jdcasey: you can key at the execution level, for inheritance
[30/05/2005 23:19:05] jdcasey: definitely
[30/05/2005 23:19:18] jdcasey: but it starts to separate the dual purpose of the plugin declaration
[30/05/2005 23:19:20] brett: ok, now rename executions goals and remove the goal subelement
[30/05/2005 23:19:46] jdcasey: so you're talking about embedding <configuration/> inside the goals element?
[30/05/2005 23:19:51] jdcasey: ...that would work
[30/05/2005 23:20:10] brett: no, in the goal element, which it already does
[30/05/2005 23:20:16] jdcasey: but from a modello standpoint, it's the same thing: you have to define a goals class.
[30/05/2005 23:20:18] brett: I'm not sure what the extra executions level gives you
[30/05/2005 23:20:35] brett: oh, I guess its another shared config
[30/05/2005 23:20:41] jdcasey: so you'd have to have per-goal configuration, even if it's the same for a set of goals in that execution?
[30/05/2005 23:20:49] jdcasey: shared per-execution
[30/05/2005 23:21:04] jdcasey: and that's probably more useful than shared across executions, really
[30/05/2005 23:21:53] brett: ok, let me paste here for the record. I can do a multiline
[30/05/2005 23:21:58] brett: <plugin>
   g/a/v
   <configuration />
   <executions>
     <execution>
       <configuration />
       <goals>
         <goal>
           <id/>
           <configuration/>
[30/05/2005 23:22:19] jdcasey: actually, I'd like to see the top level <configuration/> go away...
[30/05/2005 23:22:35] brett: in execution?
[30/05/2005 23:22:50] jdcasey: no, directly inside plugin...but that's just personal preference
[30/05/2005 23:23:08] brett: I think most people will configer per plugin
[30/05/2005 23:23:13] brett: its less verbose
[30/05/2005 23:23:17] jdcasey: I feel like the highest level of configuration should be per-execution, and that you'll always have at least one execution
[30/05/2005 23:23:23] jdcasey: eh, ok
[30/05/2005 23:23:32] brett: but the executions are often predefined
[30/05/2005 23:23:46] brett: anyone else have thoughts on the above?
[30/05/2005 23:25:03] brett: I'm missing <key/> inside execution, I guess
[30/05/2005 23:25:12] jdcasey: sure
[30/05/2005 23:25:16] brett: that does feel better than repeating a plugin or goal within a plugin without an extra wrapper
[30/05/2005 23:25:24] jdcasey: it's less confusing IMO
[30/05/2005 23:25:39] jdcasey: maybe more verbose, but it's worth it for clarity
[30/05/2005 23:25:51] brett: ok, I can live with that
[30/05/2005 23:25:55] brett: is the key the right approach to merging
[30/05/2005 23:26:10] brett: and only do that at the execution level
[30/05/2005 23:26:20] brett: I'll use id for consistency
[30/05/2005 23:26:29] jdcasey: that sounds right to me...