ARTEMIS-2557 don't export openwire-protocol JMS spec dep

[jbertram]

No description provided.

[michaelandrepearce]

Why don't we just make the dependency exclusion in our poms so the dependency doesnt pull avoiding the issue and not requiring this doc

[jbertram]

Where would we make the exclusion in our pom? As I understand it, the issue is 3rd party applications which are embedding the broker and declaring their own dependencies on our poms.

[gemmellr]

Since the example given in the doc change is artemis-openwire-protocol, I'd expect Michael is thinking of excluding it there, i.e exclude the 1.1 dep when pulling in whichever bits depend on it, and add the 2.0 dep as used elsewhere in artemis. Folks who pull in the artemis-openwire-protocol dep then just get 2.0 dep, which should be fine at runtime.

[jbertram]

As far as I can tell, any <exclusion> would have to be done by the 3rd party application which is declaring the <dependency> on artemis-openwire-protocol. The artemis-openwire-protocol can't exclude the JMS interface dependency because it needs it. As you note, we could change the dependency to JMS 2, but I didn't go that route because I didn't want to give the impression that the OpenWire protocol implementation for Artemis supported JMS 2.

[clebertsuconic]

@jbertram / @gemmellr / @michaelandrepearce are you guys settled on this discussion? is this ready to be merged?

[michaelandrepearce]

Not really theres been no change. Exclusion works fine to remove a transitive dependency to be pulled in by others.

[jbertram]

@michaelandrepearce, I'm still confused on what should be changed. Can you clarify?

[michaelandrepearce]

Where the jms 1.1 api is coming in within our codebase, simply add an excludes

[jbertram]

As I already noted previously, "The artemis-openwire-protocol can't exclude the JMS interface dependency because it needs it."

[michaelandrepearce]

But you can either add jms 2.0 or just make it compile time scope

[gemmellr]

Personally I dont think this should really be documented, and would change the module config out such that the issue doesnt arise.

The module has a transitive dep on the JMS 1.1 API via activemq-client, and has a transitive dep on the JMS 2.0 API via artemis-jms-client, and then further declares a non-transitive dep on JMS 1.1 itself. Various options likely exist to resolve the issue this doc update covers, stopping the 1.1 dep being passed to dependent componenents, while keeping things working for the module...e.g, excluding the transitive 1.1 dep from activemq-client, marking the fixed 1.1 dep as provided scope or optional, removing it entirely, declaring a fixed dep on JMS 2.0 spec, different combinations of these etc.

I dont think using the JMS 2 API jar [,perhaps only at runtime,] for a server-side component of an otherwise JMS2-supporting broker really implies anything much about the spec level supported for clients, particularly as no client yet exists to follow through on any confusion that arises. Since the JMS 2.0 API is still in the dep list here, if there is any scope for confusion it largely exists either way. Anyone that tries using JMS 2 APIs with a client that doesnt implement them will quickly find out it doesnt work, with it fairly simple to figure out why from the resulting errors. Anyone that really does want a 1.1 API + client used in something declaring a dep on artemis-openwire-protocol should already have their own dependency on them, in which case nothing would change by preventing the dep being passed on to them by artemis-openwire-protocol.

[jbertram]

I excluded the transitive JMS 1.1 dependency from activemq-client and set the scope of the explicit JMS 1.1 dependency to provided as that made the most sense to me.