what shall we do with hornetq-core and hornetq-jms

[ataylor]

Now that we have a clean seperation between client and server with these 2 modules we now have 3 jars for each (NB there is a PR for the JMS layer). One thing we could do is move all the core classes into the client module, since the server modules also use the client jars this wont be a problem however it could be argued that some of the core classes don't really belong in a client, so

advantages

1. less modules to maintain

2. less jars, client would only need the client jar not client and common.

disadvantages

1. some classes aren't really client classes for instance

     JMSServerControl.java is implemented on the server side but used on the client side via JMX etc, it seems non intuitive that this is a client class

     classes like SimpleString and Exceptions are neither client or server classes but both

the point is that keeping shared classes separate will help us keep the abstractions cleaner and make us think when writing code

personally I'm happy to go either way, just looking for some consensus one way or the other.

one other thing, could evryone review the API and suggest any thing we can do to improve it, now is the time to be doing this

[borges]

Hi,

FWIW Thanks for splitting the projects, those RE includes inside the client's pom were an horrible hack. We are much better off now.

[...]

+1 for doing away with hornetq-core (and with a hornetq-jms-core) and integrating it into hq-client.

Since we don't expect hq-core to be ever used withOUT hq-core-client, I don't see any practical advantage for for keeping them appart. All the classes that don't fit the client abstraction will be available anyway and when creating new classes it will also lead to confusion about where the class should be added.

[clebert.suconic]

I'm for just 2 jars as well. hornetq-core-client and hornetq-core-server.

[jbertram]

I agree with Francisco.