You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2019/07/12 18:30:26 UTC
[shade plugin] common code with gradle shadow plugin?
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>
Re: [shade plugin] common code with gradle shadow plugin?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <le...@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 <rm...@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 <ti...@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 <
> > rmannibucau@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.jorelid@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 <
> > > > rmannibucau@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: lj@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: lj@jguru.se
> | URL: www.jguru.se
> | Phone
> | (skype): jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
>
Re: [shade plugin] common code with gradle shadow plugin?
Posted by Lennart Jörelid <le...@gmail.com>.
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 <rm...@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 <ti...@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 <
> rmannibucau@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.jorelid@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 <
> > > rmannibucau@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: lj@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: lj@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Re: [shade plugin] common code with gradle shadow plugin?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ti...@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 <rm...@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.jorelid@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 <
> > rmannibucau@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: lj@jguru.se
> > > | URL: www.jguru.se
> > > | Phone
> > > | (skype): jgurueurope
> > > | (intl): +46 708 507 603
> > > | (domestic): 0708 - 507 603
> > > +==============================+
> > >
> >
>
Re: [shade plugin] common code with gradle shadow plugin?
Posted by Tibor Digana <ti...@apache.org>.
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 <rm...@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 <le...@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 <
> rmannibucau@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: lj@jguru.se
> > | URL: www.jguru.se
> > | Phone
> > | (skype): jgurueurope
> > | (intl): +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +==============================+
> >
>
Re: [shade plugin] common code with gradle shadow plugin?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <le...@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 <rm...@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: lj@jguru.se
> | URL: www.jguru.se
> | Phone
> | (skype): jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
>
Re: [shade plugin] common code with gradle shadow plugin?
Posted by Lennart Jörelid <le...@gmail.com>.
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 <rm...@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: lj@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Re: [shade plugin] common code with gradle shadow plugin?
Posted by Christian Stein <so...@gmail.com>.
proguard plays in the same realm.
Olivier Lamy <ol...@apache.org> schrieb am Mo., 15. Juli 2019, 13:02:
> Hi
> Sounds a good idea!
>
> On Sat, 13 Jul 2019 at 04:30, Romain Manni-Bucau <rm...@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
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
Re: [shade plugin] common code with gradle shadow plugin?
Posted by Olivier Lamy <ol...@apache.org>.
Hi
Sounds a good idea!
On Sat, 13 Jul 2019 at 04:30, Romain Manni-Bucau <rm...@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
> >
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy