It looks like the OSGi version would be compatible code wise, but it appears that it has not been packaged with a module-info unfortunately. I was attempting to avoid using a shaded jar so that there is less dependency micromanagement, but I may have to look in to that route if we wish to proceed with it. I imagine the a version 7.x release is quite a ways off correct?
On 2024/10/15 23:22:37 Matt Pavlovich wrote: > Hi Christopher- > > I cannot confirm that ActiveMQ is packaged to align with Java modules. The > broker does depend on classes in the client jar, so if you depend on the > broker, it will drag the client classes. > > Since ActiveMQ has been prevalent for so long, moving packages to proper > separation will need to wait until the next major release — 7.x. > > Tip— the OSGi module is a single jar with everything packaged, you may look > to try that dependency, or rolling your own shaded jar with everything you > need in one place. > > Thanks, > Matt Pavlovich > > > On Oct 15, 2024, at 4:42 PM, Freeman, Christopher <ch...@sap.com.INVALID> > > wrote: > > > > Hello all, > > > > We are in the process of upgrading our application from Java 8 to 17 using > > ActiveMQ Classic version 6.1.2. I am learning about the modules as I go so > > I apologize if this much easier than it seems. > > > > While setting up our module-info, in it we require the activemq.broker and > > activemq.client. However it seems this is not allowed as both of those > > modules export the same packages names to the same modules which causes it > > to error. Is the expectation that the client and broker should not be > > together and be implemented differently on our end? > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > For additional commands, e-mail: users-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > > >
