Return-Path: X-Original-To: apmail-maven-dev-archive@www.apache.org Delivered-To: apmail-maven-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 282BC10035 for ; Fri, 16 Jan 2015 16:24:44 +0000 (UTC) Received: (qmail 10071 invoked by uid 500); 16 Jan 2015 16:24:45 -0000 Delivered-To: apmail-maven-dev-archive@maven.apache.org Received: (qmail 9983 invoked by uid 500); 16 Jan 2015 16:24:45 -0000 Mailing-List: contact dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Developers List" Reply-To: "Maven Developers List" Delivered-To: mailing list dev@maven.apache.org Received: (qmail 9966 invoked by uid 99); 16 Jan 2015 16:24:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Jan 2015 16:24:45 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lennart.jorelid@gmail.com designates 209.85.216.46 as permitted sender) Received: from [209.85.216.46] (HELO mail-qa0-f46.google.com) (209.85.216.46) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Jan 2015 16:24:41 +0000 Received: by mail-qa0-f46.google.com with SMTP id j7so16027134qaq.5 for ; Fri, 16 Jan 2015 08:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Tl23lqM9l7CsE9dCs70t9IjaCpeNM4z0WaZ2GjKxDAI=; b=b1xkNks6/uzPSYGPZa1jLwy3jMldD/HZYZnPgZpYpiGS0QcSYSww7hODH1ovm9EVV0 8DR9c9bPAXVtKuwUImobSFaoHpjbCW5KmKMWMdqgx5+VxaWlixeWBIY1AgR/1cioGkbV ZYJ2d6DmvL3cM/8gr10rk0HY2/CmWGL0EsNZcWBP/DrW/ODqjoMhl4DZ33uz8cOflEAu /elif4l5Lkdh0WlGryQhG1dHAk6VnKgORk5lDdJivhEv5syJ+e4iXW8IO1WUwwBeJMMd 5MywHSHn+Gnt0CJHfhrdJfjGMRtTN1a7P6q2w8S095fYuEUCnYpn5R4YmHnnGF9t33/v LYng== MIME-Version: 1.0 X-Received: by 10.224.43.72 with SMTP id v8mr19397573qae.30.1421425324912; Fri, 16 Jan 2015 08:22:04 -0800 (PST) Received: by 10.140.102.14 with HTTP; Fri, 16 Jan 2015 08:22:04 -0800 (PST) In-Reply-To: References: <1421258651886-5823548.post@n5.nabble.com> <1421274813894-5823565.post@n5.nabble.com> <1421319434601-5823611.post@n5.nabble.com> <077F2AAA-3748-45E7-B5A5-C680454BD2D4@takari.io> <950F4E64-253F-4F05-9EA0-2672C311152D@takari.io> Date: Fri, 16 Jan 2015 17:22:04 +0100 Message-ID: Subject: Re: Plugable/Softcoded/Customized Maven Plugins From: =?UTF-8?Q?Lennart_J=C3=B6relid?= To: Maven Developers List Content-Type: multipart/alternative; boundary=047d7bdc9f7090f4bb050cc75f87 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bdc9f7090f4bb050cc75f87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: .... 2015-01-16 17:17 GMT+01:00 Lennart J=C3=B6relid = : > I usually handle the case with replacing default plugin functionality wit= h > non-mandatory (and, hopefully, well-documented) plugin parameters, simila= r > to the following: > > *Within a locally defined AbstractMojo subclass:* > protected abstract List getTransformers(); > > *In the concrete Mojo (which extends the locally defined AbstractMojo > subclass):* > @Parameter > private Transformer[] transformers; > > @Override > protected List getTransformers() { > > if(transformers =3D=3D null || transformers.length =3D=3D 0) { > // Fallback to a defined standard of transformers, defined within > this Mojo. > return STANDARD_TRANSFORMERS; > } > > // All done. > return Arrays.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 >: > >> 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=C3=B6relid : >> > 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 perm= it >> > you to inject several different implementations >> > >> > >> > >> > @Parameter >> > private Transformer[] transformer; >> > >> > with the 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 : >> > >> >> 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 othe= r >> >> 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.rosenvold@gmail.com> wrote: >> >> >> >> > Jason; >> >> > >> >> > We have been talking at length about what we think is wrong with th= e >> >> > plugin model in this thread. I'm happy to hear that you have solve= d >> >> > things within the existing model in Takari. From what I've picked u= p >> >> > 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 consid= er >> >> > this to be an important problem; maybe the most important problem w= e >> >> > are facing. >> >> > >> >> > Kristian >> >> > >> >> > 2015-01-15 20:36 GMT+01:00 Jason van Zyl : >> >> >> 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 par= t >> 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 w= e >> just >> >> bound new implementations. >> >> >> >> >> >> There is also nothing stopping you from adding extensions points t= o >> >> 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 th= at >> >> 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 >> >> 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-Plu= gins-tp5823365p5823611.html >> >> >>> Sent from the Maven Developers mailing list archive at Nabble.com= . >> >> >>> >> >> >>> >> --------------------------------------------------------------------- >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >> >> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org >> >> >> For additional commands, e-mail: dev-help@maven.apache.org >> >> >> >> >> > >> >> > -------------------------------------------------------------------= -- >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >> >> > For additional commands, e-mail: dev-help@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 migh= t. >> >> >> >> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >> >> For additional commands, e-mail: dev-help@maven.apache.org >> >> >> >> >> > >> > >> > -- >> > >> > -- >> > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+ >> > | B=C3=A4sta h=C3=A4lsningar, >> > | [sw. "Best regards"] >> > | >> > | Lennart J=C3=B6relid >> > | EAI Architect & Integrator >> > | >> > | jGuru Europe AB >> > | M=C3=B6lnlycke - Kista >> > | >> > | Email: lj@jguru.se >> > | URL: www.jguru.se >> > | Phone >> > | (skype): jgurueurope >> > | (intl): +46 708 507 603 >> > | (domestic): 0708 - 507 603 >> > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >> For additional commands, e-mail: dev-help@maven.apache.org >> >> > > > -- > > -- > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ > | B=C3=A4sta h=C3=A4lsningar, > | [sw. "Best regards"] > | > | Lennart J=C3=B6relid > | EAI Architect & Integrator > | > | jGuru Europe AB > | M=C3=B6lnlycke - Kista > | > | Email: lj@jguru.se > | URL: www.jguru.se > | Phone > | (skype): jgurueurope > | (intl): +46 708 507 603 > | (domestic): 0708 - 507 603 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ > > --=20 -- +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ | B=C3=A4sta h=C3=A4lsningar, | [sw. "Best regards"] | | Lennart J=C3=B6relid | EAI Architect & Integrator | | jGuru Europe AB | M=C3=B6lnlycke - Kista | | Email: lj@jguru.se | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ --047d7bdc9f7090f4bb050cc75f87--