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 <robbie.gemm...@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 <robbie.gemm...@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 <clebert.suco...@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 > > > <clebert.suco...@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 <a...@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 > > > > > <michael.andre.pea...@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 <jbert...@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.suco...@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 <jbert...@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.suco...@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 > > > > > > > > <jbert...@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.suco...@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 < > > > > > > jbert...@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.suco...@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
