2008/11/10 Paul Gier <[EMAIL PROTECTED]>
> Stephen Connolly wrote:
>
>> 2008/11/10 Paul Gier <[EMAIL PROTECTED]>
>>
>> What about adding new syntax to the goal string? So that from the
>>> command
>>> line you could write something like this to refer to specific execution
>>> configs:
>>>
>>> mvn eclipse:eclipse{execution-1}
>>> or
>>> mvn eclipse:eclipse{execution-2}
>>>
>>>
>> How would that interact with the lifecycle?
>>
>> If I define execution-1 as attached to the compile phase, does that mean
>> that Maven will execute all phases upto compile and then just execute
>> eclipse:eclipse, or is it just executing eclipse:eclipse and ignoring any
>> plugins that are attached to prior phases? (With the side effect that I'd
>> loose the information of the extra attached source directories)
>>
>> The more I think about it, calling out a specific execution *that has been
>> attached to a specific phase* is a bad bad pattern, and it's a good thing
>> that Maven does not let you do that.
>>
>> If you need to do a pile of every-so-often tasks I'd define them in
>> profiles
>> with each profile attaching the plugins to the requisite phases and
>> defining
>> the defaultGoals to the highest phase necessary.
>>
>>
>>
> I was imagining that the interaction with the phases wouldn't change from
> how it is now. For example:
>
> mvn eclipse:eclipse{execution-1}
>
> This would behave the same way it does now (calls the genereate-resources
> phase then the eclipse goal) except that it would look for relevant
> configuration in execution-1. And of course merge that with the global
> plugin config.
> But it would ignore the phase and goals settings of the execution.
>
Ahh, no what eclipse:eclipse does currently is that it forkes the build to
call the lifecycle up to generate-sources (or is it generate-test-sources)
This is why I think eclipse:eclipse is a *bad example*
A better example is the compiler plugin.
If we had lifecycle:<phase> or lifecycle:<packaging>:<phase> we would not
need separate goals for compile and test-compile (of course we have the
minor problem of how to specify in the lifecycle that when bound to
test-compile we use different source and output dirs)
If you execute mvn compiler:compile outside of the lifecycle on a project
that generates sources you'll see why context becomes important.
>
>
> The curly braces already seem to be associated with execution ids in
>>> maven's logging output. This would mean that components.xml file in
>>> maven
>>> core could be changed to provide execution IDs for each plugin that is
>>> executed, but probably no one wants to manually update this all the time.
>>>
>>> IMO the wildcard syntax is more than what is needed, and will make the
>>> pom
>>> a little less readable. The choice should be configure all executions or
>>> just one, otherwise it starts getting too complicated.
>>>
>>> After looking into the current behavior a little more, it is possible to
>>> execute the same plugin goal twice in the same phase. So I think all the
>>> naming schemes proposed except maybe Brett's
>>> (groupId:artifactId:sequenceNumber) could run into conflicts in the
>>> future.
>>> But if we include a sequence number, then what happens if you add
>>> another
>>> execution of an existing plugin to the lifecycle? Do all the sequence
>>> numbers have to increment to make room?
>>>
>>>
>> Plus sequence number is non-deterministic. Also, you are forgetting...
>> this
>> is not the id of executions *defined within the pom* but it's the id of
>> executions *defined by either the lifecycle or the plugin's mojo bindings*
>>
>> I don't see how a mojo's descriptor can bind to any more than one phase,
>> so
>> I guess the only thing preventing uniqueness is if the lifecycle can
>> invoke
>> the same goal multiple times in the same phase... but hang on, how is that
>> a
>> problem if we say that the execution is per phase (unless you want to
>> configure the different multiple executions differentially.... sounds like
>> you're writing a severe hack)
>>
>>
>> I think if we add the goal name to the execution like Benjamin suggested,
>>> we will be unlikely to run into conflicts. So I would prefer something
>>> like:
>>>
>>> default-lifecycle-compile
>>> default-lifecycle-testCompile
>>>
>>>
>> No, what if I bind compile goal to the compile phase and process-classes?
>>
>> Now I have an execution that is bound to two phases (not allowed) or two
>> executions with the same id (not allowed)
>>
>> I'm sorry, but I don't see how you can exclude the phase from the
>> execution's id...
>>
>> And given that phases consist of names separated by -, it seems confusing
>> to
>> name them with - as a separator.
>>
>> Now I don't mind if we do
>>
>> default-lifecycle:compile
>> default-lifecycle:test-compile
>>
>> or
>>
>> lifecycle:compile
>> lifecycle:test-compile
>>
>> or
>>
>> lifecycle:jar:compile
>> lifecycle:jar:test-compile
>>
>> or even use a different separator ('/' anyone?)
>>
>> The only advantage of specifying the packaging type is if you have a
>> common
>> root pom. Wildcards only become really important if you use packaging in
>> the id, but there is still the issue of what if I need to specify
>> something
>> for all executions (but keep the defaults outside of an execution
>> different
>> for when executing goals directly from the command line)
>>
>> I can live without wildcards.
>>
>> Sequence numbers are either non-deterministic, or will end up having a 1:1
>> mapping with each phase, so why not just use the phase. Goal is
>> non-unique,
>> and has the problem of multiple executions, and we can likely get away
>> with
>> just phase anyway.
>>
>>
>> When building, this logs to the command line like this:
>>> [INFO] [compiler:compile {execution: default-lifecycle-compile}]
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>
>
