Re: [DISCUSS] Remove shaded client JARS

[Robbie Gemmell <ro...@gmail.com>]

I'd like to raise again the middle-ground of removing these
partially-shaded uber jars from the assembly.

I think it would be better for all the folks who dont use them,
removing the triple duplication of half the deps in the assembly, and
yet also simple for the folks that do use them as they can still
easily grab the artifact directly without having to download the
broker and 2 other clients they dont want. E.g when Clebert added the
updated generateddocs around client classpath [1] I tweaked the docs
to include a note of being able to grab these -all artifacts from
Maven Central.

[1] https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.html

On Mon, 8 Aug 2022 at 12:00, Robbie Gemmell <ro...@gmail.com> wrote:
>
> Not shading them makes the likelihood of clashing-dependencies worse,
> i.e that another component being used with it might use (or itself
> similarly include) a different version of something being ubered
> without shading, leading to potential for a broken classpath that
> manifests either very explicitly or in strange unseen ways. Thats what
> made netty drop their uber jar, as mixed use of the -all and
> individual netty deps of different versions by different components
> would routinely cause clashes due to not being alignable by tooling.
> As it happens, the -all client jars are apparently not shading netty,
> so nothing else using netty can currently be used along with them
> without risking a broken classpath. Which is harder to see and resolve
> since netty is hidden away inside the jar.
>
> In short, if not shading anything, to me that makes it seem there
> would be even less point in having them at all (it being even simpler
> for folks to build their own non-shaded uber jar than a shaded one),
> and even more likelihood it causes people using them problems.
>
> I mentioned it already in my other replym but adding a quick note now
> too as it relates...regardless whats done here I think we should
> remove them from the assembly, it would be better for those not using
> them and simple for those doing so.
>
> On Mon, 1 Aug 2022 at 15:59, Clebert Suconic <cl...@gmail.com> wrote:
> >
> > I would be fine to keep the *all clients (given I don't see a
> > consensus here), however the issue I see is with the shading and class
> > renaming.
> >
> >
> > if users don't want to use maven and just use our *all clients, they
> > should not mix with other classes and assure all risks. Right now we
> > shade these jars and we don't really test if there's anything wrong
> > with the transformations.
> >
> > We now have improved the documentation a little bit, and we should
> > perhaps just stop shading jars.. just keep everything as they are on
> > the uber jar.
> >
> > On Mon, Aug 1, 2022 at 10:58 AM Clebert Suconic
> > <cl...@gmail.com> wrote:
> > >
> > > I just sent a PR that will update the client classPath and generate the client dependencies with a maven plugin that I just wrote:
> > >
> > > https://github.com/apache/activemq-artemis/pull/4162
> > >
> > > On Fri, Jul 29, 2022 at 12:54 PM Arthur Naseef <ar...@amlinv.com> wrote:
> > > >
> > > > Making use simple for users is a good thing.  On the other hand, there are
> > > > a lot of target environments that could use different tweaks.  Our
> > > > dependency-management tool is maven.
> > > >
> > > > If folks want to work outside of maven, that's their choice, but then
> > > > dependency management becomes a problem for that case.
> > > >
> > > > Is it worth the effort, and added complexity, to maintain the uber jar?
> > > >
> > > > Art
> > > >
> > > > On Wed, Jul 27, 2022 at 7:57 AM Michael André Pearce
> > > > <mi...@me.com.invalid> wrote:
> > > >
> > > > > So as the person who added the shaded jars, this was a requirement to make
> > > > > it far easier for those who DO NOT use tools like maven to be able to build
> > > > > an application without having to copy a large dependency tree of libs,
> > > > > which yes for maven or gradle is fine as they handle the dependency tree,
> > > > > as those tools do this. But unfortunately we don't live in a perfect world,
> > > > > and providing the shaded allows those users to use the client.
> > > > >
> > > > > Im happy to look at why moving logging to slf4j brings an issue, im unsure
> > > > > why it does tbh, its just another lib, and as long as you shade correctly
> > > > > it should be fine, ive seen it shaded in many other projects.
> > > > >
> > > > > With this i am going on leave for a bit, so unlikely i will get to have a
> > > > > look at it for a week or two.
> > > > >
> > > > > Best
> > > > > Mike
> > > > >
> > > > > On 26 Jul 2022, at 21:44, Justin Bertram <jb...@apache.org> wrote:
> > > > >
> > > > >
> > > > > To be clear, the documentation already exists [1]. It just needs to be
> > > > > updated with the aforementioned details when the uber jars are removed.
> > > > >
> > > > >
> > > > > Justin
> > > > >
> > > > > [1]
> > > > >
> > > > > https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.html
> > > > >
> > > > > On Tue, Jul 26, 2022 at 3:39 PM Clebert Suconic <clebert.suconic@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > sure, of course we need to update the docs in relation to anything
> > > > > these removed jars. What I meant was we need to document the jars that
> > > > > are required independently of removing the jars.. if someone wants to
> > > > > use the client jars the client dependency should be documented anyway.
> > > > > that's what I meant
> > > > >
> > > > > On Tue, Jul 26, 2022 at 3:25 PM Justin Bertram <jb...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > I'm not sure what you mean by "independent issue." If we remove the uber
> > > > > > jars then the docs have to be updated. The two things are directly
> > > > > related,
> > > > > > right?
> > > > > >
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > On Tue, Jul 26, 2022 at 2:13 PM Clebert Suconic <
> > > > > clebert.suconic@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I think that’s an independent issue. The doc would need to be updated
> > > > > > > anyways.
> > > > > > >
> > > > > > > On Tue, Jul 26, 2022 at 2:40 PM Justin Bertram <jb...@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Yes, the documentation needs to be clear. This is a usability issue.
> > > > > > > >
> > > > > > > > Even if you did a "mvn dependency:list" you'd get a list including
> > > > > > > optional
> > > > > > > > and test dependencies. Also, there would be potentially unnecessary
> > > > > > > > dependencies (e.g. netty-transport-native-kqueue even if you aren't
> > > > > on a
> > > > > > > > Mac).
> > > > > > > >
> > > > > > > >
> > > > > > > > Justin
> > > > > > > >
> > > > > > > > On Tue, Jul 26, 2022 at 1:30 PM Clebert Suconic <
> > > > > > > clebert.suconic@gmail.com
> > > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > the pom on artemis-core-client, artemis-jms-client, and
> > > > > > > > > artemis-jakarta-client... They will include all the needed
> > > > > > > > > dependencies, right?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > what is the issue? to have a clear text on the docs?
> > > > > > > > >
> > > > > > > > > On Tue, Jul 26, 2022 at 2:01 PM Justin Bertram <
> > > > > jbertram@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > The original impetus for the uber jar was ARTEMIS-1129. The issue
> > > > > > > there
> > > > > > > > > was
> > > > > > > > > > that it wasn't clear what jars were needed on the client. If we
> > > > > > > remove
> > > > > > > > > the
> > > > > > > > > > uber jars then we need to update the documentation to make
> > > > > crystal
> > > > > > > > clear
> > > > > > > > > > what jars are needed on the client, including details about what
> > > > > jars
> > > > > > > > may
> > > > > > > > > > be optional depending on which functionality the client uses.
> > > > > > > > > >
> > > > > > > > > > I'm not necessarily against it, but removing the uber jar is
> > > > > probably
> > > > > > > > > going
> > > > > > > > > > to sting for a handful of users. Anything we can do to alleviate
> > > > > that
> > > > > > > > > will
> > > > > > > > > > help. Maybe we could generate a text file in lib/client instead
> > > > > of
> > > > > > > the
> > > > > > > > > uber
> > > > > > > > > > jars to help users who expect them to be there. The text could
> > > > > list
> > > > > > > the
> > > > > > > > > > jars required for the client's classpath.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Justin
> > > > > > > > > >
> > > > > > > > > > [1] https://issues.apache.org/jira/browse/ARTEMIS-1129
> > > > > > > > > >
> > > > > > > > > > On Tue, Jul 26, 2022 at 8:40 AM Clebert Suconic <
> > > > > > > > > clebert.suconic@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > We currently deploy these following shaded uber jars with
> > > > > ActiveMQ
> > > > > > > > > Artemis.
> > > > > > > > > > >
> > > > > > > > > > > artemis-jms-client-all
> > > > > > > > > > > artemis-core-client-all
> > > > > > > > > > > artemis-jakarta-client-all
> > > > > > > > > > >
> > > > > > > > > > > We are in the process of removing jboss-logging, and replacing
> > > > > it
> > > > > > > by
> > > > > > > > > > > SLF4j /LOG4J on a separate branch, and we will probably make a
> > > > > > > switch
> > > > > > > > > > > on the branch as 3.0.
> > > > > > > > > > >
> > > > > > > > > > > I never really liked these shaded jars as part of the
> > > > > > > distribution. I
> > > > > > > > > > > would be inclined to remove them on a switch for 3.0 anyways,
> > > > > and
> > > > > > > now
> > > > > > > > > > > we are having a build issue,
> > > > > > > > > > > as they will fail (on a second build) shading
> > > > > > > apache-commons-logging:
> > > > > > > > > > >
> > > > > > > > > > > ERROR] Failed to execute goal
> > > > > > > > > > > org.apache.maven.plugins:maven-shade-plugin:3.3.0:shade
> > > > > (default)
> > > > > > > on
> > > > > > > > > > > project artemis-core-client-all: Error creating shaded jar:
> > > > > > > duplicate
> > > > > > > > > > > entry: META-INF/services/
> > > > > org.apache.activemq.artemis.shaded.org
> > > > > > > > > > > .apache.commons.logging.LogFactory
> > > > > > > > > > > -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the
> > > > > > > > > > > errors, re-run Maven with the -e switch. [ERROR] Re-run Maven
> > > > > using
> > > > > > > > > > > the -X switch to enable full debug logging. [ERROR] [ERROR]
> > > > > For
> > > > > > > more
> > > > > > > > > > > information about the errors and possible solutions, please
> > > > > read
> > > > > > > the
> > > > > > > > > > > following articles: [ERROR] [Help 1]
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> > > > > > > > > > > [ERROR] [ERROR] After correcting the problems, you can resume
> > > > > the
> > > > > > > > > > > build with the command [ERROR] mvn <args> -rf
> > > > > > > > > > > :artemis-core-client-all
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Also, they add about 20MB to our distribution, and more 10MB
> > > > > for
> > > > > > > the
> > > > > > > > > > > core-client-all that's not on the distro but it is on maven
> > > > > repo.
> > > > > > > > > > >
> > > > > > > > > > > This is a common trend with other projects. Netty stopped
> > > > > > > producing a
> > > > > > > > > > > netty-all and is offering a pom. Jetty did the same thing.. and
> > > > > > > There
> > > > > > > > > > > are a lot of issues introduced by an "all client".
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > So, even though we could fix the build, these JARs are never
> > > > > tested
> > > > > > > > as
> > > > > > > > > > > part of the testsuite or anything.... It's like playing with
> > > > > the
> > > > > > > > > > > odds... and they are huge on the distribution as they will all
> > > > > > > > > > > include copies of Netty.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I would really like to remove these JARs and I think it would
> > > > > be a
> > > > > > > > > > > great improvement to do so.
> > > > > > > > > > >
> > > > > > > > > > > These POMS are already defining all the dependencies anyway.
> > > > > Any
> > > > > > > user
> > > > > > > > > > > who wants to have a shaded jar would just be able to shade it
> > > > > > > > > > > themselves as part of their project.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > If anyone have a strong feeling about keeping them we would
> > > > > need:
> > > > > > > > > > >
> > > > > > > > > > > - your opinion (why we keep them on 3.0)
> > > > > > > > > > > - Help fixing the build on new-logging
> > > > > > > > > > > - Help with adding smoke tests for these jars.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > anyone?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Clebert Suconic
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > --
> > > > > > > Clebert Suconic
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Clebert Suconic
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> >
> >
> >
> > --
> > Clebert Suconic

