Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-12 Thread Matt Pavlovich
Hey JB- I’m not sure I agree about changing them. Current approach allows for ‘optional’ feautres. A couple things that this could impact: 1. Plugin extensions using xbean namespaces 2. The activemq-http component and other ’optional’ add-ons. 3. Other optional features— client-side blob

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-12 Thread Jean-Baptiste Onofré
I ack your point (even if I don't necessarily agree regarding my experience with AMQ/Karaf/OSGi :)), and we have a consensus. As I said, I will continue the current approach with the required upgrades. Regards JB On Tue, Sep 12, 2023 at 11:01 AM Christoph Läubrich wrote: > > > I agree with the

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-12 Thread Jean-Baptiste Onofré
Just to be clear: I will keep the current approach upgrading to spring 6 etc. In the meantime, I will work on SMX/Karaf requirements for ActiveMQ. Regards JB Le mar. 12 sept. 2023 à 10:51, Jean-Baptiste Onofré a écrit : > Ok fair enough. > > I will update the features and OSGi bundles

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-12 Thread Christoph Läubrich
> I agree with the overhead but is it really an issue Of course it is an issue (depending on how much you embedd), at least it vast disk, cpu, ram and network resources > AMQ broker is a black box in Karaf/OSGi So no configuration? No plugins? No management possible? Client only ever use

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-12 Thread Jean-Baptiste Onofré
Ok fair enough. I will update the features and OSGi bundles accordingly. Regards JB Le mar. 12 sept. 2023 à 10:41, Robbie Gemmell a écrit : > I'm really glad someone already noted the various disadvantages of > uber jars that I thought of when reading the original email. Saved me > some

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-12 Thread Robbie Gemmell
I'm really glad someone already noted the various disadvantages of uber jars that I thought of when reading the original email. Saved me some typing. I'd only expand upon the "Every update to a dependency will require a full ActiveMQ release" point to more directly call it out as being a security

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-11 Thread Jean-Baptiste Onofré
About your points: - I agree with the overhead but is it really an issue ? Having an atomic bundle is not a bad thing imho - that's why I said "most of" import packages and today, AMQ broker is a black box in Karaf/OSGi, so I don't see a difference here - nobody is doing Spring update or Jetty

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-11 Thread Christoph Läubrich
> I disagree on what particular point? > I don't understand why people are against uber bundle. Because it has many bad properties: - You duplicate the code in your bundle, especially for large frameworks like spring this can be a major overhead, if someone else is using that framework it

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-11 Thread Jean-Baptiste Onofré
Hi, I disagree, I don't understand why people are against uber bundle. The export packages stay the same, so ActiveMQ can still "collaborate" with other bundles. Most of import (not all) will go private, not necessary all (I'm on a PoC right now). Regards JB On Tue, Sep 12, 2023 at 5:48 AM

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-11 Thread Jean-Baptiste Onofré
Hi We already have shell commands to deal with the broker: we will still have it, it doesn't change there. Good comment about Spring, however, imho, it's not OSGi specific: we would need to replace Spring with something else in ActiveMQ iitself. Regards JB On Mon, Sep 11, 2023 at 11:27 PM

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-11 Thread Christoph Läubrich
Making "uberbundles" is really bad not only for file-size, OSGi was made with sharing in mind and embedding "everything" will make this impossible if you not at the same time rexport the packages what has other implications. Also keep in mind that he activemq could not participate in any

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-11 Thread fpapon
Hi JB, Sounds good to me. Just some side questions: - You're talking about having an embedded broker in Karaf so does it mean that we can also have some Karaf command to control the broker? (like we can have with Camel) - About the client, should we will need to use Pax-JMS or not? If not,

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-11 Thread Christopher Shannon
I don't really know too much about how the Osgi stuff works so I will defer to you and others who use it in terms of what is best so this sounds ok to me if it is needed. On Mon, Sep 11, 2023 at 8:08 AM Jean-Baptiste Onofré wrote: > Hi all, > > As you know, ActiveMQ 5.19.x is in preparation

[PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

2023-09-11 Thread Jean-Baptiste Onofré
Hi all, As you know, ActiveMQ 5.19.x is in preparation with importants changes: JMS 2, Jakarta namespace, Spring 6, ... For ActiveMQ 5.19.x, I propose to change the OSGi packaging (client and broker). Today we have OSGi bundles for client and broker, with Karaf features installing all dependent