I usually handle the case with replacing default plugin functionality with
non-mandatory (and, hopefully, well-documented) plugin parameters, similar
to the following:
*Within a locally defined AbstractMojo subclass:*
protected abstract List<Transformer> getTransformers();
*In the concrete Mojo (which extends the locally defined AbstractMojo
subclass):*
@Parameter
private Transformer[] transformers;
@Override
protected List<Transformer> getTransformers() {
if(transformers == null || transformers.length == 0) {
// Fallback to a defined standard of transformers, defined within this
Mojo.
return STANDARD_TRANSFORMERS;
}
// All done.
return Arrays.<Transformer>asList(transformers);
}
This ensures that the call to getTransformers() always returns a non-null
result, and that any user-supplied configuration fully replaces the
defaults. If user configuration should be treated as an *extension* to the
locally provided STANDARD_TRANSFORMERS, I adjust the logic in the
getTransformers method - and the documentation - accordingly.
This approach is programmatically trivial, but requires updated and
sensible documentation (Which are the standard Transformers? Does
user-supplied configuration replace standards or add to them?). I fully
understand that there are no maven-defined standards for this behaviour -
it is implemented in every plugin that needs it.
2015-01-16 9:36 GMT+01:00 Kristian Rosenvold <kristian.rosenv...@gmail.com>:
> Lennart;
>
> Is there a good solution for having the user-provided implementation
> *replace* the built-in one ?
>
>
> Kristian
>
>
> 2015-01-15 21:29 GMT+01:00 Lennart Jörelid <lennart.jore...@gmail.com>:
> > I believe that it is important to let the POM serve as a configuration
> (for
> > a set of Plugin-clad operations).
> > If we permit the POM to be the host of scripts, I suggest that overall
> > build stability would be compromised.
> >
> > If one wants to implement a chain-of-command or extension pattern within
> a
> > Plugin, it is simple enough.
> >
> >
> > - Define an interface (say Transformer) holding methods defining a
> > behaviour
> > - Define an array or list of these Transformers within your plugin, as
> > shown below.
> > - In your execute() method, simply call them in order.
> > - You have now defined a behaviour; Maven's standard mechanics permit
> > you to inject several different implementations
> >
> >
> >
> > @Parameter
> > private Transformer[] transformer;
> >
> > with the configuration
> >
> > <configuration>
> > <coffeCooker implementation="your.coffee.ExtensionCooker"/>
> > <breadBaker implementation="your.bread.Processor"/>
> > ....
> > </configuration>
> >
> > This may not be a very obvious way to implement an extension, but it
> > certainly works. The enforcer plugin, which was mentioned above uses this
> > type of mechanics to permit injecting custom rules (of type
> EnforcerRule).
> >
> > Would this type of extension cover the needs? Or am I missing your point,
> > Tibor?
> >
> >
> > 2015-01-15 21:09 GMT+01:00 Jason van Zyl <ja...@takari.io>:
> >
> >> Ok, stay within what's here.
> >>
> >> I posit that the default lifecycle and binding to it with mojos provides
> >> sufficient means of extension. So we have a lifecycle and at the other
> >> extreme in Ant and Gradle we have an arbitrary DAG. Along that spectrum
> I'm
> >> not sure I understand what you think the problem is.
> >>
> >> I also posit that you can make Java-based extension mechanisms today.
> >> Maybe not scriptable ones but you can provide extension points.
> >>
> >> I gather that the "whole issue" you're talking about is it
> extensibility?
> >> If so I was only trying to draw attention to facilities that are present
> >> you may not be familiar with.
> >>
> >> On Jan 15, 2015, at 2:54 PM, Kristian Rosenvold <
> >> kristian.rosenv...@gmail.com> wrote:
> >>
> >> > Jason;
> >> >
> >> > We have been talking at length about what we think is wrong with the
> >> > plugin model in this thread. I'm happy to hear that you have solved
> >> > things within the existing model in Takari. From what I've picked up
> >> > It sounds like you have made an even greater monotlith than what we
> >> > already have, so it appears you may not consider this whole issue a
> >> > problem.
> >> >
> >> > The solutions you describe are things we know about. I still consider
> >> > this to be an important problem; maybe the most important problem we
> >> > are facing.
> >> >
> >> > Kristian
> >> >
> >> > 2015-01-15 20:36 GMT+01:00 Jason van Zyl <ja...@takari.io>:
> >> >> What do you think is unclear about the default lifecycle that you
> >> augment by adding new executions to a particular phase in the lifecycle?
> >> You can also make your own lifecycle if you wish but for the most part
> the
> >> default lifecycle is sufficient. Or even cahnge all the bindings for the
> >> default lifecycle. For the Takari Lifecycle which has completely
> different
> >> implementations we didn't need any changes to the default lifecycle we
> just
> >> bound new implementations.
> >> >>
> >> >> There is also nothing stopping you from adding extensions points to
> >> plugins. You can do that today, the enforcer plugin being a case in
> point.
> >> This mechanism already exists where you can create an extension point
> as a
> >> collection that gets injected into a plugin, and new implementations of
> the
> >> extension will be loaded dynamically when added as dependencies to that
> >> plugin in the POM. We can add this to any plugin today. If you wanted to
> >> provide an extension point to the maven-jar-plugin to filter the
> manifest
> >> before writing it into the JAR you can do that now.
> >> >>
> >> >> On Jan 15, 2015, at 5:57 AM, Tibor Digana <tibordig...@apache.org>
> >> wrote:
> >> >>
> >> >>> Maybe Jason can bring some light into this discussion.
> >> >>> Jason?
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> View this message in context:
> >>
> http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823611.html
> >> >>> Sent from the Maven Developers mailing list archive at Nabble.com.
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >> >>>
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Jason
> >> >>
> >> >> ----------------------------------------------------------
> >> >> Jason van Zyl
> >> >> Founder, Apache Maven
> >> >> http://twitter.com/jvanzyl
> >> >> http://twitter.com/takari_io
> >> >> ---------------------------------------------------------
> >> >>
> >> >> happiness is like a butterfly: the more you chase it, the more it
> will
> >> >> elude you, but if you turn your attention to other things, it will
> come
> >> >> and sit softly on your shoulder ...
> >> >>
> >> >> -- Thoreau
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >> >
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder, Apache Maven
> >> http://twitter.com/jvanzyl
> >> http://twitter.com/takari_io
> >> ---------------------------------------------------------
> >>
> >> First, the taking in of scattered particulars under one Idea,
> >> so that everyone understands what is being talked about ... Second,
> >> the separation of the Idea into parts, by dividing it at the joints,
> >> as nature directs, not breaking any limb in half as a bad carver might.
> >>
> >> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
> >
> > --
> >
> > --
> > +==============================+
> > | Bästa hälsningar,
> > | [sw. "Best regards"]
> > |
> > | Lennart Jörelid
> > | EAI Architect & Integrator
> > |
> > | jGuru Europe AB
> > | Mölnlycke - Kista
> > |
> > | Email: l...@jguru.se
> > | URL: www.jguru.se
> > | Phone
> > | (skype): jgurueurope
> > | (intl): +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +==============================+
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
