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 +==============================+
