Well, Maven is already voted to go onto Java6 from now on ;-). Anyway, as I say, I know this isn't for tomorrow. But there's another thing, there was not a lot of exciting features attracting developers between Java 5 and 7 (Coin was too small to really be a major reason for a mainstream migration).
But the traction from lambda, default methods, better type inference, date/time api and so on should help migrate a bit quicker. Let's hope this will happen for some maven components in the next 3 or 4 (and not 10) years if we are optimists. 2013/12/20 Igor Fedorenko <[email protected]> > Java 8 isn't out yet... Maven is still limited java 5... so yeah, we'll > get there... eventually... around 2023 or so. > > Please excuse my sarcasm, I just couldn't resist :-) > > -- > Regards, > Igor > > > On 12/20/2013, 9:40, Baptiste Mathus wrote: > >> Sure, it'll take time, but the good news is Java8's default methods are >> certainly going to progressively cause deprecation of that >> convention/naming convention. >> >> >> 2013/12/20 Igor Fedorenko <[email protected]> >> >> I don't think this is eclipse-specific, but IBM did analysis of >>> java-based API evolution and documented the results at eclipse [1]. >>> >>> The document is quite thorough and I usually use it as a reference when >>> I need to develop API for long-term maintenance. >>> >>> The "2 Convention" is explained in the part 3. >>> >>> [1] http://wiki.eclipse.org/Evolving_Java-based_APIs >>> >>> -- >>> Regards, >>> Igor >>> >>> >>> On 12/19/2013, 23:21, Hervé BOUTEMY wrote: >>> >>> IIUC, numbered interfaces + abstract implementations are roughly Eclipse >>>> way >>>> of solving this requirement about API evolution, isn't it? >>>> >>>> Regards, >>>> >>>> Hervé >>>> >>>> Le jeudi 19 décembre 2013 07:43:03 Igor Fedorenko a écrit : >>>> >>>> On 12/18/2013, 16:42, Olivier Lamy wrote: >>>>> >>>>> 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. >>>>>> >>>>>> >>>>> API clarity and consistency are the reasons I have slight preference to >>>>> explicitly pass parameters to callback methods. >>>>> >>>>> MojoExecutionListener2 will still be required to introduce new callback >>>>> methods, and I like having single/consistent API evolution approach >>>>> that >>>>> covers all scenarios. >>>>> >>>>> When parameters are passed in explicitly, clients do not have to guess >>>>> what is available to them. It also makes it little easier to reason >>>>> what >>>>> API version a client expects just by looking at implements >>>>> MojoExecutionListener vs MojoExecutionListener2. >>>>> >>>>> At any rate, I don't think this matter much in this particular case, so >>>>> I'll introduce event objects in next couple of days. >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Igor >>>>> >>>>> 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] >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------ >>>>> --------- >>>>> 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] >>> >>> >>> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
