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.
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
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.
Ok, I will move them
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.
If users want guarantee compatibility, that's a value add in the EAP.
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.