Starting ActiveMQ 5.18.x preparation/update

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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

Re: Starting ActiveMQ 5.18.x preparation/update

[Robbie Gemmell <ro...@gmail.com>]

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 <ro...@gmail.com> wrote:
>
> 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
> <ch...@gmail.com> wrote:
> >
> > 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 breaking change in the broker but also have 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 latest
> > version.
> >
> > On Tue, Jan 10, 2023 at 7:44 AM Jean-Baptiste Onofré <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 they
> > > 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
> > > <ch...@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 also
> > > imply
> > > > we have to have the Jakarta changes too? Also, I haven't tested with JDK
> > > 17
> > > > but I assume the broker should be compatible with it at runtime (also
> > > > 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 already
> > > > exists). I just re-kicked off a 5.17.x build so will see if it happens
> > > > again but may need to fix something. Running the tests by itself locally
> > > > work fine.
> > > >
> > > > On Tue, Jan 10, 2023 at 6:28 AM Robbie Gemmell <robbie.gemmell@gmail.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 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?
> > > > >
> > > > > 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 requirements
> > > > > for build (17+) and runtime (11+ or 17+ depending on what bits you
> > > > > 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 handling
> > > > > between them) at this stage, I'm doing that elsewhere, though there
> > > > > are certainly also tradeoffs to it vs alternatives. You were proposing
> > > > > something different here, can you flesh out your original idea for
> > > > > comparison? Had you implemented something?
> > > > >
> > > > > On Sun, 8 Jan 2023 at 07:19, Jean-Baptiste Onofré <jb...@nanthrax.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
> > > > >
> > >

Re: Starting ActiveMQ 5.18.x preparation/update

[Robbie Gemmell <ro...@gmail.com>]

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
<ch...@gmail.com> wrote:
>
> 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 breaking change in the broker but also have 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 latest
> version.
>
> On Tue, Jan 10, 2023 at 7:44 AM Jean-Baptiste Onofré <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 they
> > 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
> > <ch...@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 also
> > imply
> > > we have to have the Jakarta changes too? Also, I haven't tested with JDK
> > 17
> > > but I assume the broker should be compatible with it at runtime (also
> > > 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 already
> > > exists). I just re-kicked off a 5.17.x build so will see if it happens
> > > again but may need to fix something. Running the tests by itself locally
> > > work fine.
> > >
> > > On Tue, Jan 10, 2023 at 6:28 AM Robbie Gemmell <robbie.gemmell@gmail.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 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?
> > > >
> > > > 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 requirements
> > > > for build (17+) and runtime (11+ or 17+ depending on what bits you
> > > > 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 handling
> > > > between them) at this stage, I'm doing that elsewhere, though there
> > > > are certainly also tradeoffs to it vs alternatives. You were proposing
> > > > something different here, can you flesh out your original idea for
> > > > comparison? Had you implemented something?
> > > >
> > > > On Sun, 8 Jan 2023 at 07:19, Jean-Baptiste Onofré <jb...@nanthrax.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
> > > >
> >

Re: Starting ActiveMQ 5.18.x preparation/update

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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
<ch...@gmail.com> wrote:
>
> 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 breaking change in the broker but also have 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 latest
> version.
>
> On Tue, Jan 10, 2023 at 7:44 AM Jean-Baptiste Onofré <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 they
> > 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
> > <ch...@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 also
> > imply
> > > we have to have the Jakarta changes too? Also, I haven't tested with JDK
> > 17
> > > but I assume the broker should be compatible with it at runtime (also
> > > 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 already
> > > exists). I just re-kicked off a 5.17.x build so will see if it happens
> > > again but may need to fix something. Running the tests by itself locally
> > > work fine.
> > >
> > > On Tue, Jan 10, 2023 at 6:28 AM Robbie Gemmell <robbie.gemmell@gmail.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 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?
> > > >
> > > > 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 requirements
> > > > for build (17+) and runtime (11+ or 17+ depending on what bits you
> > > > 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 handling
> > > > between them) at this stage, I'm doing that elsewhere, though there
> > > > are certainly also tradeoffs to it vs alternatives. You were proposing
> > > > something different here, can you flesh out your original idea for
> > > > comparison? Had you implemented something?
> > > >
> > > > On Sun, 8 Jan 2023 at 07:19, Jean-Baptiste Onofré <jb...@nanthrax.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
> > > >
> >

Re: Starting ActiveMQ 5.18.x preparation/update

[Christopher Shannon <ch...@gmail.com>]

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 breaking change in the broker but also have 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 latest
version.