Re: [DISCUSS] Remove shaded client JARS

[Robbie Gemmell <ro...@gmail.com>]

It has been several weeks without objection (or reply) to this from
multiple raisings, I'll be looking to do it next week if discussion
doesnt lead otherwise.

On Thu, 8 Sept 2022 at 15:35, Robbie Gemmell <ro...@gmail.com> wrote:
>
> I'd like to raise again the middle-ground of removing these
> partially-shaded uber jars from the assembly.
>
> I think it would be better for all the folks who dont use them,
> removing the triple duplication of half the deps in the assembly, and
> yet also simple for the folks that do use them as they can still
> easily grab the artifact directly without having to download the
> broker and 2 other clients they dont want. E.g when Clebert added the
> updated generateddocs around client classpath [1] I tweaked the docs
> to include a note of being able to grab these -all artifacts from
> Maven Central.
>
> [1] https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.html
>
> On Mon, 8 Aug 2022 at 12:00, Robbie Gemmell <ro...@gmail.com> wrote:
> >
> > Not shading them makes the likelihood of clashing-dependencies worse,
> > i.e that another component being used with it might use (or itself
> > similarly include) a different version of something being ubered
> > without shading, leading to potential for a broken classpath that
> > manifests either very explicitly or in strange unseen ways. Thats what
> > made netty drop their uber jar, as mixed use of the -all and
> > individual netty deps of different versions by different components
> > would routinely cause clashes due to not being alignable by tooling.
> > As it happens, the -all client jars are apparently not shading netty,
> > so nothing else using netty can currently be used along with them
> > without risking a broken classpath. Which is harder to see and resolve
> > since netty is hidden away inside the jar.
> >
> > In short, if not shading anything, to me that makes it seem there
> > would be even less point in having them at all (it being even simpler
> > for folks to build their own non-shaded uber jar than a shaded one),
> > and even more likelihood it causes people using them problems.
> >
> > I mentioned it already in my other replym but adding a quick note now
> > too as it relates...regardless whats done here I think we should
> > remove them from the assembly, it would be better for those not using
> > them and simple for those doing so.
> >
> > On Mon, 1 Aug 2022 at 15:59, Clebert Suconic <cl...@gmail.com> wrote:
> > >
> > > I would be fine to keep the *all clients (given I don't see a
> > > consensus here), however the issue I see is with the shading and class
> > > renaming.
> > >
> > >
> > > if users don't want to use maven and just use our *all clients, they
> > > should not mix with other classes and assure all risks. Right now we
> > > shade these jars and we don't really test if there's anything wrong
> > > with the transformations.
> > >
> > > We now have improved the documentation a little bit, and we should
> > > perhaps just stop shading jars.. just keep everything as they are on
> > > the uber jar.
> > >
> > > On Mon, Aug 1, 2022 at 10:58 AM Clebert Suconic
> > > <cl...@gmail.com> wrote:
> > > >
> > > > I just sent a PR that will update the client classPath and generate the client dependencies with a maven plugin that I just wrote:
> > > >
> > > > https://github.com/apache/activemq-artemis/pull/4162
> > > >
> > > > On Fri, Jul 29, 2022 at 12:54 PM Arthur Naseef <ar...@amlinv.com> wrote:
> > > > >
> > > > > Making use simple for users is a good thing.  On the other hand, there are
> > > > > a lot of target environments that could use different tweaks.  Our
> > > > > dependency-management tool is maven.
> > > > >
> > > > > If folks want to work outside of maven, that's their choice, but then
> > > > > dependency management becomes a problem for that case.
> > > > >
> > > > > Is it worth the effort, and added complexity, to maintain the uber jar?
> > > > >
> > > > > Art
> > > > >
> > > > > On Wed, Jul 27, 2022 at 7:57 AM Michael André Pearce
> > > > > <mi...@me.com.invalid> wrote:
> > > > >
> > > > > > So as the person who added the shaded jars, this was a requirement to make
> > > > > > it far easier for those who DO NOT use tools like maven to be able to build
> > > > > > an application without having to copy a large dependency tree of libs,
> > > > > > which yes for maven or gradle is fine as they handle the dependency tree,
> > > > > > as those tools do this. But unfortunately we don't live in a perfect world,
> > > > > > and providing the shaded allows those users to use the client.
> > > > > >
> > > > > > Im happy to look at why moving logging to slf4j brings an issue, im unsure
> > > > > > why it does tbh, its just another lib, and as long as you shade correctly
> > > > > > it should be fine, ive seen it shaded in many other projects.
> > > > > >
> > > > > > With this i am going on leave for a bit, so unlikely i will get to have a
> > > > > > look at it for a week or two.
> > > > > >
> > > > > > Best
> > > > > > Mike
> > > > > >
> > > > > > On 26 Jul 2022, at 21:44, Justin Bertram <jb...@apache.org> wrote:
> > > > > >
> > > > > >
> > > > > > To be clear, the documentation already exists [1]. It just needs to be
> > > > > > updated with the aforementioned details when the uber jars are removed.
> > > > > >
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > > https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.html
> > > > > >
> > > > > > On Tue, Jul 26, 2022 at 3:39 PM Clebert Suconic <clebert.suconic@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > sure, of course we need to update the docs in relation to anything
> > > > > > these removed jars. What I meant was we need to document the jars that
> > > > > > are required independently of removing the jars.. if someone wants to
> > > > > > use the client jars the client dependency should be documented anyway.
> > > > > > that's what I meant
> > > > > >
> > > > > > On Tue, Jul 26, 2022 at 3:25 PM Justin Bertram <jb...@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > I'm not sure what you mean by "independent issue." If we remove the uber
> > > > > > > jars then the docs have to be updated. The two things are directly
> > > > > > related,
> > > > > > > right?
> > > > > > >
> > > > > > >
> > > > > > > Justin
> > > > > > >
> > > > > > > On Tue, Jul 26, 2022 at 2:13 PM Clebert Suconic <
> > > > > > clebert.suconic@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I think that’s an independent issue. The doc would need to be updated
> > > > > > > > anyways.
> > > > > > > >
> > > > > > > > On Tue, Jul 26, 2022 at 2:40 PM Justin Bertram <jb...@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Yes, the documentation needs to be clear. This is a usability issue.
> > > > > > > > >
> > > > > > > > > Even if you did a "mvn dependency:list" you'd get a list including
> > > > > > > > optional
> > > > > > > > > and test dependencies. Also, there would be potentially unnecessary
> > > > > > > > > dependencies (e.g. netty-transport-native-kqueue even if you aren't
> > > > > > on a
> > > > > > > > > Mac).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Justin
> > > > > > > > >
> > > > > > > > > On Tue, Jul 26, 2022 at 1:30 PM Clebert Suconic <
> > > > > > > > clebert.suconic@gmail.com
> > > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > the pom on artemis-core-client, artemis-jms-client, and
> > > > > > > > > > artemis-jakarta-client... They will include all the needed
> > > > > > > > > > dependencies, right?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > what is the issue? to have a clear text on the docs?
> > > > > > > > > >
> > > > > > > > > > On Tue, Jul 26, 2022 at 2:01 PM Justin Bertram <
> > > > > > jbertram@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > The original impetus for the uber jar was ARTEMIS-1129. The issue
> > > > > > > > there
> > > > > > > > > > was
> > > > > > > > > > > that it wasn't clear what jars were needed on the client. If we
> > > > > > > > remove
> > > > > > > > > > the
> > > > > > > > > > > uber jars then we need to update the documentation to make
> > > > > > crystal
> > > > > > > > > clear
> > > > > > > > > > > what jars are needed on the client, including details about what
> > > > > > jars
> > > > > > > > > may
> > > > > > > > > > > be optional depending on which functionality the client uses.
> > > > > > > > > > >
> > > > > > > > > > > I'm not necessarily against it, but removing the uber jar is
> > > > > > probably
> > > > > > > > > > going
> > > > > > > > > > > to sting for a handful of users. Anything we can do to alleviate
> > > > > > that
> > > > > > > > > > will
> > > > > > > > > > > help. Maybe we could generate a text file in lib/client instead
> > > > > > of
> > > > > > > > the
> > > > > > > > > > uber
> > > > > > > > > > > jars to help users who expect them to be there. The text could
> > > > > > list
> > > > > > > > the
> > > > > > > > > > > jars required for the client's classpath.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Justin
> > > > > > > > > > >
> > > > > > > > > > > [1] https://issues.apache.org/jira/browse/ARTEMIS-1129
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jul 26, 2022 at 8:40 AM Clebert Suconic <
> > > > > > > > > > clebert.suconic@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > We currently deploy these following shaded uber jars with
> > > > > > ActiveMQ
> > > > > > > > > > Artemis.
> > > > > > > > > > > >
> > > > > > > > > > > > artemis-jms-client-all
> > > > > > > > > > > > artemis-core-client-all
> > > > > > > > > > > > artemis-jakarta-client-all
> > > > > > > > > > > >
> > > > > > > > > > > > We are in the process of removing jboss-logging, and replacing
> > > > > > it
> > > > > > > > by
> > > > > > > > > > > > SLF4j /LOG4J on a separate branch, and we will probably make a
> > > > > > > > switch
> > > > > > > > > > > > on the branch as 3.0.
> > > > > > > > > > > >
> > > > > > > > > > > > I never really liked these shaded jars as part of the
> > > > > > > > distribution. I
> > > > > > > > > > > > would be inclined to remove them on a switch for 3.0 anyways,
> > > > > > and
> > > > > > > > now
> > > > > > > > > > > > we are having a build issue,
> > > > > > > > > > > > as they will fail (on a second build) shading
> > > > > > > > apache-commons-logging:
> > > > > > > > > > > >
> > > > > > > > > > > > ERROR] Failed to execute goal
> > > > > > > > > > > > org.apache.maven.plugins:maven-shade-plugin:3.3.0:shade
> > > > > > (default)
> > > > > > > > on
> > > > > > > > > > > > project artemis-core-client-all: Error creating shaded jar:
> > > > > > > > duplicate
> > > > > > > > > > > > entry: META-INF/services/
> > > > > > org.apache.activemq.artemis.shaded.org
> > > > > > > > > > > > .apache.commons.logging.LogFactory
> > > > > > > > > > > > -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the
> > > > > > > > > > > > errors, re-run Maven with the -e switch. [ERROR] Re-run Maven
> > > > > > using
> > > > > > > > > > > > the -X switch to enable full debug logging. [ERROR] [ERROR]
> > > > > > For
> > > > > > > > more
> > > > > > > > > > > > information about the errors and possible solutions, please
> > > > > > read
> > > > > > > > the
> > > > > > > > > > > > following articles: [ERROR] [Help 1]
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> > > > > > > > > > > > [ERROR] [ERROR] After correcting the problems, you can resume
> > > > > > the
> > > > > > > > > > > > build with the command [ERROR] mvn <args> -rf
> > > > > > > > > > > > :artemis-core-client-all
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Also, they add about 20MB to our distribution, and more 10MB
> > > > > > for
> > > > > > > > the
> > > > > > > > > > > > core-client-all that's not on the distro but it is on maven
> > > > > > repo.
> > > > > > > > > > > >
> > > > > > > > > > > > This is a common trend with other projects. Netty stopped
> > > > > > > > producing a
> > > > > > > > > > > > netty-all and is offering a pom. Jetty did the same thing.. and
> > > > > > > > There
> > > > > > > > > > > > are a lot of issues introduced by an "all client".
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > So, even though we could fix the build, these JARs are never
> > > > > > tested
> > > > > > > > > as
> > > > > > > > > > > > part of the testsuite or anything.... It's like playing with
> > > > > > the
> > > > > > > > > > > > odds... and they are huge on the distribution as they will all
> > > > > > > > > > > > include copies of Netty.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I would really like to remove these JARs and I think it would
> > > > > > be a
> > > > > > > > > > > > great improvement to do so.
> > > > > > > > > > > >
> > > > > > > > > > > > These POMS are already defining all the dependencies anyway.
> > > > > > Any
> > > > > > > > user
> > > > > > > > > > > > who wants to have a shaded jar would just be able to shade it
> > > > > > > > > > > > themselves as part of their project.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > If anyone have a strong feeling about keeping them we would
> > > > > > need:
> > > > > > > > > > > >
> > > > > > > > > > > > - your opinion (why we keep them on 3.0)
> > > > > > > > > > > > - Help fixing the build on new-logging
> > > > > > > > > > > > - Help with adding smoke tests for these jars.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > anyone?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Clebert Suconic
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > --
> > > > > > > > Clebert Suconic
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Clebert Suconic
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Clebert Suconic
> > >
> > >
> > >
> > > --
> > > Clebert Suconic