[DISCUSS] Remove shaded client JARS

[Clebert Suconic <cl...@gmail.com>]

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?

Re: [DISCUSS] Remove shaded client JARS

[Clebert Suconic <cl...@gmail.com>]

Even then, I would rather add a section with documentation than an
Uber jar that's not tested.

On Tue, Jul 26, 2022 at 2:22 PM Clebert Suconic
<cl...@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 <jb...@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 <cl...@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

Re: [DISCUSS] Remove shaded client JARS

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

Its possible to make the dependency:list output more appropriate to
the desired use here by asking for only deps needed at runtime
(conceptual scope, not quite exactly the maven scope) and thus not
including the test etc ones:
mvn dependency:list -DincludeScope=runtime

It could also be prettied up a bit further for this usage by sorting,
and perhaps dropping the dep scopes to make just the GAV more obvious:
mvn dependency:list -DincludeScope=runtime -Dsort=true -Dmdep.outputScope=false

Alternatively a simple intermediate pom depending on the client only
could be used, which running even just "mvn dependency:list" on would
then just get a list of specifically what maven/gradle/other users
actually get dependency wise when depending on the client, i.e no test
etc deps as those aren't passed on to users. The output of "mvn
dependency:tree" could also make more sense with the intermediate pom.
Or even just some using dependency:copy and then listing the dest dir
contents.

On Tue, 26 Jul 2022 at 19:40, 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 <cl...@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 <jb...@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
> >
> >

Re: [DISCUSS] Remove shaded client JARS

[Clebert Suconic <cl...@gmail.com>]

sure thing!

On Tue, Jul 26, 2022 at 4:45 PM 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 <cl...@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

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

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>]

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

[Clebert Suconic <cl...@gmail.com>]

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

[Clebert Suconic <cl...@gmail.com>]

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

Re: [DISCUSS] Remove shaded client JARS

[Arthur Naseef <ar...@amlinv.com>]

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
>
>
>

Re: [DISCUSS] Remove shaded client JARS

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

Another thing I've noticed with these modules is that a download is
made for the snapshot of their own sources artifact from the
repository.apache.org snapshots repo, while they are themselves being
built, e.g:
https://github.com/apache/activemq-artemis/runs/7530099764?check_suite_focus=true#step:5:11312

So each CI job is doing this every time (multiple times), and each
regular developers builds likely doing it once a day. I'm not clear if
that means the resulting output built locally doesnt actually match
the local sources if it differs. It also fails when rebuilding older
commits that no longer have remote snapshots deployed (though without
failing the build fortunately, or else noone would be able to build
the old commits at all). Whatever the reason it would be nice to avoid
this waste of resources and any knock on correctness issues from it.

On Wed, 27 Jul 2022 at 17:15, Robbie Gemmell <ro...@gmail.com> wrote:
>
> Those users can clearly still use the client without shading though,
> they'd just have to copy more files. Not quite as trivial, certainly,
> but hardly an insurmountable challenge either. If really against
> having multiple files like many many things do, they could always
> produce an uber jar in e.g a CI job, perhaps along with their
> application bits bundled in too since liking having one file.
>
> Having everyone who gets the assembly download need to grab what is
> 17MB (out of 50MB total, so 33MB without them) of essentially
> triple-duplicated dependencies to satisfy one somewhat-corner use case
> that has other simple options, doesnt seem needed for me. Having us
> all [try to] maintain these essentially untested set of uber jars for
> that use case also seems off. Especially when for many people I'd say
> they shouldnt even consider using these artifacts.
>
> Shading also introduces various issues for applications, particularly
> those ones not using build tooling. It makes it difficult to update
> transitive dependencies (say, prior to a release) without rebuilding
> the shaded artifact, cumbersome for security updates. It makes it hard
> to even see what is being used for identifying if such updates are
> needed, since everythings all hidden in the shaded artifact. It can
> even make it impossible to use other components in the same
> application if it depends on (or even similarly uber-bundled) a subtly
> different version of the same dependency that isnt shaded, e.g it
> appears Netty is not being shaded in the -all client jar, so anything
> else using Netty in an app could easily introduce potentially
> incompatible netty classes to the classpath when combined with the
> client uber jar. The latter is why netty themselves did away with
> their own uber jar and kept only the individual ones, since that kept
> happening, one component used the uber, another component used
> individual bits, and then apps using both components then had subtle
> (or nt) clashes from mixing them since at that point even the build
> tools such as Maven couldnt them keep things aligned on one version
> because the components have deps using the different GAVs.
>
> As an aside, I dont think the issue is really that Log4j bits
> directly, but probably some stuff I did around commons-logging->SLF4J
> bridging. Either way its likely the shading stuff needs adjusted since
> nothings been done it for with the logging bits yet and it seemed to
> be working, it was only on doing a re-build clebert noticed it fails.
>
> On Wed, 27 Jul 2022 at 15:57, 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 <cl...@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
> >
> >