On Tue, Jan 10, 2023 at 7:44 AM Jean-Baptiste Onofré <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 they
> 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
> <ch...@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 also
> imply
> > we have to have the Jakarta changes too? Also, I haven't tested with JDK
> 17
> > but I assume the broker should be compatible with it at runtime (also
> > 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 already
> > exists). I just re-kicked off a 5.17.x build so will see if it happens
> > again but may need to fix something. Running the tests by itself locally
> > work fine.
> >
> > On Tue, Jan 10, 2023 at 6:28 AM Robbie Gemmell <robbie.gemmell@gmail.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 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?
> > >
> > > 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 requirements
> > > for build (17+) and runtime (11+ or 17+ depending on what bits you
> > > 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 handling
> > > between them) at this stage, I'm doing that elsewhere, though there
> > > are certainly also tradeoffs to it vs alternatives. You were proposing
> > > something different here, can you flesh out your original idea for
> > > comparison? Had you implemented something?
> > >
> > > On Sun, 8 Jan 2023 at 07:19, Jean-Baptiste Onofré <jb...@nanthrax.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
> > >
>

Re: Starting ActiveMQ 5.18.x preparation/update

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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 they
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
<ch...@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 also imply
> we have to have the Jakarta changes too? Also, I haven't tested with JDK 17
> but I assume the broker should be compatible with it at runtime (also
> 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 already
> exists). I just re-kicked off a 5.17.x build so will see if it happens
> again but may need to fix something. Running the tests by itself locally
> work fine.
>
> On Tue, Jan 10, 2023 at 6:28 AM Robbie Gemmell <ro...@gmail.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 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?
> >
> > 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 requirements
> > for build (17+) and runtime (11+ or 17+ depending on what bits you
> > 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 handling
> > between them) at this stage, I'm doing that elsewhere, though there
> > are certainly also tradeoffs to it vs alternatives. You were proposing
> > something different here, can you flesh out your original idea for
> > comparison? Had you implemented something?
> >
> > On Sun, 8 Jan 2023 at 07:19, Jean-Baptiste Onofré <jb...@nanthrax.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
> >

Re: Starting ActiveMQ 5.18.x preparation/update

[Christopher Shannon <ch...@gmail.com>]

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 also imply
we have to have the Jakarta changes too? Also, I haven't tested with JDK 17
but I assume the broker should be compatible with it at runtime (also
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 already
exists). I just re-kicked off a 5.17.x build so will see if it happens
again but may need to fix something. Running the tests by itself locally
work fine.

On Tue, Jan 10, 2023 at 6:28 AM Robbie Gemmell <ro...@gmail.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 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?
>
> 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 requirements
> for build (17+) and runtime (11+ or 17+ depending on what bits you
> 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 handling
> between them) at this stage, I'm doing that elsewhere, though there
> are certainly also tradeoffs to it vs alternatives. You were proposing
> something different here, can you flesh out your original idea for
> comparison? Had you implemented something?
>
> On Sun, 8 Jan 2023 at 07:19, Jean-Baptiste Onofré <jb...@nanthrax.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
>

Re: Starting ActiveMQ 5.18.x preparation/update

[Robbie Gemmell <ro...@gmail.com>]

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?

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 requirements
for build (17+) and runtime (11+ or 17+ depending on what bits you
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 handling
between them) at this stage, I'm doing that elsewhere, though there
are certainly also tradeoffs to it vs alternatives. You were proposing
something different here, can you flesh out your original idea for
comparison? Had you implemented something?

On Sun, 8 Jan 2023 at 07:19, Jean-Baptiste Onofré <jb...@nanthrax.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

Re: Starting ActiveMQ 5.18.x preparation/update

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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 did it. I can keep
for 5.19.x, but it's possible to include for 5.18.x (Karaf already
supports it, so the broker in Karaf can work).

Regards
JB

On Mon, Jan 9, 2023 at 8:35 PM Matt Pavlovich <ma...@gmail.com> wrote:
>
> 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 namespace and dependency changes.
>
> v5.18.x (JDK 11 minimum, JMS 2.0, javax.jms, Spring 5)
> v5.19.x (JDK 11 minimum, JMS 2.0, jakarta.jms, Spring 6)
>
> -Matt Pavlovich
>
> > On Jan 8, 2023, at 1:19 AM, Jean-Baptiste Onofré <jb...@nanthrax.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
>

Re: Starting ActiveMQ 5.18.x preparation/update

[Matt Pavlovich <ma...@gmail.com>]

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 namespace and dependency changes.

v5.18.x (JDK 11 minimum, JMS 2.0, javax.jms, Spring 5)
v5.19.x (JDK 11 minimum, JMS 2.0, jakarta.jms, Spring 6)

-Matt Pavlovich

> On Jan 8, 2023, at 1:19 AM, Jean-Baptiste Onofré <jb...@nanthrax.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