Continue to bundle up Remoting classes in jboss-messaging-cl

[jay.howell]

Are we going to continue to bundle up the remoting classes in the jboss-messaging-client.jar? Customers are also having problems in their client because jbossall-client.jar does the same thing(bundle up remoting).

Is there a reason, that remoting is bundled up in so many jars? Can it exist on it's own as a jar in the client's classpath?

This has led to some difficulties when having customers upgrade thier remoting due to a remoting patch. This also leads to some difficulties because users using messaging and EJB3 could possibly be using two different versions of remoting on thier client.

[clebert.suconic]

I have seen so many other issues on having these jars on jbossall-client.jar also.

I would like also to remove jboss-remoting.jar from jbossall-client.jar. Scott/Dimitris would have to take the decision on doing it.

Tom Elrod added this to jbossall-client.jar and as I remember the only reason was to make Customer's life easier... and as this is making their lifes more difficult we should stop doing it.

Scott/Dimitris.. .what you guys think?


Clebert

[starksm64]

In terms of evolution of an existing install, there is nothing good about the jbossall-client.jar. If it exists it really should be an empty jar that only includes a manifest classpath pointing to the jars that should be on a client classpath.

[timfox]

We should definitely provide a jboss-messaging-client.jar which contains the jboss messaging classes and nothing else (or maybe just a few other jars that are highly unlikely to change - TBD)

I have created a JIRA task for it:


http://jira.jboss.org/jira/browse/JBMESSAGING-940

[dimitris]

recorded it here:
http://jira.jboss.com/jira/browse/JBAS-4355