org.hornetq.core.server.cluster.QueueConfiguration

[clebert.suconic]

Not a big deal, but shouldn't org.hornetq.core.server.cluster.QueueConfiguration be located at org.hornetq.core.core instead?

[jmesnil]

Actually, we should move *all* the XXXConfiguration classes to org.hornetq.core.configuration.

They all represent an objectified version of the configuration and would be simpler to use if located in the same package.

[clebert.suconic]

I guess the only class that would need to be moved is org.hornetq.core.server.cluster.QueueConfiguration.

But that will probably change the API, possibly breaking user's compilation on the next upgrade. What should I do?

Keep it as is

Move it, and create a deprecated class on the older place (extending the new one)

or just move it and have eventual users renaming their packages

BTW: there is another identical QueueConfiguration at org.hornetq.jms.configuration

[jmesnil]

the Configuration interface also references DivertConfiguration, ClusterConnectionConfiguration, etc. imho, this makes sense to provide

all these configurations interfaces in a single class.

Besides, this package is not in our API. aiui, we make no promise this would not change in a future release.

[clebert.suconic]

Ok, I will move them

[timfox]

I mentioned this on another thread.

But for community projects we make no guarantees that apis or wireformats won't change over time. Although we will do our best to minimise such change.

Consequently there is no need for deprecation.

[timfox]

If users want guarantee compatibility, that's a value add in the EAP.

[clebert.suconic]

Ok, Having said that, unless someone see a problem I will rename:

- the core Queueconfiguration to CoreQueueConfiguration

- and the jms QueueConfiguration to JMSQueueConfiguration.

I would prefer not having two classes with the same name and same exact code into two different packages.