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
> 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
Hi,
I agree and it's actually something we likely discussed while ago
related to renaming as for me we have two really different subprojects
(https://lists.apache.org/thread/f0rqkq01xgyogqownx38k1mdsy69lzvm).
IMHO, ActiveMQ should use 6.x, 7.x, 8.x; ... versioning (and so jump
to 6.x now with
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
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
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
I agree. We have had breaking changes in the 5.x series, and that's bad.
We may not be perfect in maintaining semantic versioning, but it is
important.
The Jakarta changes are definitely a major concern if we stick to 5.x.
Is there any reason to avoid using 6.x? I looked around to see if we
Jeff,
That's a good point about Artemis possibly being 7.0, that's fine too.
This is nothing against Artemis, really it's just this release completely
breaks everything and is not compatible at all so I really think it would
be terrible to release it as 5.19.x as for the last 10+ years people
Hi,
Make totally sense, especially about keeping the javax version
supported, so need to split in 2 major versions.
Big +1
regards,
François
On 11/09/2023 23:14, Christopher Shannon wrote:
First, I realize that this thread is likely to cause a fight based on past
history and probably not
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,
Its funny you mentioned this...I was just having a side discussion about this
with some others and I fully agree with you. This is a major change... as in
break stuff change. I fully agree it should be considered 6.0. We really
don't have a reservation system for number (IMHO). I dont have
First, I realize that this thread is likely to cause a fight based on past
history and probably not go anywhere, but with the work being done
with Jakarta for AMQ 5.x I think it's time to at least bring up the
ActiveMQ 6.0 discussion.
With all the breaking changes currently targeted for version
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
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
+1 (binding)
Regards
JB
On Sun, Sep 10, 2023 at 7:40 PM Havret wrote:
>
> Hi all,
>
> I have put together another release of activemq-nms-api. Please review it
> and vote accordingly.
>
> This release adds an API allowing users to consume messages asynchronously
> using the new
15 matches
Mail list logo
