[shade plugin] common code with gradle shadow plugin?

[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 - 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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book

[shade plugin] new transformer for properties?

[Romain Manni-Bucau]

Hello everyone,

I just did a ticket+PR on maven shade plugin to add some properties related
transformers ([1])

The rational is that it is currently tricky to handle all frameworks using
an ordinal like key to solve conflictings entries when merging properties
at runtime.

As you can see in the PR, Apache OpenWebBeans but also Microprofile Config
use this kind of logic to cite a few.

The main implementation logic was just extracted from Apache OpenWebBeans,
only addition was a key configuration to be able to mark a properties as
being already merged manually and therefore to skip all other files - and
fail if two are already merged.

Wdyt?

[1] https://issues.apache.org/jira/browse/MSHADE-322

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book