You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2019/08/28 07:56:41 UTC

Switch to from assembly to shade plugin for building Uber-jars?

Hi all,

you know we were having problems in the past with the assembly of the no-deps artifacts.
We solved this by creating a new assembly descriptor with plugins to merge the services properties.
Now while working on our demo for Vegas Roman had problems with these as there seem to be other parts that also require merging.

He came up with a solution to use the shade plugin.

Switching to this has the advantage of not having to maintain an assembly.xml or deploy and release a dedicated assembly artifact.
We could simply define the defaults in the parent and then just use the shade plugin wherever we need it.

I sort of remembered that it was discouraged to use the shade plugin in preference of the assembly in the past, but I could no longer see this confirmed.

So how about switching the uber-jar generator?


Chris

AW: Switch to from assembly to shade plugin for building Uber-jars?

Posted by "Strljic, Matthias Milan" <ma...@isw.uni-stuttgart.de>.

Hi Chris,

+1 also from me.

If it works then is shade ok 😉

Greetings
Matthias Strljic, M.Sc.

Universität Stuttgart
Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW)

Seidenstraße 36
70174 Stuttgart
GERMANY

Tel: +49 711 685-84530
Fax: +49 711 685-74530

E-Mail: matthias.strljic@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de

-----Ursprüngliche Nachricht-----
Von: Christofer Dutz <ch...@c-ware.de> 
Gesendet: Wednesday, August 28, 2019 9:57 AM
An: dev@plc4x.apache.org
Betreff: Switch to from assembly to shade plugin for building Uber-jars?

Hi all,

you know we were having problems in the past with the assembly of the no-deps artifacts.
We solved this by creating a new assembly descriptor with plugins to merge the services properties.
Now while working on our demo for Vegas Roman had problems with these as there seem to be other parts that also require merging.

He came up with a solution to use the shade plugin.

Switching to this has the advantage of not having to maintain an assembly.xml or deploy and release a dedicated assembly artifact.
We could simply define the defaults in the parent and then just use the shade plugin wherever we need it.

I sort of remembered that it was discouraged to use the shade plugin in preference of the assembly in the past, but I could no longer see this confirmed.

So how about switching the uber-jar generator?


Chris

Re: Switch to from assembly to shade plugin for building Uber-jars?

Posted by Christofer Dutz <ch...@c-ware.de>.

So I'm having a strange problem with the maven-shade-plugin.
As soon as I configure it to run, the apache-rat-plugin fails mentioning every binary file in "TARGET" missing the Apache Header :-/

This really sucks.

Chris


Am 28.08.19, 10:12 schrieb "Christofer Dutz" <ch...@c-ware.de>:

    That's just cause you are a shady person :-P
    
    Chris
    
    Am 28.08.19, 09:58 schrieb "Sebastian Rühl" <se...@googlemail.com.INVALID>:
    
        Hi Chris,
        
        My experience is the other way around: shade over assembly.
        
        So from my side go for it +1
        
        Sebastian
        
        > Am 28.08.2019 um 09:56 schrieb Christofer Dutz <ch...@c-ware.de>:
        > 
        > Hi all,
        > 
        > you know we were having problems in the past with the assembly of the no-deps artifacts.
        > We solved this by creating a new assembly descriptor with plugins to merge the services properties.
        > Now while working on our demo for Vegas Roman had problems with these as there seem to be other parts that also require merging.
        > 
        > He came up with a solution to use the shade plugin.
        > 
        > Switching to this has the advantage of not having to maintain an assembly.xml or deploy and release a dedicated assembly artifact.
        > We could simply define the defaults in the parent and then just use the shade plugin wherever we need it.
        > 
        > I sort of remembered that it was discouraged to use the shade plugin in preference of the assembly in the past, but I could no longer see this confirmed.
        > 
        > So how about switching the uber-jar generator?
        > 
        > 
        > Chris

Re: Switch to from assembly to shade plugin for building Uber-jars?

Posted by Christofer Dutz <ch...@c-ware.de>.

That's just cause you are a shady person :-P

Chris

Am 28.08.19, 09:58 schrieb "Sebastian Rühl" <se...@googlemail.com.INVALID>:

    Hi Chris,
    
    My experience is the other way around: shade over assembly.
    
    So from my side go for it +1
    
    Sebastian
    
    > Am 28.08.2019 um 09:56 schrieb Christofer Dutz <ch...@c-ware.de>:
    > 
    > Hi all,
    > 
    > you know we were having problems in the past with the assembly of the no-deps artifacts.
    > We solved this by creating a new assembly descriptor with plugins to merge the services properties.
    > Now while working on our demo for Vegas Roman had problems with these as there seem to be other parts that also require merging.
    > 
    > He came up with a solution to use the shade plugin.
    > 
    > Switching to this has the advantage of not having to maintain an assembly.xml or deploy and release a dedicated assembly artifact.
    > We could simply define the defaults in the parent and then just use the shade plugin wherever we need it.
    > 
    > I sort of remembered that it was discouraged to use the shade plugin in preference of the assembly in the past, but I could no longer see this confirmed.
    > 
    > So how about switching the uber-jar generator?
    > 
    > 
    > Chris

Re: Switch to from assembly to shade plugin for building Uber-jars?

Posted by Sebastian Rühl <se...@googlemail.com.INVALID>.

Hi Chris,

My experience is the other way around: shade over assembly.

So from my side go for it +1

Sebastian

> Am 28.08.2019 um 09:56 schrieb Christofer Dutz <ch...@c-ware.de>:
> 
> Hi all,
> 
> you know we were having problems in the past with the assembly of the no-deps artifacts.
> We solved this by creating a new assembly descriptor with plugins to merge the services properties.
> Now while working on our demo for Vegas Roman had problems with these as there seem to be other parts that also require merging.
> 
> He came up with a solution to use the shade plugin.
> 
> Switching to this has the advantage of not having to maintain an assembly.xml or deploy and release a dedicated assembly artifact.
> We could simply define the defaults in the parent and then just use the shade plugin wherever we need it.
> 
> I sort of remembered that it was discouraged to use the shade plugin in preference of the assembly in the past, but I could no longer see this confirmed.
> 
> So how about switching the uber-jar generator?
> 
> 
> Chris