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]
