Yup. I propose to update the website with a table with different
versions (as we do in Karaf).
Regards
JB
On Wed, Apr 12, 2023 at 4:08 PM Christopher Shannon
wrote:
>
> Yep, this seems like a good plan to me. If people want to upgrade to
> Jakarta we will have to require Spring 6 (due to the
Yep, this seems like a good plan to me. If people want to upgrade to
Jakarta we will have to require Spring 6 (due to the configuration) which
requires JDK 17 and I think requiring JDK 17 is reasonable for that version
as JDK 21 is almost out.
I also want to add that we should upgrade 5.18.x to
That's exactly my proposal :)
+1
Regards
JB
On Wed, Apr 12, 2023 at 3:57 PM Matt Pavlovich wrote:
>
> Hi Robbie-
>
> Yep, I’m back to agreeing with planning to move forward with the two separate
> versions is the way to go. Chris Shannon has the jetty continuation thing
> resolved, so that
Hi Robbie-
Yep, I’m back to agreeing with planning to move forward with the two separate
versions is the way to go. Chris Shannon has the jetty continuation thing
resolved, so that was the only potential snag for back porting.
Proposed plan for 5.19.x and to LTS-ify 5.18.x:
5.18.x LTS - JDK
I dont really understand what your table of combinations entries say,
and so why Option 1 would be to support "3 (or more)" LTS branches but
the other only 2, so its hard to reply specifically around that.
Adding -javax modules on a new branch thats primary-jakarta just
doesnt really make sense
I had assumed you would use Spring 6 on the Jakarta branch, though
still targeting 11 with the client etc, but requiring 17 for build and
using those modules with spring 6 requirement (im not clear which bits
those are...but sounds like its more widespread than I thought it
was).
On Wed, 5 Apr
I agree w/ Chris. I don’t think there is harm in keeping a -jakarta client
module in 5.18.x. It provides runway for users that lag on JDK adoption and are
not using Spring 6.
A couple of technical notes to keep in mind about JDK-Spring-Jakarta coupling
*specific* to ActiveMQ 5:
1. Spring 6
All fair points Robbie. I'd still like to leave the jakarta client in
5.18.x just as it gives some compatibility for clients only even if it's
going to go away in 5.19.x.
So how about the following:
5.18.x - Still javax support with just a jakarta client. This can be a long
term LTS, at least
No extra -javax client module module. People wanting Jakarta client
support would use 5.19.x. People wanting javax client support would
just use 5.18.x as they would today. I'd even consider removing the
extra 5.18.x -jakarta client module personally (could be super nice
and add a maven relocation
So if 5.19.x just becomes Jakarta API (and not new modules) then I assume
we would just have an extra client module for javax? Basically the inverse
of 5.18.x (where we primarily use javax and have a jakarta client module)
I guess that will be fine but it is pretty unusual to make such a large
Hi
Agree, it was basically my proposal in a previous email: I would not
use different artifacts, just change to the major version (5.19.x). If
people still want to use javax.jms, then he can use 5.18.x (that we
can "flag" as LTS).
Regards
JB
On Mon, Apr 3, 2023 at 10:20 PM Christopher Shannon
Based on what Robbie is saying we wouldn't have any new modules at all. I
would just be different versions, one version is javax and one is jakarta
which is what Qpid JMS did. (Jakarta is 2.x and javax is 1.x)
On Mon, Apr 3, 2023 at 1:32 PM Matt Pavlovich wrote:
> Yeah, I agree w/ Robbie. I
Yeah, I agree w/ Robbie. I think this makes the most sense considering Jakarta
namespace will be default going forward for all new apps.
When migrating existing apps, it’ll most likely be all javax deps to jakarta,
so that makes for a nice clean version-number-only change.
For example,
Though that was over 2 years ago, and at the time having the separate
-jakarta modules was probably the most obvious way to go given very
few were likely going to actually use those new modules at the time,
with the prior/existing stuff clearly still being the focus for almost
everyone, and thus
Thanks for the input Justin, that makes sense to not require existing users
to change GAV (at least not yet until we drop javax). I think we are
heading down that path with new modules for jakarta based on what Matt
started doing so that is in line with what Artemis did and it would be good
to be
For what it's worth Artemis created new coordinates for the Jakarta modules
and left the existing ones the same. Folks who are migrating are actually
touching their applications in most (if not all) circumstances. It makes
sense to require them to change the GAV.
In my opinion folks who just want
Matt,
My main concern with that is with new -javax modules everyone has to change
to new GAV and then they have to change GAV again if we drop the javax.
But this might just be the way it is and users will have to make changes to
their build that is more than just a version change.
On Fri, Mar
Hi Endre-
Thanks, this might be a way to bring 5.18.x forward on Jetty version 12 w/o
converting 5.18.x to jakarta and Spring 6.
-Matt Pavlovich
> On Mar 30, 2023, at 3:06 PM, Endre Stølsvik wrote:
>
> From a lurker position here, I just wanted to point out that Jetty is
> evidently making a
Hi Christopher-
After taking yesterday to get most of the way through the jakarta conversion, I
think we can go without the version gap.
I think option #1 gives us the best approach. After a period of time we can
just ‘drop’ the javax modules and not have to cause users to change anything
Thanks Matt for bringing this up. We definitely need to figure out a path
forward as there is a lot of confusion about this still and users are
getting bit by it when trying to upgrade to Spring 6 and Spring boot 3.
Ultimately I think we will need to support both javax and jakarta for quite
a
>From a lurker position here, I just wanted to point out that Jetty is
evidently making a version 12 which will support both javax. and jakarta.
in the same server.
https://www.eclipse.org/jetty/download.php
Kind regards,
Endre
On Thu, Mar 30, 2023 at 9:54 PM Jean-Baptiste Onofré
wrote:
> Hi,
Hi,
I agree with the plan but why not keep 5.19.0-SNAPSHOT on main ?
We have the activemq-5.18.x branch already that could be LTS where we
keep javax namespace.
Regards
JB
On Thu, Mar 30, 2023 at 7:54 PM Matt Pavlovich wrote:
>
> Hello All-
>
> I started building a jakarta-based broker for
Hello All-
I started building a jakarta-based broker for ActiveMQ 5.x and propose the
following steps to manage the change.
Background:
Jakarta support in ActiveMQ 5.x is going to pull in JDK 17, Spring 6, Jakarta
EE 9, Servlet 5.x, and Jetty 11. That is quite a bit of change, and I suggest
23 matches
Mail list logo
