maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: [1/2] git commit: MNG-5549 introduced MojoExecutionListener and ProjectExecutionListener
Date Wed, 18 Dec 2013 21:01:15 GMT
Just an example:
http://maven.apache.org/maven-release/maven-release-manager/apidocs/org/apache/maven/shared/release/ReleaseManager.html

I'm sure nobody suggested to change the method signatures in the  
beginning, but at some moment one had to.
The result right now is a huge number of overloaded methods.
Using the Event object is just a way to ensure you won't end up with  
something like this: an ultimate ugly API.

Robert

Op Wed, 18 Dec 2013 21:32:11 +0100 schreef Igor Fedorenko  
<igor@ifedorenko.com>:

> Olivier, Robert,
>
> Do you insist on event objects or can live with my initial  
> implementation?
>
> I am not sure if I explained this clearly enough, but I never suggested
> changing existing method signatures in the future. If we need to add
> new parameters or new callback methods in the future, we can introduce
> new listener interface
>
>     MojoExecutionListener2 extends MojoExecutionListener
>
> and add new method to the new interface. Clients that implement
> original MojoExecutionListener will continue to work as is.
>
> --
> Regards,
> Igor
>
> On 12/16/2013, 17:04, Robert Scholte wrote:
>> There are 2 issues here:
>> - What if one of the current methods require an extra Object/argument?
>> - What if we need an extra method.
>>
>> The first one can be solved with the suggestion of Olivier. The method
>> signature will stay we same, we just extend the Event object passed.
>> For the latter you need to introduce a new interface of require Java8,
>> which will support default interface implementations.
>>
>> Keeping a stable method signature if much more worth to me then the not
>> directly visible parameters of the event object.
>> If the current methods require different arguments, I would consider
>> different Events.
>>
>> Robert
>>
>> Op Mon, 16 Dec 2013 16:45:14 +0100 schreef Igor Fedorenko
>> <igor@ifedorenko.com>:
>>
>>>
>>>
>>> On 12/16/2013, 7:39, Olivier Lamy wrote:
>>>> On Dec 16, 2013 11:27 PM, "Igor Fedorenko" <igor@ifedorenko.com>  
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 12/16/2013, 5:27, Olivier Lamy wrote:
>>>>>>>
>>>>>>> +/**
>>>>>>>> + * Extension point that allows build extensions observe
and
>>>>>>>> possibly
>>>> veto mojo executions.
>>>>>>>> + *
>>>>>>>> + * @see WeakMojoExecutionListener
>>>>>>>> + * @since 3.1.2
>>>>>>>> + * @provisional This interface is part of work in progress
and
>>>>>>>> can be
>>>> changed or removed without notice.
>>>>>>>> + */
>>>>>>>> +public interface MojoExecutionListener
>>>>>>>> +{
>>>>>>>> +    public void beforeMojoExecution( MavenSession session,
>>>> MavenProject project, MojoExecution execution, Mojo mojo )
>>>>>>>> +        throws MojoExecutionException;
>>>>>>>> +
>>>>>>>> +    public void afterMojoExecutionSuccess( MavenSession
session,
>>>> MavenProject project, MojoExecution execution,
>>>>>>>> +                                           Mojo mojo )
>>>>>>>> +        throws MojoExecutionException;
>>>>>>>> +
>>>>>>>> +    public void afterExecutionFailure( MavenSession session,
>>>> MavenProject project, MojoExecution execution, Mojo mojo,
>>>>>>>> +                                       Throwable cause );
>>>>>>>> +}
>>>>>>
>>>>>> I wonder if it will be easier for future enhancement to use a bean
>>>>>> with fields for those objects.
>>>>>> MojoExecutionListenerEvent with getMavenSession() etc...
>>>>>>
>>>>>> Maybe will be simpler to add getter to this bean than changing the
>>>>>> signature of the interface.
>>>>>> ?
>>>>>>
>>>>>>
>>>>>
>>>>> Good idea. Any objections against MojoExecutionEvent and
>>>>> ProjectExecutionEvent names?
>>>>
>>>> Sounds good
>>>>
>>>
>>> So I tried this and I am not sure I like the result.
>>>
>>> Event objects make it harder to see (at a glance) what parameters are
>>> provided to the callbacks, especially because not all callbacks have  
>>> the
>>> same set of parameters. This muddies the API, I think.
>>>
>>> Event objects make it possible to add new callback parameters but won't
>>> help if we need to add new callbacks.
>>>
>>> I think MojoExecutionListener2/3/4/etc provides reasonably good
>>> evolution path for this API.
>>>
>>> What do you think?
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message