Hello,
I understand that jakarta support will be released in 5.18.x to help
compatibility between ActiveMQ classic and spring boot 3.
Is there an ETA for a 5.18 release?
Thanks!
Dale
I should add that one other approach I've seen which is somewhat
combining the approaches is at Quarkus, where they are currently (not
sure if this is intended going forward, after the 3.0 stuff actually
gets released, but is how its being developed for now) using rewrite
tooling thats part of the
Artemis currently does the dual-modules thing, with the 'main'
artifacts are the same JMS 2 based ones that were always there from
the start, but with additional modules added that take the existing
source and create new 'jakarta variants', e.g artemis-jakarta-client.
I think that was a sensible
Hi Chris,
yes, makes sense.
I agree with you: even it's more work, I think from user community
standpoint, it's better to have two different artifacts/modules.
I will create/update Jira to mention this.
Thanks,
Regards
JB
On Tue, Jan 10, 2023 at 1:53 PM Christopher Shannon
wrote:
>
> If we
If we do have a breaking change and drop JMS jar entirely in 5.19.x then I
think we will need to support 5.18.x for a while. Even though old JMS
clients would work with 5.19.x (just not in the same JVM) it would be good
to support JMS jar still for a while longer.
The other option is we do the
Hi,
Those are valid points:
1. For Jakarta, I plan to change the dep and rename on dedicated
branch (5.19.x). The intention is to introduce breaking change here
(as spring or camel did).
2. Spring 6: you are right for JDK 17 (I forgot this part). Jakarta
namespace depends of the spring module in
JB,
I was writing up a response when I saw Robbies and I have the same
questions.
What is your plan for handling the Jakarta namespace? Are you just using
Maven to generate another module that's a copy of activemq-client?
Also, you said Spring 6 is not very difficult and could be in 5.18.x but
Would the plan be to have these first 5.18 releases marked as e.g.
alphas to set people's expectations appropriately around it not yet
implementing most of JMS 2's new functionality, only some of the new
'simplified' API? Or are the PRs going to pick up on completing [more
of] the impl first?
Hi Matt,
It sounds good to me, as soon as we move forward on 5.19.x soon after
5.18.x. Jakarta namespace could be quickly expected by users as some
frameworks already switched to it (spring boot, camel, ...), so client
libs will have to move fast.
For Spring 6, it's not very difficult, I already
Hey JB-
Thoughts on consolidating the pre-jakarta work into a quick v5.18.x and then
doing a v5.19.x for jakarta?
My thought is that we could consolidate v5.16.x and v5.17.x support work into a
v5.18.x for all javax.* supported build going forward and then start 5.19.x w/
the jakarta
Hi guys,
I started to work on ActiveMQ 5.18.x major release preparation.
Basically, I propose to include (as major changes, in addition of all
others more "minor" changes :)):
- JMS 2.x support (mostly client and first part broker)
- Spring 6 update
- Jakarta namespace support
I should have the
11 matches
Mail list logo
