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

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 i

Re: ITs in maven-release

Hi Tibor, will look at the Readmes, and see what I can do, though I didn't came to look at them in the first place. Not sure what you meant with the CLI documentation, though.  Maybe you can help me with that in direct mail. As to the Java SE roadmaps [0]: JDK 7 Update 80 was the last free upd

Re: Naming of ITs in maven-release

Hi Olivier, yeah, could do that.  Would be a great idea.  But i am stuck on what to put into this IT: RemoveScmTag does what the name suggests:  it uses maven-scm to remove the tag during release:rollback. In the unit tests maven-scm is mocked away and i think in the ITs of maven-release maven-

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

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 gu

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

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 Resolver

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

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?

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 m

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

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 Sh

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

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 ki