if you need to add new parameters in the future, you won't have to add this new MojoExecutionListener2 extends MojoExecutionListener (IMHO it's just ugly but that's my POV) just add those new fields in MojoExecutionEvent etc...
Anyway I only talk by experience and you are the guy who write the code so do as you want. This API can be here for a while so if it's easy to enhance it it's better. BTW I just wonder why you don't want to use this pattern with a bean rather than a method with a lot of parameters. On 19 December 2013 07:32, Igor Fedorenko <[email protected]> wrote: > 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 >> <[email protected]>: >> >>> >>> >>> On 12/16/2013, 7:39, Olivier Lamy wrote: >>>> >>>> On Dec 16, 2013 11:27 PM, "Igor Fedorenko" <[email protected]> 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: [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] > -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
