I usually give a time frame that I'm never able to follow.
Time time, let's just say we are releasing it as soon as possible and ready...
if you could use this thread for anything that needs to be waited
before release, please send a link to a PR discussion or JIRA here.
Thanks...
Clebert
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?