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