Artemis JMS Client All JAR

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Artemis JMS Client All JAR

beegee
Hi,

the Artemis client all JAR contains all dependencies in a shadowed package,
except of two dependencies:
- JMS Spec 2.0
- javax.json Spec (?)

I would suggest to not include the Spec JARS in the client JAR as it could
cause trouble if those JARS are already included in the classpath. Also, if
an application supports several different JMS providers and has included
client all JARS of those providers, then it's better to have the JMS spec
JAR included just once.

In our software product we cannot use Maven or some sort of library
dependency management tool as of now, so we need to add those JARS manually
to the classpath. The client all JAR helps a lot, but as we need to support
different JMS providers it would be better to have the JMS spec separatly.

What do you think?

Kind regards,
Benjamin Gentner



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: Artemis JMS Client All JAR

MichaelAndrePearce
Hi Benjamin

I can understand a little as classloader if the class would be different in two different jars.

but if these are spec jars with the same class’s then it shouldn’t cause an issue as it shouldn’t matter which class gets loaded from which jar, because they should be the same.

If anything having all the implantation jars in the single jar may cause more issues if you have other vendors as Libs like guava etc are bundled in.

We did do some shading to try avoid some of that, but the original intent of the single jar was to package everything needed, for simple deployment cases where we don’t expect competing jars, not for complex dependencies clashing handling.

from the sounds of it with having multiple other vendors libs also, if you have that really should be handling the dependencies manually without the all jar , manually, via maven or other tooling.

I’m not saying it’s not causing you an issue but it be good if you could expand with an exception this is causing. And the jars you have on the cp.

I’m not 100% pulling libs out is the answer here as it sounds as you have more a complex dependency deployment which as stated wasn’t the original intent of the single jar client.


Cheers
Mike



Sent from my iPhone

> On 6 Dec 2017, at 14:39, beegee <[hidden email]> wrote:
>
> Hi,
>
> the Artemis client all JAR contains all dependencies in a shadowed package,
> except of two dependencies:
> - JMS Spec 2.0
> - javax.json Spec (?)
>
> I would suggest to not include the Spec JARS in the client JAR as it could
> cause trouble if those JARS are already included in the classpath. Also, if
> an application supports several different JMS providers and has included
> client all JARS of those providers, then it's better to have the JMS spec
> JAR included just once.
>
> In our software product we cannot use Maven or some sort of library
> dependency management tool as of now, so we need to add those JARS manually
> to the classpath. The client all JAR helps a lot, but as we need to support
> different JMS providers it would be better to have the JMS spec separatly.
>
> What do you think?
>
> Kind regards,
> Benjamin Gentner
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: Artemis JMS Client All JAR

beegee
Hi Mike,

thank you for your detailed answer. Agree with all of your points. We will
stick now with the single JAR as adding all dependencies manually is really
troublesome in our software product (there are already dozens of libs
included). Hopefully we will switch soon to Maven to resolve our
dependencies automatically.

Kind regards,
Benjamin



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html