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 >