Re: [DISCUSS] Remove shaded client JARS

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

Those users can clearly still use the client without shading though,
they'd just have to copy more files. Not quite as trivial, certainly,
but hardly an insurmountable challenge either. If really against
having multiple files like many many things do, they could always
produce an uber jar in e.g a CI job, perhaps along with their
application bits bundled in too since liking having one file.

Having everyone who gets the assembly download need to grab what is
17MB (out of 50MB total, so 33MB without them) of essentially
triple-duplicated dependencies to satisfy one somewhat-corner use case
that has other simple options, doesnt seem needed for me. Having us
all [try to] maintain these essentially untested set of uber jars for
that use case also seems off. Especially when for many people I'd say
they shouldnt even consider using these artifacts.

Shading also introduces various issues for applications, particularly
those ones not using build tooling. It makes it difficult to update
transitive dependencies (say, prior to a release) without rebuilding
the shaded artifact, cumbersome for security updates. It makes it hard
to even see what is being used for identifying if such updates are
needed, since everythings all hidden in the shaded artifact. It can
even make it impossible to use other components in the same
application if it depends on (or even similarly uber-bundled) a subtly
different version of the same dependency that isnt shaded, e.g it
appears Netty is not being shaded in the -all client jar, so anything
else using Netty in an app could easily introduce potentially
incompatible netty classes to the classpath when combined with the
client uber jar. The latter is why netty themselves did away with
their own uber jar and kept only the individual ones, since that kept
happening, one component used the uber, another component used
individual bits, and then apps using both components then had subtle
(or nt) clashes from mixing them since at that point even the build
tools such as Maven couldnt them keep things aligned on one version
because the components have deps using the different GAVs.

As an aside, I dont think the issue is really that Log4j bits
directly, but probably some stuff I did around commons-logging->SLF4J
bridging. Either way its likely the shading stuff needs adjusted since
nothings been done it for with the logging bits yet and it seemed to
be working, it was only on doing a re-build clebert noticed it fails.

On Wed, 27 Jul 2022 at 15:57, 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 <cl...@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
>
>

Re: [DISCUSS] Remove shaded client JARS

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

I think that subset is niche enough that they should satisfy such
requirements themselves where they exist, rather than the project
bloating its build and maintaining multiple client uber jars, which
are themselves prone to causing issues especially when not used in one
of these specialised cases, and having everyone getting the binary
assembly for the broker effectively downloading deps in triplicate
needlessly if not in one of these situations that wants a client uber
jar.

At the very least I think we should remove them from the assembly
either way. They are referenced from the docs and can be grabbed
easily direct from Central by those few that want them, as opposed to
unnecessarily downloading the entire broker and all the individual
deps (and the other uber jar) as well if all you want is a single jar
uber client jar.

On Thu, 28 Jul 2022 at 16:02, Matt Pavlovich <ma...@gmail.com> wrote:
>
> +1 on Mike’s point here.
>
> Shaded client jars are just another packaging for a subset of users — 3rd party, SaaS, COTS apps, etc. that consume a jar like a ‘driver’. At times, limited to only allow uploading of a single file.
>
> Matt Pavlovich
>
> > On Jul 27, 2022, at 9: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 <https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.html>
> >>
> >> On Tue, Jul 26, 2022 at 3:39 PM Clebert Suconic <cl...@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 <ma...@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 <ma...@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 <ma...@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 <https://issues.apache.org/jira/browse/ARTEMIS-1129>
> >>> > > > > >
> >>> > > > > > On Tue, Jul 26, 2022 at 8:40 AM Clebert Suconic <
> >>> > > > > clebert.suconic@gmail.com <ma...@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 <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
> >>>
> >
> >
>

Re: [DISCUSS] Remove shaded client JARS

[Matt Pavlovich <ma...@gmail.com>]

+1 on Mike’s point here.

Shaded client jars are just another packaging for a subset of users — 3rd party, SaaS, COTS apps, etc. that consume a jar like a ‘driver’. At times, limited to only allow uploading of a single file.

Matt Pavlovich

> On Jul 27, 2022, at 9: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 <https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.html>
>> 
>> On Tue, Jul 26, 2022 at 3:39 PM Clebert Suconic <cl...@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 <ma...@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 <ma...@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 <ma...@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 <https://issues.apache.org/jira/browse/ARTEMIS-1129>
>>> > > > > >
>>> > > > > > On Tue, Jul 26, 2022 at 8:40 AM Clebert Suconic <
>>> > > > > clebert.suconic@gmail.com <ma...@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 <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
>>> 
> 
> 

