Re: [shade plugin] common code with gradle shadow plugin?

2019-07-17 Thread Romain Manni-Bucau
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

Re: [shade plugin] common code with gradle shadow plugin?

2019-07-15 Thread Lennart Jörelid
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 wrote: > It is simpler actually, in pseudo code it is: > > >shade plugin gav... > > > > > > > > And exactly the same MyPortableTfr

Re: [shade plugin] common code with gradle shadow plugin?

2019-07-15 Thread Romain Manni-Bucau
It is simpler actually, in pseudo code it is: shade plugin gav... And exactly the same MyPortableTfr in shadow gradle plugin. Maven just wraps orgportable.Transformer implementations in native mvn shade Transformers forwarding attributes through a factory in

Re: [shade plugin] common code with gradle shadow plugin?

2019-07-15 Thread Tibor Digana
Hi Lenant, The plugin looks like this in POM: ... implements="pkg.ResolverImpl"... ~~~ plugin dependencies ~~~ groupId,artifactId,version ~~~ for ~~~ artifact ~~~ having ~~~ pkg.ResolverImpl.class ~~~ So " implements" is already the extention style. The class

Re: [shade plugin] common code with gradle shadow plugin?

2019-07-15 Thread Romain Manni-Bucau
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 | Blog

Re: [shade plugin] common code with gradle shadow plugin?

2019-07-15 Thread Lennart Jörelid
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

Re: [shade plugin] common code with gradle shadow plugin?

2019-07-15 Thread Christian Stein
proguard plays in the same realm. Olivier Lamy schrieb am Mo., 15. Juli 2019, 13:02: > Hi > Sounds a good idea! > > On Sat, 13 Jul 2019 at 04:30, Romain Manni-Bucau > wrote: > > > Hello (again) everyone, > > > > Gradle shadow plugin - kind of shade plugin for gradle - forked Apache > > Maven

Re: [shade plugin] common code with gradle shadow plugin?

2019-07-15 Thread Olivier Lamy
Hi Sounds a good idea! On Sat, 13 Jul 2019 at 04:30, Romain Manni-Bucau 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

[shade plugin] common code with gradle shadow plugin?

2019-07-12 Thread Romain Manni-Bucau
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 -