Oh - and I see I forgot the surrounding transformers element within the
configuration, but we all realize that, right? To make this work with
maven's DI, it should have read:
<configuration>
<transformers>
<coffeCooker implementation="your.coffee.ExtensionCooker"/>
<breadBaker implementation="your.bread.Processor"/>
....
</transformers>
</configuration>
2015-01-16 17:17 GMT+01:00 Lennart Jörelid <lennart.jore...@gmail.com>:
> 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
> +==============================+
>
>
--
--
+==============================+
| 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
+==============================+