Re: [DISCUSS] Remove shaded client JARS

[Michael André Pearce <mi...@me.com.INVALID>]

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.BestMike 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 beupdated with the aforementioned details when the uber jars are removed.Justin[1]https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.htmlOn Tue, Jul 26, 2022 at 3:39 PM Clebert Suconic <cl...@gmail.com>wrote:sure, of course we need to update the docs in relation to anythingthese removed jars. What I meant was we need to document the jars thatare required independently of removing the jars.. if someone wants touse the client jars the client dependency should be documented anyway.that's what I meantOn 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 directlyrelated,> right?>>> Justin>> On Tue, Jul 26, 2022 at 2:13 PM Clebert Suconic <cl...@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'ton 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 <jb...@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 makecrystal> > > clear> > > > > what jars are needed on the client, including details about whatjars> > > may> > > > > be optional depending on which functionality the client uses.> > > > >> > > > > I'm not necessarily against it, but removing the uber jar isprobably> > > > going> > > > > to sting for a handful of users. Anything we can do to alleviatethat> > > > will> > > > > help. Maybe we could generate a text file in lib/client insteadof> > the> > > > uber> > > > > jars to help users who expect them to be there. The text couldlist> > 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 withActiveMQ> > > > Artemis.> > > > > >> > > > > > artemis-jms-client-all> > > > > > artemis-core-client-all> > > > > > artemis-jakarta-client-all> > > > > >> > > > > > We are in the process of removing jboss-logging, and replacingit> > 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 Mavenusing> > > > > > the -X switch to enable full debug logging. [ERROR]  [ERROR]For> > more> > > > > > information about the errors and possible solutions, pleaseread> > the> > > > > > following articles: [ERROR] [Help 1]> > > > > >> > > >> >http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException> > > > > > [ERROR]  [ERROR] After correcting the problems, you can resumethe> > > > > > build with the command [ERROR]   mvn <args> -rf> > > > > > :artemis-core-client-all> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > Also, they add about 20MB to our distribution, and more 10MBfor> > the> > > > > > core-client-all that's not on the distro but it is on mavenrepo.> > > > > >> > > > > > 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 nevertested> > > as> > > > > > part of the testsuite or anything.... It's like playing withthe> > > > > > 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 wouldbe 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 wouldneed:> > > > > >> > > > > > - 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

Re: [DISCUSS] Remove shaded client JARS

[Justin Bertram <jb...@apache.org>]

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 <cl...@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
>
>

Re: [DISCUSS] Remove shaded client JARS

[Clebert Suconic <cl...@gmail.com>]

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 <cl...@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 <jb...@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

Re: [DISCUSS] Remove shaded client JARS

[Justin Bertram <jb...@apache.org>]

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 <cl...@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 <jb...@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
>

Re: [DISCUSS] Remove shaded client JARS

[Clebert Suconic <cl...@gmail.com>]

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 <jb...@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

Re: [DISCUSS] Remove shaded client JARS

[Justin Bertram <jb...@apache.org>]

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 <cl...@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 <jb...@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
>
>

Re: [DISCUSS] Remove shaded client JARS

[Clebert Suconic <cl...@gmail.com>]

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 <jb...@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 <cl...@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

Re: [DISCUSS] Remove shaded client JARS

[Justin Bertram <jb...@apache.org>]

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 <cl...@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?
>
>

Re: [DISCUSS] Remove shaded client JARS

[Arthur Naseef <ar...@amlinv.com>]

+1 for eliminating shaded jars/bundles where possible

On Tue, Jul 26, 2022 at 10:16 AM Timothy Bish <ta...@gmail.com> wrote:

> +1
>
> Removing them seems valid given the issues noted.
>
> On 7/26/22 12:18, Robbie Gemmell wrote:
> > I think removing them would be good for various reasons inc all you
> noted below.
> >
> > On Tue, 26 Jul 2022 at 14:34, Clebert Suconic <cl...@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?
>
>
> --
> Tim Bish
>
>

Re: [DISCUSS] Remove shaded client JARS

[Timothy Bish <ta...@gmail.com>]

+1

Removing them seems valid given the issues noted.

On 7/26/22 12:18, Robbie Gemmell wrote:
> I think removing them would be good for various reasons inc all you noted below.
>
> On Tue, 26 Jul 2022 at 14:34, Clebert Suconic <cl...@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?


-- 
Tim Bish

Re: [DISCUSS] Remove shaded client JARS

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

I think removing them would be good for various reasons inc all you noted below.

On Tue, 26 Jul 2022 at 14:34, Clebert Suconic <cl...@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?