2008/11/10 Paul Gier <[EMAIL PROTECTED]>
> Stephen Connolly wrote:
>
>> 2008/11/10 Paul Gier <[EMAIL PROTECTED]>
>>
>> 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 just said that sequence numbers are the only way suggested that
> completely avoid id conflicts, but you're right it has other problems.
>
> I don't think it's a severe hack to have two executions for the same plugin
> goal in the same phase. For example, let's say I want to generate three jar
> files with different manifests during the package phase. I need to call the
> assembly or jar plugin three times with different configurations. I'm just
> saying it's possible to have this scenario even in a default lifecycle, so
> there is a small possibility of a name conflict even if we use something
> like
> lifecycle-<packaging>-<phase>-<plugin>-<goal>
>
>
>> 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.
>>
>>
> Adding the phase to the ID doesn't prevent name conflicts, since you can
> have the same goal twice in the same phase. I would guess it's actually be
> more common to have a goal twice in the same phase vs. in different phases.
> So I think the goal name is a better qualifier than the phase.
>
Remember, these are the executions that are introduced *through the
lifecycle*
At present, AFAIK, the lifecycle does not provide a means to configure the
same goal differentially, so if you define your own packaging: (e.g.
threejars) and bind jar:jar to the packaging phase three times, they will
all have exactly the same configuration.
We are not talking about executions that are added to the pom, we are
talking about executions coming from the lifecycle.
>
>
> 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]
>
>
