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]
