[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    Re: Starting ActiveMQ 5.18.x preparation/update
From:       Robbie Gemmell <robbie.gemmell () gmail ! com>
Date:       2023-01-10 13:28:02
Message-ID: CAFitrpTYBrkX6WwHOPxLQV0V-AnjZZOpAq-5ze4MpPqg44bJLw () mail ! gmail ! com
[Download RAW message or body]

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 main (2.x) branch that is used to have
rewrite the build into the jakarta variant intended to become 3.x...so
the build updates everything to the jakarta version, and that output
can then pushed to another branch for release etc.

On Tue, 10 Jan 2023 at 13:17, Robbie Gemmell <robbie.gemmell@gmail.com> wro=
te:
>
> 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 approach when Artemis added Jakarta
> Messaging support going on a couple of years ago, but at this point
> I'd probably go with the full switch and have 2 separate branches.
> Thats what I have done elsewhere, and what other projects switching
> now seem to be doing. Less build complexity, better/simpler for
> testing, uses the same old module names, etc...
>
> ...however, also means doing more releases (seems like it would happen
> anyway in this case), and needs backporting if wanting to support
> both, which seems inevitable for quite some time in this particular
> case. That said, for 5.x it also seems pretty much every change
> released is already backported from main to a branch today, so that
> other 'downside' also isnt actually much different than exactly what
> is already being done now (besides maybe the occasional import fixup).
>
> Robbie
>
> On Tue, 10 Jan 2023 at 12:54, Christopher Shannon
> <christopher.l.shannon@gmail.com> wrote:
> >
> > If we do have a breaking change and drop JMS jar entirely in 5.19.x the=
n 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 g=
ood
> > to support JMS jar still for a while longer.
> >
> > The other option is we do the breaking change in the broker but also ha=
ve a
> > separate module we still release that supports the old JMS 2.0 spec jar=
,
> > like Artemis does. This would require more work but might be an option =
for
> > someone who's code hasn't been upgraded to the new API but wants the la=
test
> > version.
> >
> > On Tue, Jan 10, 2023 at 7:44 AM Jean-Baptiste Onofr=C3=A9 <jb@nanthrax.=
net>
> > wrote:
> >
> > > 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 use.
> > > spring-beans/spring-core doesn't change here. spring-jms, etc yes the=
y
> > > changed. I did the change on the broker first (as it uses
> > > spring-aop/spring-beans/spring-core). But that's correct, better to
> > > postpone to 5.19.x.
> > > 3. I'm doing a full pass on the tests, also reevaluating the profiles=
.
> > > I will share some details.
> > >
> > > I will update Jira with the releases plan.
> > >
> > > Thanks,
> > > Regards
> > > JB
> > >
> > > On Tue, Jan 10, 2023 at 12:40 PM Christopher Shannon
> > > <christopher.l.shannon@gmail.com> wrote:
> > > >
> > > > 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
> > > > doesn't Spring 6 require Jakarta and JDK 17 (as Robbie pointed out)=
? So
> > > if
> > > > you wanted to include support for that for 5.18.x wouldn't that als=
o
> > > imply
> > > > we have to have the Jakarta changes too? Also, I haven't tested wit=
h JDK
> > > 17
> > > > but I assume the broker should be compatible with it at runtime (al=
so
> > > > required for Spring 6). We could also easily add a Jenkins job for =
JDK 17
> > > > if we haven't already.
> > > >
> > > > Speaking of which, it looks like the Jenkins build has had a lot of
> > > > failures and has been unhappy with the Advisory tests since back in
> > > > November which is odd as it's complaining about JMX (instance alrea=
dy
> > > > exists). I just re-kicked off a 5.17.x build so will see if it happ=
ens
> > > > again but may need to fix something. Running the tests by itself lo=
cally
> > > > work fine.
> > > >
> > > > On Tue, Jan 10, 2023 at 6:28 AM Robbie Gemmell <robbie.gemmell@gmai=
l.com
> > > >
> > > > wrote:
> > > >
> > > > > 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 y=
et
> > > > > 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?
> > > > >
> > > > > Doesnt Spring 6 require Java 17, and so anything using it would
> > > > > similarly? Is the thinking to change the minimum globally, or e.g=
 just
> > > > > for specific bits using it and then e.g have divergent requiremen=
ts
> > > > > for build (17+) and runtime (11+ or 17+ depending on what bits yo=
u
> > > > > use)?
> > > > >
> > > > > Matt's reply was around having separate release branches/streams =
for
> > > > > java.jms and jakarta.jms namespace support. I think that might be
> > > > > simplest (and potentially also allowing for different JVM handlin=
g
> > > > > between them) at this stage, I'm doing that elsewhere, though the=
re
> > > > > are certainly also tradeoffs to it vs alternatives. You were prop=
osing
> > > > > something different here, can you flesh out your original idea fo=
r
> > > > > comparison? Had you implemented something?
> > > > >
> > > > > On Sun, 8 Jan 2023 at 07:19, Jean-Baptiste Onofr=C3=A9 <jb@nanthr=
ax.net>
> > > wrote:
> > > > > >
> > > > > > 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 first PRs ready for review very soon.
> > > > > >
> > > > > > I would like to propose a first 5.18.0 in Feb.
> > > > > >
> > > > > > Thoughts ?
> > > > > > Regards
> > > > > > JB
> > > > >
> > >
[prev in list] [next in list] [prev in thread] [next in thread]