Hi Lenant,
The plugin looks like this in POM:
<plugin>
... implements="pkg.ResolverImpl"...
~~~ plugin dependencies ~~~
<dependency>
groupId,artifactId,version ~~~ for ~~~ artifact ~~~ having ~~~
pkg.ResolverImpl.class ~~~
</dependency>
</plugin>
So " implements" is already the extention style.
The class ResolverImpl should inherit the API from a separate API artifact.
So the separation concern (plugin implementation and API) means that the
SPI is not need and the patch is directly applied to the particular plugin
(and plugin execution), not the whole JVM as in case of SPIs.
If somebody does not want to use POM, still the API is the keypoint.
Somebody who deploys the artifact in dependency has to write facade or
adapter between this API in Maven and Gradle or whatever else.
I thik this is meant by Romain.
Honestly, i am not a fan or embedding these Gradle adapters in Maven, and
quite pessimistic, because doing such things would mean that the API
(whatever it means) is a "beton". One endpoint wins and second will loose
because any change breaks the world. So therefore a 3rd party (equal devs
from Maven + Gradle project) should be the adapter artifact/project, and
his speed of development and release matters how fast he reacts on changes
from both.
Cheers
Tibor
On Mon, Jul 15, 2019 at 3:13 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
> Hello Lennart,
>
> Do you have an example where transformer abstraction can be messing for
> existing transformers?
> Goal here is not to abstract the build system but the user extensions for
> two particular plugins.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 15 juil. 2019 à 14:58, Lennart Jörelid <lennart.jore...@gmail.com>
> a écrit :
>
> > I'd say it would - nowadays - always be a good idea to split the plugins
> > into an API-or-SPI part where the meat of the functionality is located -
> > and an Implementation-Per-Build-System part (i.e. an *x-spi*,
> > *x-maven-plugin* and *x-gradle-plugin* type of structure).
> >
> > However, the underpinnings of most known build systems would be in need
> of
> > an abstraction layer themselves for those kinds of operation to work
> > smoothly... and at the moment they are not exactly harmonized to a level
> > where cross-buildsystem development is necessarily trivial. As an
> example,
> > compare the semantics for transitive dependencies between Maven and
> Gradle.
> > It is currently not trivial to - say - modify the execution environment
> for
> > a plugin in a consistent manner across build systems.
> >
> > That being said, I guess there is quite a bit of simplification to be
> > gained in terms of reusing implemented algorithms, even if adapting said
> > implementation to Maven or Gradle or SBT or ... whatever ... quickly can
> > get rather messy.
> >
> > On Fri, Jul 12, 2019 at 8:30 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hello (again) everyone,
> > >
> > > Gradle shadow plugin - kind of shade plugin for gradle - forked Apache
> > > Maven Shade ResourceTransformer to enrich it ([1]).
> > >
> > > By itself it is ok but I wonder if we couldn't launch a kind of
> > abstraction
> > > to let people code once and use the transformer - needed by libraries -
> > in
> > > both plugins and build tools.
> > >
> > > It would consist of the following parts:
> > >
> > > 1. Transformer API (likely something very close of our current resource
> > > transformer),
> > > 2. Some common transformer using 1.,
> > > 3. A generic ResourceTransformerWrapper able to instantiate a
> Transformer
> > > coded with 1. and wire its lifecycle in a plain shade
> ResourceTransformer
> > > (likely the same on shadow side).
> > >
> > > Any interest doing that here?
> > > If so, should it be hosted in maven-shade-plugin project making it a
> > > multi-module project?
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/johnrengelman/shadow/blob/master/src/main/groovy/com/github/jengelman/gradle/plugins/shadow/transformers/Transformer.groovy#L26
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> >
> >
> > --
> >
> > --
> > +==============================+
> > | 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
> > +==============================+
> >
>
