Re: Switch to from assembly to shade plugin for building Uber-jars?
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" : That's just cause you are a shady person :-P Chris Am 28.08.19, 09:58 schrieb "Sebastian Rühl" : 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 : > > 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?
That's just cause you are a shady person :-P Chris Am 28.08.19, 09:58 schrieb "Sebastian Rühl" : 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 : > > 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?
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 : > > 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
