A PoC being always better than a mail, here is the demo of what I am talking about: https://github.com/rmannibucau/portable-transformer
Both integrations have an IT with should help to see how it works if the readme is not enough 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 mar. 16 juil. 2019 à 01:03, Lennart Jörelid <lennart.jore...@gmail.com> a écrit : > It could make a lot of sense, Romain - and fine in terms of Shadow/Shade > reuse. > > On Mon, Jul 15, 2019 at 8:09 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > It is simpler actually, in pseudo code it is: > > > > <plugin> > > ....shade plugin gav... > > <configuration> > > <transformers> > > <transformer class="org.foo.MyPortableTfr" ....attributes /> > > <transformers> > > </configuration> > > </plugin> > > > > And exactly the same MyPortableTfr in shadow gradle plugin. > > Maven just wraps org....portable.Transformer implementations in native > mvn > > shade Transformers forwarding attributes through a factory in guice or > > equivalent. > > > > Topic is not about bridging mvn and gradle but maven shade and shadow > > plugins together only. > > > > Does it make more sense? > > > > Le lun. 15 juil. 2019 à 17:08, Tibor Digana <tibordig...@apache.org> a > > écrit : > > > > > 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 > > > > > +==============================+ > > > > > > > > > > > > > > > > > -- > > -- > +==============================+ > | 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 > +==============================+ >
