Re: [RESULT][VOTE] Apache ActiveMQ 5.16.6 release

[Jean-Baptiste Onofré]

Agree, I will do a new time (we already replied to few users on the
mailing list announcing that it's an last/exceptional release).

Regards
JB

On Thu, Feb 16, 2023 at 5:59 PM Robbie Gemmell  wrote:
>
> The announcement should be crystal clear on the status of 5.16.x,
> given it was already announced finished in May 2022and this time
> we should remove it from the download page promptly.
>
> On Thu, 16 Feb 2023 at 15:37, Jean-Baptiste Onofré  wrote:
> >
> > Hi everyone,
> >
> > this vote passed with the following result:
> >
> > +1 (binding): Christopher Shannon, JB Onofré, Robbie Gemmell
> > +1 (non binding): Bruce, Jean-Louis Monteiro, François Papon, Jamie
> > Goodyear, Matt Pavlovich, Murali Krishna, Cesar Hernandez
> >
> > I'm promoting the artifacts on Maven Central and dist.apache.org, then
> > I will update Jira and website, and I will do the announcement.
> >
> > Thanks all for your vote!
> >
> > FYI, ActiveMQ 5.17.4 vote will start soon (before the end of the week)!
> >
> > Regards
> > JB
> >
> > On Fri, Feb 10, 2023 at 4:56 PM Jean-Baptiste Onofré  
> > wrote:
> > >
> > > Hi guys,
> > >
> > > We receive several requests to provide a new (final) ActiveMQ 5.16.6
> > > release, including few security fixes/improvements.
> > >
> > > So, I submit ActiveMQ 5.16.6 release to your vote. This one should be
> > > the last version on the 5.16.x series, inviting our users to upgrade
> > > to at least 5.17.x (or 5.18.x that should be available soon).
> > >
> > > Please take a look on the Release Notes for details:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12351793
> > >
> > > Maven Staging Repository:
> > > https://repository.apache.org/content/repositories/orgapacheactivemq-1269/
> > >
> > > Dist Staging Repository:
> > > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.6/
> > >
> > > Git tag: activemq-5.16.6
> > >
> > > Please vote to approve this release:
> > > [ ] +1 Approve the release
> > > [ ] -1 Don't approve the release (please provide specific comments)
> > >
> > > This vote will be open for at least 72 hours.
> > >
> > > Thanks !
> > > Regards
> > > JB

[ANN] Apache ActiveMQ 5.16.6 has been released!

[Jean-Baptiste Onofré]

The ActiveMQ team is pleased to announce Apache ActiveMQ 5.16.6 release.

NB: this should be the last release on the 5.16.x series, we strongly
invite all users to update to ActiveMQ 5.17.x series.

ActiveMQ 5.16.6 includes several fixes, improvements, and dependency
updates as well, especially:
- fixes on the LDAP authentication module
- fixes high CPU usage when closing many consumers
- a bunch of dependency upgrades

You can find details on the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12351793

You can download ActiveMQ 5.16.6 here:
https://activemq.apache.org/components/classic/download/

Enjoy!

Regards
---
The Apache ActiveMQ team

[VOTE] Apache ActiveMQ 5.17.4 release

[Jean-Baptiste Onofré]

Hi,

I submit ActiveMQ 5.17.4 to your vote. This release includes several
fixes, improvements and a lot of dependency updates, especially:
- add JOLOKIA_CONF env variable in wrapper configuration
- potential race condition in the store while creating new destinations
- fix reentrant lock in the broker configuration runtime
- upgrade to xstream 1.4.20
- upgrade to Spring 5.3.25
- and much more!

You can a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352481

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1270/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.4/

Git tag: activemq-5.17.4

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

Re: [VOTE] Apache ActiveMQ 5.17.4 release

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Wed, Feb 22, 2023 at 9:06 AM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> I submit ActiveMQ 5.17.4 to your vote. This release includes several
> fixes, improvements and a lot of dependency updates, especially:
> - add JOLOKIA_CONF env variable in wrapper configuration
> - potential race condition in the store while creating new destinations
> - fix reentrant lock in the broker configuration runtime
> - upgrade to xstream 1.4.20
> - upgrade to Spring 5.3.25
> - and much more!
>
> You can a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352481
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1270/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.4/
>
> Git tag: activemq-5.17.4
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

[RESULT][VOTE] Apache ActiveMQ 5.17.4 release

[Jean-Baptiste Onofré]

Hi,

this vote passe with the following result:

+1 (binding): Christopher Shannon, JB Onofré, Robbie Gemmell, Tim Bish
+1 (non binding): Jamie Goodyear, Matt Pavlovich, François Papon

I'm promoting the artifacts on Maven Central and dist.apache.org, I
will update Jira and the website, and I will send the announcement.

Thanks all for your vote!

Regards
JB

On Wed, Feb 22, 2023 at 9:06 AM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> I submit ActiveMQ 5.17.4 to your vote. This release includes several
> fixes, improvements and a lot of dependency updates, especially:
> - add JOLOKIA_CONF env variable in wrapper configuration
> - potential race condition in the store while creating new destinations
> - fix reentrant lock in the broker configuration runtime
> - upgrade to xstream 1.4.20
> - upgrade to Spring 5.3.25
> - and much more!
>
> You can a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352481
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1270/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.4/
>
> Git tag: activemq-5.17.4
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

[ANN] Apache ActiveMQ 5.17.4 has been released!

[Jean-Baptiste Onofré]

The ActiveMQ team is pleased to announce Apache ActiveMQ 5.17.4 release.

ActiveMQ 5.17.4 includes several fixes, improvements, and dependency
updates as well, especially:
- add JOLOKIA_CONF env variable in wrapper configuration
- potential race condition in the store while creating new destinations
- fix reentrant lock in the broker configuration runtime
- upgrade to xstream 1.4.20
- upgrade to Spring 5.3.25
- and much more!

You can find details on the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352481

You can download ActiveMQ 5.17.4 here:
https://activemq.apache.org/components/classic/download/

Enjoy!

Regards
---
The Apache ActiveMQ team

[HEADSUP] Moving forward on 5.18.0 release

[Jean-Baptiste Onofré]

Hi,

Now 5.17.4 has been released, I propose to move forward on 5.18.0 release.

The target is to submit this release to vote at the end of next week.

Thanks,
Regards
JB

Re: [HEADSUP] Moving forward on 5.18.0 release

[Jean-Baptiste Onofré]

Hi Matt,

Great ! Thanks ! I'm on several fixes/Jira as well.

Regards
JB

On Tue, Mar 7, 2023 at 11:07 PM Matt Pavlovich  wrote:
>
> Hi JB-
>
> Sounds good, I’ve started cleaning up JIRA and PRs. I’ll get my stuff merged 
> and sorted out here in the next 1-2 days.
>
> Thanks!
> Matt Pavlovich
>
> > On Mar 4, 2023, at 11:44 PM, Jean-Baptiste Onofré  wrote:
> >
> > Hi,
> >
> > Now 5.17.4 has been released, I propose to move forward on 5.18.0 release.
> >
> > The target is to submit this release to vote at the end of next week.
> >
> > Thanks,
> > Regards
> > JB
>

[VOTE] Apache ActiveMQ 5.18.0 release

[Jean-Baptiste Onofré]

Hi,

After several weeks of work, I'm glad to submit ActiveMQ 5.18.0 to
your vote. This release is a major milestone for ActiveMQ bringing
major changes:
- JMS 2 API support (client)
- support Jakarta namespace (client)
- a lot of dependency updates and fixes
- and much much more!

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12351380

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1275/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.0/

Git tag: activemq-5.18.0

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

Re: [VOTE] Apache ActiveMQ 5.18.0 release

[Jean-Baptiste Onofré]

+1 (binding)

Obviously I did a bunch of tests with standalone brokers scenarios.

Regards
JB

On Sun, Mar 19, 2023 at 6:26 PM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> After several weeks of work, I'm glad to submit ActiveMQ 5.18.0 to
> your vote. This release is a major milestone for ActiveMQ bringing
> major changes:
> - JMS 2 API support (client)
> - support Jakarta namespace (client)
> - a lot of dependency updates and fixes
> - and much much more!
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12351380
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1275/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.0/
>
> Git tag: activemq-5.18.0
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

Re: [VOTE] Apache ActiveMQ 5.18.0 release

[Jean-Baptiste Onofré]

I agree, let's update the JMS2 page and I will include a note on the
announcement/release notes.

Regards
JB

On Thu, Mar 23, 2023 at 3:32 PM Matt Pavlovich  wrote:
>
> Chris-
>
> Good point re Jakarta and the need to communicate specifics. I’ll work to 
> update the JMS2 page to include notes about the Jakarta support.
>
> -Matt
>
> > On Mar 23, 2023, at 8:54 AM, Christopher Shannon 
> >  wrote:
> >
> > Also for anyone who is looking at the release and is testing and isn't
> > aware on the state of the JMS 2.0 client and the new Jakarta client...It's
> > not complete and there is some info here: https://activemq.apache.org/jms2
> >
> > Currently the clients only support some of the new API methods so far so
> > not everything will work. Also if testing using the Jakarta client be aware
> > it's just a repackaging so it also doesn't support everything and it can't
> > be used in the same JVM as an embedded broker because the broker still uses
> > the old JMS apis so there would be conflicts.
> >
> > The release notes page and any other communication like on that jms2 link
> > will need to make sure to document  very carefully what exactly is and
> > isn't supported in each release in regards to the JMS 2.0 and Jakarta APIs.
> >
> > On Wed, Mar 22, 2023 at 3:47 AM Francois Papon 
> > 
> > wrote:
> >
> >> +1 (non-binding)
> >>
> >> Thanks!
> >>
> >> regards,
> >>
> >> François
> >>
> >> On 19/03/2023 18:26, Jean-Baptiste Onofré wrote:
> >>> Hi,
> >>>
> >>> After several weeks of work, I'm glad to submit ActiveMQ 5.18.0 to
> >>> your vote. This release is a major milestone for ActiveMQ bringing
> >>> major changes:
> >>> - JMS 2 API support (client)
> >>> - support Jakarta namespace (client)
> >>> - a lot of dependency updates and fixes
> >>> - and much much more!
> >>>
> >>> You can take a look on the Release Notes for details:
> >>>
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12351380
> >>>
> >>> Maven Staging Repository:
> >>>
> >> https://repository.apache.org/content/repositories/orgapacheactivemq-1275/
> >>>
> >>> Dist Staging Repository:
> >>> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.0/
> >>>
> >>> Git tag: activemq-5.18.0
> >>>
> >>> Please vote to approve this release:
> >>> [ ] +1 Approve the release
> >>> [ ] -1 Don't approve the release (please provide specific comments)
> >>>
> >>> This vote will be open for at least 72 hours.
> >>>
> >>> Thanks !
> >>> Regards
> >>> JB
> >>
>

Re: [VOTE] Apache ActiveMQ 5.18.0 release

[Jean-Baptiste Onofré]

Gentle reminder, we would need an additional binding vote to have this
release vote pass.

Thanks !
Regards
JB

On Sun, Mar 19, 2023 at 6:26 PM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> After several weeks of work, I'm glad to submit ActiveMQ 5.18.0 to
> your vote. This release is a major milestone for ActiveMQ bringing
> major changes:
> - JMS 2 API support (client)
> - support Jakarta namespace (client)
> - a lot of dependency updates and fixes
> - and much much more!
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12351380
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1275/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.0/
>
> Git tag: activemq-5.18.0
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

[RESULT][VOTE] Apache ActiveMQ 5.18.0 release

[Jean-Baptiste Onofré]

Hi everyone,

This vote passed with the following result:

+1 (binding): Christopher Shannon, JB Onofré, Timothy Bish
+1 (non binding): Jamie Goodyear, Matt Pavlovich, JL Monteiro, François Papon

I'm promoting the artifacts on Maven Central and dist.apache.org, and
update Jira.
Then, I will prepare the announcement (update website, email, ...).

Thanks all for your vote!

Regards
JB

On Sun, Mar 19, 2023 at 6:26 PM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> After several weeks of work, I'm glad to submit ActiveMQ 5.18.0 to
> your vote. This release is a major milestone for ActiveMQ bringing
> major changes:
> - JMS 2 API support (client)
> - support Jakarta namespace (client)
> - a lot of dependency updates and fixes
> - and much much more!
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12351380
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1275/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.0/
>
> Git tag: activemq-5.18.0
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

[ANN] Apache ActiveMQ 5.18.0 has been released!

[Jean-Baptiste Onofré]

The ActiveMQ team is pleased to announce Apache ActiveMQ 5.18.0 release.

This release is an important milestone for the ActiveMQ project, providing:
- JMS 2.0 client support with both javax.jms and jakarta.jms
namespaces (see https://activemq.apache.org/jms2 for details)
- JDK11+ support
- Spring 5.3.x support
- a lot of dependency updates, including CVE fixes (xstream 1.4.20, ...)
- improvements in a lot of areas (JAAS authentication, redelivery
policy, REST API, ...)

You can find details on the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12351380

You can download ActiveMQ 5.18.0 here:
https://activemq.apache.org/components/classic/download/

Enjoy!
---
The Apache ActiveMQ team

Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker

[Jean-Baptiste Onofré]

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 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 
> we leave a ‘gap version’ in case we need to make any incremental updates to 
> 5.18.x series along the way.
>
> 1. Rename main to 5.20.0-SNAPSHOT
> 2. Commit broker-related jakarta, servlet, jetty, spring, etc changes to main
> 3. Create new ‘-javax’ broker modules to support a 
> apache-activemq-javax-5.20.0-bin.tar.gz package using re-packaging of the 
> jakarta artifacts.
> 4. Leave 5.19.x as a ‘gap version’ in case it is needed for 5.18.x changes
>
> Thanks,
> Matt Pavlovich

Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker

[Jean-Baptiste Onofré]

t;>>> 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 while because while some users are going to want to use newer
> > >>>>> technologies that require jakarta (like Spring 6 ) others will be
> > happy
> > >>>> to
> > >>>>> stay on the old APIs for a while. So the question becomes what is the
> > >>>> best
> > >>>>> way to do that. I do think that some sort of repackaging is probably
> > >>> the
> > >>>>> way to go like we did for the client but to do it for all the
> > relevant
> > >>>>> modules and release both.  We can keep 5.18.x as a long running
> > branch
> > >>> to
> > >>>>> back port but it would still be nice if the latest worked for either
> > >>> API
> > >>>>> (ie 5.19.x). I'm thinking more about it and we can probably just do
> > it
> > >>> in
> > >>>>> 5.19.x and don't need a gap version.
> > >>>>>
> > >>>>> I can see 3 ways to release both:
> > >>>>>
> > >>>>> *1) Create duplicate modules (like we did with  the client for
> > jakarta
> > >>> in
> > >>>>> 5.18.x). *This works but means a lot of extra modules to maintain but
> > >>> is
> > >>>>> probably the most flexible as you can do custom things in each module
> > >>>>> easily. We could create BOM files for people to use to import the
> > right
> > >>>>> things to keep things consistent.
> > >>>>>
> > >>>>> 
> > >>>>> org.apache.activemq
> > >>>>> activemq-broker-javax
> > >>>>> 5.19.0
> > >>>>> 
> > >>>>>
> > >>>>> 
> > >>>>> org.apache.activemq
> > >>>>> activemq-broker-jakarta
> > >>>>> 5.19.0
> > >>>>> 
> > >>>>>
> > >>>>> *2) Don't add new modules, just keep the same ones but have each
> > module
> > >>>>> build 2 jars using classifiers. *We could just have each module
> > build 2
> > >>>>> jars and repackage.  My primary concern about sharing the same module
> > >>> for
> > >>>>> both APIs would be if the Jakarta API becomes different enough that
> > >>>>> repackaging doesn't work due to changes between it and javax but we
> > >>> might
> > >>>>> still be able to make this work by having each classified jar only
> > pull
> > >>>> in
> > >>>>> certain things.
> > >>>>>
> > >>>>> 
> > >>>>> org.apache.activemq
> > >>>>> activemq-broker
> > >>>>> 5.19.0
> > >>>>> javax
> > >>>>> 
> > >>>>>
> > >>>>> 
> > >>>>> org.apache.activemq
> > >>>>> activemq-broker
> > >>>>> 5.19.0
> > >>>>> jakarta
> > >>>>> 
> > >>>>>
> > >>>>> *3) Just build with a different version (this is what Guava does with
> > >>> jre
> > >>>>> and android). *This is probably the most annoying as you would need
> > to
> > >>>>> re-package and then I guess use a different version when building.
> > >>>>>
> > >>>>> 
> > >>>>> org.apache.activemq
> > >>>>> activemq-broker
> > >>>>> 5.19.0-javax
> > >>>>> 
> > >>>>>
> > >>>>> 
> > >>>>> org.apache.activemq
> > >>>>> activemq-broker
> > >>>>> 5.19.0-jakarta
> > >>>>> 
> > >>>>>
> > >>>>>
> > >>>>> On Thu, Mar 30, 2023 at 4:06 PM Endre Stølsvik 
> > >>>> wrote:
> > >>>>>
> > >>>>>> 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é <
> > j...@nanthrax.net
> > >>>>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> 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 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 we leave a ‘gap version’ in case we need to make any
> > >>>>>> incremental
> > >>>>>>> updates to 5.18.x series along the way.
> > >>>>>>>>
> > >>>>>>>> 1. Rename main to 5.20.0-SNAPSHOT
> > >>>>>>>> 2. Commit broker-related jakarta, servlet, jetty, spring, etc
> > >>> changes
> > >>>>>> to
> > >>>>>>> main
> > >>>>>>>> 3. Create new ‘-javax’ broker modules to support a
> > >>>>>>> apache-activemq-javax-5.20.0-bin.tar.gz package using re-packaging
> > of
> > >>>> the
> > >>>>>>> jakarta artifacts.
> > >>>>>>>> 4. Leave 5.19.x as a ‘gap version’ in case it is needed for 5.18.x
> > >>>>>>> changes
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>> Matt Pavlovich
> > >>>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>>
> >
> >

[VOTE] Apache ActiveMQ 5.18.1 release

[Jean-Baptiste Onofré]

Hi,

I submit Apache ActiveMQ 5.18.1 release to your vote. This release
fixes activemq-client-jakarta where the META-INF/services file was
missing in the artifact.

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352969

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1278/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.1/

Git tag: activemq-5.18.1

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

Re: [VOTE] Apache ActiveMQ 5.18.1 release

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Tue, Apr 11, 2023 at 11:26 AM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> I submit Apache ActiveMQ 5.18.1 release to your vote. This release
> fixes activemq-client-jakarta where the META-INF/services file was
> missing in the artifact.
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352969
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1278/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.1/
>
> Git tag: activemq-5.18.1
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

Re: ASF board report due in two days!

[Jean-Baptiste Onofré]

+1

it looks good, thanks !

Sorry I was busy and didn't have time to add content to the report.

Regards
JB

On Wed, Apr 12, 2023 at 12:34 PM Robbie Gemmell
 wrote:
>
> I fleshed out the report with the stats + releases etc detail, tweaked
> the earlier additions from Justin and Matt, and reflowed things so it
> can be submitted directly via Whimsy.
>
> https://github.com/apache/activemq-website/commit/8035b7148bba966f8d72aba682fc8a118cdecbbf
>
> https://github.com/apache/activemq-website/blob/8035b7148bba966f8d72aba682fc8a118cdecbbf/src/team/reports/DRAFT-ActiveMQ-board-report.txt
>
> Robbie
>
> On Tue, 11 Apr 2023 at 20:36, Bruce Snyder  wrote:
> >
> > So far, there have been zero contributions to the board report and it's due
> > tomorrow. Please contribute to this month's board report so I can submit it
> > tomorrow.
> >
> > Bruce
> >
> > On Mon, Apr 10, 2023 at 11:36 AM Bruce Snyder 
> > wrote:
> >
> > > It looks like we got notified late again regarding this month's board
> > > report and it's due in two days!
> > >
> > > Please provide your contributions for this board report by adding them to
> > > the following file already in the git repo:
> > >
> > >
> > > https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt
> > >
> > >
> > > Bruce
> > >
> > > --
> > > perl -e 'print
> > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > > http://bsnyder.org/ 
> > >
> >
> >
> > --
> > perl -e 'print
> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > http://bsnyder.org/ 

Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker

[Jean-Baptiste Onofré]

o not do  
> >> -javax modules in 5.19.x
> >>
> >> Option 2: Add -javax modules to 5.19.x and support 2 LTS branches
> >>
> >> Thanks,
> >> Matt Pavlovich
> >>
> >>> On Apr 5, 2023, at 9:20 AM, Christopher Shannon 
> >>>  wrote:
> >>>
> >>> 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 for bug fixes. We will probably want to backport some
> >>> features too for a while.
> >>> 5.19.x - Becomes Jakarta API only. Still support JDK 11 and by default
> >>> would still have Spring 5.3.x but will be of course compatible with Spring
> >>> 6 and Spring boot 3, etc.
> >>> 5.20.x - By this release JDK 21 LTS should be out so I say we bump to
> >>> require JDK 17 (we can bump other things like Jetty/Spring 6 at the same
> >>> time)
> >>>
> >>> We could also bump to JDK 17 for 5.19.x if it's too much of a pain to
> >>> support JDK 11 but I think it should be doable.
> >>>
> >>> In terms of which features are actually supported/implemented for the new
> >>> APIs is another discussion. Obviously each release would add more. I
> >>> haven't had time yet to look more into shared subscriptions but likely 
> >>> we'd
> >>> leverage the existing composite destination/virtual topics that exist in
> >>> the broker to support it but I'm not sure if it would be client/broker 
> >>> side
> >>> etc.
> >>>
> >>> Thoughts?
> >>>
> >>> On Wed, Apr 5, 2023 at 8:59 AM Robbie Gemmell 
> >>> wrote:
> >>>
> >>>> 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 for it to the initial 5.19.0 release to
> >>>> point them back to the normal client module, though as its not in
> >>>> widespread use and doesnt even work yet, a need for that is unclear).
> >>>>
> >>>> I dont particularly care what version it is called. However I will say
> >>>> I dont think it would particularly be any more unusual to call it
> >>>> 5.19.x vs 5.18.x than it was with many other more impactful changes
> >>>> that have been made in 5.n -> 5.n+1 releases in the past ~15 years.
> >>>> While awkward in some ways, its actually probably a more trivial
> >>>> change in the end compared to many prior changes in that time. Folks
> >>>> that want to update their stuff to the new API make a trivial version
> >>>> number update. Folks that dont, will not. Actual implementation
> >>>> behaviours would remain the same, unlike with many 5.x bumps. Could
> >>>> jump it to 5.30.x to separate and align with supporting Jakarta
> >>>> Messaging 3 ;)
> >>>>
> >>>> On Wed, 5 Apr 2023 at 12:31, Christopher Shannon
> >>>>  wrote:
> >>>>>
> >>>>> 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
> >>>>> breaking API change without bumping major versions. I would argue that
> >>>>> should really be a 6.0 release but everyone knows how that conversation
> >>>>> would go with versioning so I guess we are stuck on 5.19.x
> >>>>>
> >>>>> On Wed, Apr 5, 2023 at 5:17 AM Jean-Baptiste Onofré 
> >>>> wrote:
> >>>>>
> >>>>>> Hi
> >>>>>>
> >>>>

Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker

[Jean-Baptiste Onofré]

vax modules would be a way to simplify managing a
> > Spring 6 + JDK 17 + javax build without a separate branch and set of
> > releases
> > >>
> > >> A table of potential combinations:
> > >>
> > >> 5.18.x - Spring 5 + JDK 11 + javax (client and broker)
> > >> 5.18.x (-jakarta client) - Spring 5 + JDK 11 + jakarta (client-only)
> > >> 5.19.x - Spring 6 + JDK 17 + jakarta (client and broker)
> > >> 5.19.x (-javax modules) - Spring 6 + JDK 17 + javax (client and broker)
> > >>
> > >>
> > >> Based on all the above, I think the discussion could be reduced to a
> > couple practical options:
> > >>
> > >> Option 1: Gap versions and support 3 (or more) LTS branches and do not
> > do  -javax modules in 5.19.x
> > >>
> > >> Option 2: Add -javax modules to 5.19.x and support 2 LTS branches
> > >>
> > >> Thanks,
> > >> Matt Pavlovich
> > >>
> > >>> On Apr 5, 2023, at 9:20 AM, Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> > >>>
> > >>> 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 for bug fixes. We will probably want to backport
> > some
> > >>> features too for a while.
> > >>> 5.19.x - Becomes Jakarta API only. Still support JDK 11 and by default
> > >>> would still have Spring 5.3.x but will be of course compatible with
> > Spring
> > >>> 6 and Spring boot 3, etc.
> > >>> 5.20.x - By this release JDK 21 LTS should be out so I say we bump to
> > >>> require JDK 17 (we can bump other things like Jetty/Spring 6 at the
> > same
> > >>> time)
> > >>>
> > >>> We could also bump to JDK 17 for 5.19.x if it's too much of a pain to
> > >>> support JDK 11 but I think it should be doable.
> > >>>
> > >>> In terms of which features are actually supported/implemented for the
> > new
> > >>> APIs is another discussion. Obviously each release would add more. I
> > >>> haven't had time yet to look more into shared subscriptions but likely
> > we'd
> > >>> leverage the existing composite destination/virtual topics that exist
> > in
> > >>> the broker to support it but I'm not sure if it would be client/broker
> > side
> > >>> etc.
> > >>>
> > >>> Thoughts?
> > >>>
> > >>> On Wed, Apr 5, 2023 at 8:59 AM Robbie Gemmell <
> > robbie.gemm...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> 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 for it to the initial 5.19.0 release to
> > >>>> point them back to the normal client module, though as its not in
> > >>>> widespread use and doesnt even work yet, a need for that is unclear).
> > >>>>
> > >>>> I dont particularly care what version it is called. However I will say
> > >>>> I dont think it would particularly be any more unusual to call it
> > >>>> 5.19.x vs 5.18.x than it was with many other more impactful changes
> > >>>> that have been made in 5.n -> 5.n+1 releases in the past ~15 years.
> > >>>> While awkward in some ways, its actually probably a more trivial
> > >>>> change in the end compared to many prior changes in that time. Folks
> > >>>> that want to update their stuff to the new API make a trivial version
> > >>>> number update. Folks that dont, will not. Actual implementation
> > >>>> behaviours would remain the same, unlike with many 5.x bumps. Could
> > >>>> jump it to 5.30.x to separate and align with suppo

Re: activemq-client-jakarta 5.18.1 not published on Maven

[Jean-Baptiste Onofré]

Hi,

The vote is not closed yet. As soon as we close the vote and announce
5.18.1 release, it will be available on Maven Central.

Regards
JB

On Fri, Apr 14, 2023 at 9:33 AM Christian Winkler
 wrote:
>
> Hi all.
>
> I found that the 5.18.1 release of activemq-client-jakarta is not published 
> on Maven.
> The only version that can be found there so far is the broken 5.18.0
> https://mvnrepository.com/artifact/org.apache.activemq/activemq-client-jakarta
> Is this intentionally?
>
> Best regards
> Christian Winkler

[RESULT][VOTE] Apache ActiveMQ 5.18.1 release

[Jean-Baptiste Onofré]

Hi all,

this vote passed with the following result:

+1 (binding): Christopher Shannon, JB Onofré, Timothy Bish
+1 (non binding): Jean-Louis Monteiro, François Papon, Matt Pavlovich,
Jamie Goodyear

I'm promoting the artifacts on Maven Central and dist.apache.org, then
I will update Jira and the website, and I will announce the release.

Thanks all for your vote!

Regards
JB

On Tue, Apr 11, 2023 at 11:26 AM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> I submit Apache ActiveMQ 5.18.1 release to your vote. This release
> fixes activemq-client-jakarta where the META-INF/services file was
> missing in the artifact.
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352969
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1278/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.1/
>
> Git tag: activemq-5.18.1
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

[ANN] Apache ActiveMQ 5.18.1 has been released!

[Jean-Baptiste Onofré]

The ActiveMQ team is pleased to announce Apache ActiveMQ 5.18.1 release.

This release is a maintenance release on the 5.18.x series.
It especially fixes an issue with the activemq-client-jakarta artifact.

You can find details on the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352969

You can download ActiveMQ 5.18.1 here:
https://activemq.apache.org/components/classic/download/

Enjoy!
---
The Apache ActiveMQ team

Re: [VOTE] Release activemq-nms-amqp 2.2.0-rc1

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Sat, May 6, 2023 at 8:58 PM Havret  wrote:
>
> Hi all,
>
> I have put together another release of activemq-nms-amqp. Please review it
> and vote accordingly.
>
> This update enhances the message acknowledgement functionality by
> supporting multiple AckType's, This improvement enables clients to utilize
> broker redelivery configurations automatically and aligns the client
> library more closely with the qpid-jms counterpart.
>
> This release contains the following change:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201&version=12353210
>
> The files can be grabbed from:
> *https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-amqp/2.2.0-rc1/
> *
>
> Regards,
> Krzysztof
>
> Here's mine +1 (binding)

Re: activemq.xsd

[Jean-Baptiste Onofré]

Hi,

I will check the xsd uploaded. 5.19.x is not yet there anyway.

For Jakarta, do you want the client side or broker side or both ?

Regards
JB

On Wed, May 10, 2023 at 4:23 PM  wrote:
>
> Hi,
> I checked out the latest classic ActiveMQ 
> (https://github.com/apache/activemq.git)
> Due to my project at my employer I wanted to try to build 5.19 as pure 
> Jakarta.
> I am almost complete I think, updating spring to 6.0.8 as well.
>
> I am facing a problem with the activemq.xsd.
> It doesn't seem to be available in the project.  I did find 
> https://activemq.apache.org/schema/core/, but 5.18.x or 5.19.x isn't there 
> either.
> Can anyone provide some help on how to deal with this schema and build the 
> project?
>
> I am happy to contribute my updates when I have built the whole thing.
>
> Regards,
> Rune Gellein
> BT Plc

Re: NMS micro-site

[Jean-Baptiste Onofré]

Hi Mike,

It makes sense to have a component/sub-site dedicated to NMS.

Regards
JB

On Thu, May 11, 2023 at 12:05 PM Michael André Pearce
 wrote:
>
> Hi All,
>
> Krzysztof and I have been offline chatting and starting to feel the need to 
> revamp the NMS docs, one thing we're finding is that the docs area is a 
> little thin.
>
> We are thinking if it would make sense for us to make a micro-site docs akin 
> to how Artemis docs are done, where they are published separately and simply 
> iframed within the apache activemq main site.
>
> Does anyone have any big objections here if we were to venture/explore this 
> route?
> Also we were thinking of running it just as github pages, to really simplify 
> things.
>
> I want to put this out here, before we expend effort, to just make sure.
>
> Best
> Mike
>
>

Re: Remove Jackson from ActiveMQ classic

[Jean-Baptiste Onofré]

Hi,

We discussed this already in the past. IMHO, we can replace jackson by
just sax (no need to use JSON-B regarding our usage).

That sasid, I don't see any huge issue with Jackson: it works fine and
we keep the versions up to date to fix CVE.

The only interesting move would be to use SAX parsing directly instead
of a mapper.

Regards
JB

On Tue, May 16, 2023 at 12:17 PM Jean-Louis Monteiro
 wrote:
>
> Hi all,
>
> Jackson seems to be frequently affected by CVEs and it's really a pain for
> users.
>
> Looks like Jackson is only used in the WebConsole to read/write a few
> attributes. I'm sure we can get rid of it and either use a standard API so
> one can plugin any implementation, or just write down a utility class to
> parse the small attribute we have to.
>
> thoughts?
>
> I'm happy to do a PR to remove it if that's the consensus.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com

Re: Remove Jackson from ActiveMQ classic

[Jean-Baptiste Onofré]

FYI, Romain provided a PR to use Apache Johnson while ago:
https://github.com/apache/activemq/pull/308

The PR is fine (I already tested when submitted), it just needs a rebase.
If we agree, I can move forward on this one.

Regards
JB

On Wed, May 17, 2023 at 4:04 AM Justin Bertram  wrote:
>
> For what it's worth, Artemis uses JSON-P [1] since it's a standard, simple
> API. We use Apache Johnzon for the implementation. It does everything we
> need given our relatively basic use-cases.
>
> Additionally, we wrap the API so that all the broker code can use the
> wrapper and the wrapper can be modified to work in Java EE or Jakarta EE
> environments.
>
>
> Justin
>
> [1]
> https://javaee.github.io/javaee-spec/javadocs/javax/json/package-summary.html
>
> On Tue, May 16, 2023 at 6:02 PM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > Yes, this keeps coming up and as JB said I don't see a problem with
> > Jackson, it can be updated for CVEs and works very well and is quite
> > feature rich in case we need it.
> >
> > If we are going to do any JSON serialization I don't want to re-invent the
> > wheel and create our own serializer, so we should at least use an existing
> > library, even if we make it pluggable like JSON-B.
> >
> > There's alternatives too like Gson if we wanted something
> > smaller/lightweight.
> >
> > On Tue, May 16, 2023 at 3:11 PM Jean-Baptiste Onofré 
> > wrote:
> >
> > > Hi,
> > >
> > > We discussed this already in the past. IMHO, we can replace jackson by
> > > just sax (no need to use JSON-B regarding our usage).
> > >
> > > That sasid, I don't see any huge issue with Jackson: it works fine and
> > > we keep the versions up to date to fix CVE.
> > >
> > > The only interesting move would be to use SAX parsing directly instead
> > > of a mapper.
> > >
> > > Regards
> > > JB
> > >
> > > On Tue, May 16, 2023 at 12:17 PM Jean-Louis Monteiro
> > >  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > Jackson seems to be frequently affected by CVEs and it's really a pain
> > > for
> > > > users.
> > > >
> > > > Looks like Jackson is only used in the WebConsole to read/write a few
> > > > attributes. I'm sure we can get rid of it and either use a standard API
> > > so
> > > > one can plugin any implementation, or just write down a utility class
> > to
> > > > parse the small attribute we have to.
> > > >
> > > > thoughts?
> > > >
> > > > I'm happy to do a PR to remove it if that's the consensus.
> > > >
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com
> > >
> >

Re: [VOTE] Apache ActiveMQ Artemis 2.29.0

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Thu, Jun 15, 2023 at 1:39 AM Clebert Suconic
 wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.29.0 release.
>
> This is a representative workload with 126 JIRAs and 200+ commits with
> a diverse number of committers. Thanks to all who contributed to this
> big release.
>
>
> The release notes can be found here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352880&projectId=12315920
>
>
> Ths git commit report is here:
> https://activemq.apache.org/components/artemis/download/commit-report-2.29.0
>
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.29.0
>
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1279
>
> In case you want to give it a try with the maven repo on examples:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> The version has been tagged on git as '2.29.0'
>
> I will update the website after the vote has passed.
>
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here's my +1
>
>
> I will keep the Vote open until monday, US EST morning, on June 19th
>
>
> --
> Clebert Suconic

[HEADS-UP] Preparing Apache ActiveMQ 5.18.2 and 5.17.5 releases

[Jean-Baptiste Onofré]

Hi guys,

FYI, we are preparing ActiveMQ 5.18.2 and 5.17.5 before moving forward
on 5.19.x (planned for next month).

I hope to be able to submit 5.18.2 and 5.17.5 releases to vote during
the weekend.

Stay tuned !

Regards
JB

Re: [HEADS-UP] Preparing Apache ActiveMQ 5.18.2 and 5.17.5 releases

[Jean-Baptiste Onofré]

Hi François

That's correct.

Right now both 5.17.x and 5.18.x are active.
When 5.19.x will be released, 5.18.x will be LTS and 5.17.x not active anymore.

Regards
JB

On Fri, Jun 16, 2023 at 8:39 AM Francois Papon
 wrote:
>
> Hi JB,
>
> Is the 5.17.x will be no more in maintenance after releasing the 5.19.x?
>
> The idea is to keep only 2 release branch active?
>
> regards,
>
> François
>
> On 15/06/2023 15:20, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > FYI, we are preparing ActiveMQ 5.18.2 and 5.17.5 before moving forward
> > on 5.19.x (planned for next month).
> >
> > I hope to be able to submit 5.18.2 and 5.17.5 releases to vote during
> > the weekend.
> >
> > Stay tuned !
> >
> > Regards
> > JB

Re: [HEADS-UP] Preparing Apache ActiveMQ 5.18.2 and 5.17.5 releases

[Jean-Baptiste Onofré]

Hi guys,

I did the Jira triage. I have a couple of fixes on the way. It should
be done by tomorrow. I plan to submit releases to vote on Friday this
week.

Regards
JB

On Thu, Jun 15, 2023 at 3:20 PM Jean-Baptiste Onofré  wrote:
>
> Hi guys,
>
> FYI, we are preparing ActiveMQ 5.18.2 and 5.17.5 before moving forward
> on 5.19.x (planned for next month).
>
> I hope to be able to submit 5.18.2 and 5.17.5 releases to vote during
> the weekend.
>
> Stay tuned !
>
> Regards
> JB

Re: [HEADS-UP] Preparing Apache ActiveMQ 5.18.2 and 5.17.5 releases

[Jean-Baptiste Onofré]

Hi guys

I have a release build issue due to maven plugin updates. I'm fixing that.

I will start the votes today when fixed.

Sorry for this delay. Stay tuned!

Regards
JB

On Thu, Jun 15, 2023 at 3:20 PM Jean-Baptiste Onofré  wrote:
>
> Hi guys,
>
> FYI, we are preparing ActiveMQ 5.18.2 and 5.17.5 before moving forward
> on 5.19.x (planned for next month).
>
> I hope to be able to submit 5.18.2 and 5.17.5 releases to vote during
> the weekend.
>
> Stay tuned !
>
> Regards
> JB

[VOTE] Apache ActiveMQ 5.18.2 release

[Jean-Baptiste Onofré]

Hi,

I submit Apache ActiveMQ 5.18.2 release to your vote. This release is
a maintenance release on the 5.18.x series bringing:
- fix potential NPE when removing consumer with selector
- fix composite consumers in a NoB
- fix memory leak on the STOMP transport when client unsubscribe
- a bunch of dependency updates

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353099

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1283/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.2/

Git tag: activemq-5.18.2

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

[VOTE] Apache ActiveMQ 5.17.5 release

[Jean-Baptiste Onofré]

Hi guys,

I submit Apache ActiveMQ 5.17.5 release to your vote. This release is
a maintenance release on the 5.17.x series bringing:
- fix on stale queues when a connection is long to shutdown
- fix on KahaDB where the db files may be larger than the maxLength
configuration
- fix on composite consumers on NoB
- fix memory leak on STOMP transport when clients unsubscribe
- a bunch of dependency updates

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352888

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1284/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.5/

Git tag: activemq-5.17.5

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

Re: [VOTE] Apache ActiveMQ 5.17.5 release

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Wed, Jun 28, 2023 at 3:40 PM Jean-Baptiste Onofré  wrote:
>
> Hi guys,
>
> I submit Apache ActiveMQ 5.17.5 release to your vote. This release is
> a maintenance release on the 5.17.x series bringing:
> - fix on stale queues when a connection is long to shutdown
> - fix on KahaDB where the db files may be larger than the maxLength
> configuration
> - fix on composite consumers on NoB
> - fix memory leak on STOMP transport when clients unsubscribe
> - a bunch of dependency updates
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352888
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1284/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.5/
>
> Git tag: activemq-5.17.5
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

Re: [VOTE] Apache ActiveMQ 5.18.2 release

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Wed, Jun 28, 2023 at 7:44 AM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> I submit Apache ActiveMQ 5.18.2 release to your vote. This release is
> a maintenance release on the 5.18.x series bringing:
> - fix potential NPE when removing consumer with selector
> - fix composite consumers in a NoB
> - fix memory leak on the STOMP transport when client unsubscribe
> - a bunch of dependency updates
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353099
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1283/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.2/
>
> Git tag: activemq-5.18.2
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

Re: [VOTE] Apache ActiveMQ 5.18.2 release

[Jean-Baptiste Onofré]

Hi Chris

Thanks for fixing that. Yes, it's "just" the test, so I propose to
continue the release (it's already fixed for next release cycle).

Regards
JB

On Fri, Jun 30, 2023 at 12:44 AM Christopher Shannon
 wrote:
>
> FYI for anyone reviewing the release, I noticed that there is a test
> failure in JournalCorruptionEofIndexRecoveryTest but it's the test itself.
> There's already a fix in main here
> https://github.com/apache/activemq/commit/cfbea60d6d but the backport got
> missed.
>
> Since it's just the test that is broken I think it's fine to continue the
> release as is.
>
> On Thu, Jun 29, 2023 at 11:09 AM Matt Pavlovich  wrote:
>
> > +1 (non-binding) successfully ran internal test suite
> >
> > Thanks JB!
> >
> > Matt Pavlovich
> >
> > > On Jun 28, 2023, at 12:44 AM, Jean-Baptiste Onofré 
> > wrote:
> > >
> > > Hi,
> > >
> > > I submit Apache ActiveMQ 5.18.2 release to your vote. This release is
> > > a maintenance release on the 5.18.x series bringing:
> > > - fix potential NPE when removing consumer with selector
> > > - fix composite consumers in a NoB
> > > - fix memory leak on the STOMP transport when client unsubscribe
> > > - a bunch of dependency updates
> > >
> > > You can take a look on the Release Notes for details:
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353099
> > >
> > > Maven Staging Repository:
> > >
> > https://repository.apache.org/content/repositories/orgapacheactivemq-1283/
> > >
> > > Dist Staging Repository:
> > > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.2/
> > >
> > > Git tag: activemq-5.18.2
> > >
> > > Please vote to approve this release:
> > > [ ] +1 Approve the release
> > > [ ] -1 Don't approve the release (please provide specific comments)
> > >
> > > This vote will be open for at least 72 hours.
> > >
> > > Thanks !
> > > Regards
> > > JB
> >
> >

[RESULT][VOTE] Apache ActiveMQ 5.18.2 release

[Jean-Baptiste Onofré]

Hi,

this vote passed with the following result:

+1 (binding): Chris Shannon, JB Onofré, Tim Bish
+1 (non binding): Jamie Goodyear, François Papon, Jean-Louis Monteiro,
Matt Pavlovich

I'm promoting the artifacts on Maven Central and dist.apache.org. I
will update the website and do the announcement.

Thanks all for your vote!

Regards
JB

On Wed, Jun 28, 2023 at 7:44 AM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> I submit Apache ActiveMQ 5.18.2 release to your vote. This release is
> a maintenance release on the 5.18.x series bringing:
> - fix potential NPE when removing consumer with selector
> - fix composite consumers in a NoB
> - fix memory leak on the STOMP transport when client unsubscribe
> - a bunch of dependency updates
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353099
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1283/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.2/
>
> Git tag: activemq-5.18.2
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

[RESULT][VOTE] Apache ActiveMQ 5.17.5 release

[Jean-Baptiste Onofré]

Hi,

this vote passed with the following result:

+1 (binding): Chris Shannon, JB Onofré, Tim Bish
+1 (non binding): Jamie Goodyear, François Papon, Jean-Louis Monteiro,
Matt Pavlovich

I'm promoting the artifacts on Maven Central and dist.apache.org. I
will update the website and do the announcement.

Thanks all for your vote!

Regards
JB

On Wed, Jun 28, 2023 at 3:40 PM Jean-Baptiste Onofré  wrote:
>
> Hi guys,
>
> I submit Apache ActiveMQ 5.17.5 release to your vote. This release is
> a maintenance release on the 5.17.x series bringing:
> - fix on stale queues when a connection is long to shutdown
> - fix on KahaDB where the db files may be larger than the maxLength
> configuration
> - fix on composite consumers on NoB
> - fix memory leak on STOMP transport when clients unsubscribe
> - a bunch of dependency updates
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352888
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1284/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.5/
>
> Git tag: activemq-5.17.5
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

[ANN] Apache ActiveMQ 5.18.2 has been released!

[Jean-Baptiste Onofré]

The ActiveMQ team is pleased to announce Apache ActiveMQ 5.18.2 release.

It’s a maintenance release on the ActiveMQ 5.18.x series, bringing:
- fix potential NPE when removing consumer with selector
- fix composite consumers in a Network of Brokers
- fix memory leak on the STOMP transport when client unsubscribe
- a bunch of dependency updates

You can find details on the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353099

You can download ActiveMQ 5.18.2 here:
https://activemq.apache.org/components/classic/download/

Enjoy!

Regards
---
The Apache ActiveMQ team

[ANN] Apache ActiveMQ 5.17.5 has been released!

[Jean-Baptiste Onofré]

The ActiveMQ team is pleased to announce Apache ActiveMQ 5.17.5 release.

It’s a maintenance release on the ActiveMQ 5.17.x series, bringing:

- fix on stale queues when a connection is long to shutdown
- fix on KahaDB where the db files may be larger than the maxLength
configuration
- fix on composite consumers on a Network of Brokers
- fix memory leak on STOMP transport when client unsubscribe
- a bunch of dependency updates

You can find details on the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352888

You can download ActiveMQ 5.17.5 here:
https://activemq.apache.org/components/classic/download/

Enjoy!

Regards
---
The Apache ActiveMQ team

[INFO] Official Docker images available for Apache ActiveMQ

[Jean-Baptiste Onofré]

Hi,

With the new Apache ActiveMQ 5.18.2 and 5.17.5 releases, we now
publish official docker images.

You can find these images directly on Docker Hub:
https://hub.docker.com/r/apache/activemq/tags

You can pull directly the images with:

docker pull apache/activemq:5.18.2

or

docker pull apache/activemq:latest

Enjoy!
Regards
JB

Re: [DISCUSS] Naming convention for official Docker images

[Jean-Baptiste Onofré]

Hi Justin,

It has been discussed but not the name specifically.

As we use apache/activemq-artemis, I thought "logical" to use
apache/activemq (but maybe activemq-classic makes more sense).

I'm not sure we will be able to use apache/activemq/classic and
apache/activemq/artemis, but we can definitely use
apache/activemq-classic as apache/activemq-artemis.

I can rename right now.

Thoughts ?

Regards
JB


On Mon, Jul 10, 2023 at 3:57 PM Justin Bertram  wrote:
>
> This weekend JB announced [1] the availability of official Docker images
> for ActiveMQ "Classic" in the "apache/activemq" namespace [2].
>
> Perhaps I missed it, but I don't recall (and can't find) any discussion of
> or notification about this. Users will certainly expect images for both
> "Classic" and Artemis so my concern is regarding the namespace. If both
> "Classic" and Artemis share the apache/activemq namespace directly then
> there may eventually be version number conflicts and there certainly will
> be confusion about which version is which.
>
> Before these images are widely adopted I think the namespace should be
> clarified just as it is on the website so that ActiveMQ "Classic" uses
> "apache/activemq/classic" and ActiveMQ Artemis uses
> "apache/activemq/artemis".
>
> Thoughts?
>
>
> Justin
>
> [1] https://lists.apache.org/thread/4cqbm0gsbj184vrp13yorcd2rrbdcsmx
> [2] https://hub.docker.com/r/apache/activemq/tags

Re: [DISCUSS] Naming convention for official Docker images

[Jean-Baptiste Onofré]

Thanks all, I will rename apache/activemq to apache/activemq-classic.

Regards
JB

On Mon, Jul 10, 2023 at 3:57 PM Justin Bertram  wrote:
>
> This weekend JB announced [1] the availability of official Docker images
> for ActiveMQ "Classic" in the "apache/activemq" namespace [2].
>
> Perhaps I missed it, but I don't recall (and can't find) any discussion of
> or notification about this. Users will certainly expect images for both
> "Classic" and Artemis so my concern is regarding the namespace. If both
> "Classic" and Artemis share the apache/activemq namespace directly then
> there may eventually be version number conflicts and there certainly will
> be confusion about which version is which.
>
> Before these images are widely adopted I think the namespace should be
> clarified just as it is on the website so that ActiveMQ "Classic" uses
> "apache/activemq/classic" and ActiveMQ Artemis uses
> "apache/activemq/artemis".
>
> Thoughts?
>
>
> Justin
>
> [1] https://lists.apache.org/thread/4cqbm0gsbj184vrp13yorcd2rrbdcsmx
> [2] https://hub.docker.com/r/apache/activemq/tags

Re: [VOTE] Apache ActiveMQ Artemis 2.30.0

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Fri, Jul 21, 2023 at 3:54 PM Justin Bertram  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.30.0 release.
>
> This is mainly a bug-fix release with a few small improvements and a
> handful of dependency upgrades.
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12353357
>
> Ths git commit report is here:
> https://activemq.apache.org/components/artemis/download/commit-report-2.30.0.html
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.30.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1367
>
> In case you want to give it a try with the maven repo on examples:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
> The source tag:
> https://github.com/apache/activemq-artemis/tree/2.30.0
>
> I will update the website after the vote has passed.
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my +1
>
>
> Justin

Re: [INFO] Official Docker images available for Apache ActiveMQ

[Jean-Baptiste Onofré]

Hi,

I moved the images to the new apache/activemq-classic repository.

You can find the available images here:
https://hub.docker.com/r/apache/activemq-classic/tags

Regards
JB

On Sat, Jul 8, 2023 at 7:31 AM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> With the new Apache ActiveMQ 5.18.2 and 5.17.5 releases, we now
> publish official docker images.
>
> You can find these images directly on Docker Hub:
> https://hub.docker.com/r/apache/activemq/tags
>
> You can pull directly the images with:
>
> docker pull apache/activemq:5.18.2
>
> or
>
> docker pull apache/activemq:latest
>
> Enjoy!
> Regards
> JB

Re: Please help -- board report due next week

[Jean-Baptiste Onofré]

Hi Bruce,

Thanks for the report !
It looks good to me. About Classic, you mentioned the two releases we
did in June and the work about "Jakarta broker" planned for 5.19.x.

We will provide more details in the next report (I should have a more
concrete roadmap about 5.19.x just after my vacations).

Regards
JB

On Thu, Aug 3, 2023 at 5:22 PM Bruce Snyder  wrote:
>
> We just received the notice to submit a board report by Tuesday, Aug 8.
>
> Obviously this is a very short timeline, so please contribute sooner rather
> than later via the following file:
>
> https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt
>
> All project activity is welcome!
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E http://bsnyder.org/ 

Re: Heads up: ActiveMQ 5.x Jakarta broker PR in final review

[Jean-Baptiste Onofré]

Hi,

FYI, I'm resuming the work on AMQ 5.x in order to head to 5.19.0 release.

Regards
JB

On Wed, Aug 30, 2023 at 4:32 PM Matt Pavlovich  wrote:
>
> Heads up-
>
> The Jakarta PR is merged. ‘main’ is now JDK 17, Jakarta, Spring 6, Jetty 11
>
> Thanks,
> Matt Pavlovich
>
> > On Aug 29, 2023, at 10:26 AM, Christopher Shannon 
> >  wrote:
> >
> > Sounds good, I think it's ready to go as anything that needs fixing
> > shouldn't be major and we have time to fix stuff in follow on PRs.
> >
> > It would be good to get 5.19.0 released before too long so it fixes
> > compatibility with Spring 6 and Spring boot 3.
> >
> > When we do release it will be important to have that release page and notes
> > with detailed information about the goal of 5.19.0 and exactly what it does
> > and doesn't support in terms of the Jakarta spec.
> >
> > On Tue, Aug 29, 2023 at 9:42 AM Matt Pavlovich  wrote:
> >
> >> Hey Chris— Thanks for the review.
> >>
> >> I’ll plan to merge the PR this evening and get started on other tasks
> >> ahead of release.
> >>
> >> Thanks,
> >> Matt Pavlovich
> >>
> >>> On Aug 28, 2023, at 5:33 PM, Christopher Shannon <
> >> christopher.l.shan...@gmail.com> wrote:
> >>>
> >>> I'm wrapping up my testing now, I've done a lot of thorough testing with
> >> my
> >>> own custom test suite and things are looking pretty good.
> >>>
> >>> Assuming all my tests look good I will approve the PR shortly and I
> >> figure
> >>> we should give it a couple more days and just go ahead and merge the PR
> >> if
> >>> there are no comments as it's been open for a long time.
> >>>
> >>> There will still be time to make any updates/fixes in follow on PRs
> >> before
> >>> releasing 5.19.0 (such as fixing OpenWire generation and any OSGi fixes)
> >>>
> >>> On Thu, Aug 24, 2023 at 6:13 PM Matt Pavlovich 
> >> wrote:
> >>>
>  Hey All-
> 
>  Heads up— the PR for Jakarta support for the ActiveMQ 5.x broker is in
>  final review.
> 
>  There are a lot of notes in the PR ticket itself. I suggest scrolling
> >> down
>  to the ‘reviewer checklist’ to see the 100 or so files that actually had
>  some code change vs the 1,400+ or so files that have only namespace
> >> changes.
> 
>  https://github.com/apache/activemq/pull/996
> 
>  Thanks!
>  Matt Pavlovich
> >>
> >>
>

Re: [VOTE] Release activemq-nms-api 2.1.0-rc1

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Sun, Sep 10, 2023 at 7:40 PM Havret  wrote:
>
> Hi all,
>
> I have put together another release of activemq-nms-api. Please review it
> and vote accordingly.
>
> This release adds an API allowing users to consume messages asynchronously
> using the new AsyncMessageListener delegate.
>
> The files can be grabbed from:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-api/2.1.0-rc1/
>
> Regards,
> Krzysztof
>
> Here's mine +1 (binding)

[PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

[Jean-Baptiste Onofré]

Hi all,

As you know, ActiveMQ 5.19.x is in preparation with importants
changes: JMS 2, Jakarta namespace, Spring 6, ...

For ActiveMQ 5.19.x, I propose to change the OSGi packaging (client
and broker). Today we have OSGi bundles for client and broker, with
Karaf features installing all dependent features/bundles (spring,
commons-*, etc).
This approach has few issues:
- any update requires SMX bundles or Karaf features, coupling ActiveMQ
OSGi with Karaf (jetty, spring, ...)
- it's very hard to install ActiveMQ OSGi without Karaf
- we can have some side effects depending of what's installed in the
Karaf runtime (we already had refresh issues in the past, amd
cascading refresh)

My proposal is to use a new uber bundle approach for ActiveMQ OSGi
client and broker. The idea is to provide OSGi bundles that
self-contains everything needed to use/run ActiveMQ. The export
packages are the same, but the import packages will be very minimal,
most the packages will go private.
The advantage is that ActiveMQ OSGi doesn't depend on anything at
runtime, it's just a single bundle to install (one bundle for client,
one bundle for broker), no extra dependency (so not release
dependencies like ServiceMix Bundles or Karaf features), dedicated
classloader avoiding refreshes, etc.
The only drawbacks are the size of the ActiveMQ client & broker
bundles (as they ship other packages, is it really a big deal ?) and
the fact that ActiveMQ won't share packages with other bundles (I'm
thinking about Spring bundles for instance).
It's basically using something similar to the apache-activemq
distribution but in OSGi/Karaf.

Thoughts ?

Regards
JB

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

[Jean-Baptiste Onofré]

Hi

We already have shell commands to deal with the broker: we will still
have it, it doesn't change there.

Good comment about Spring, however, imho, it's not OSGi specific: we
would need to replace Spring with something else in ActiveMQ iitself.

Regards
JB

On Mon, Sep 11, 2023 at 11:27 PM fpapon  wrote:
>
> Hi JB,
>
> Sounds good to me.
>
> Just some side questions:
>
> - You're talking about having an embedded broker in Karaf so does it
> mean that we can also have some Karaf command to control the broker?
> (like we can have with Camel)
>
> - About the client, should we will need to use Pax-JMS or not? If not,
> users will use it by reference with an OSGi generic service through the
> service registry?
>
> - If all import package will be private, that is a good thing (big
> bundle size but not a big deal), is there a plan to remove Spring
> framework dependencies and use another lighter IoC framework or be more
> low level with the JDK17 and soon JDK21 for example?
>
> Thanks for your great job on ActiveMQ!
>
> regards,
>
> François
>
> On 11/09/2023 14:07, Jean-Baptiste Onofré wrote:
> > Hi all,
> >
> > As you know, ActiveMQ 5.19.x is in preparation with importants
> > changes: JMS 2, Jakarta namespace, Spring 6, ...
> >
> > For ActiveMQ 5.19.x, I propose to change the OSGi packaging (client
> > and broker). Today we have OSGi bundles for client and broker, with
> > Karaf features installing all dependent features/bundles (spring,
> > commons-*, etc).
> > This approach has few issues:
> > - any update requires SMX bundles or Karaf features, coupling ActiveMQ
> > OSGi with Karaf (jetty, spring, ...)
> > - it's very hard to install ActiveMQ OSGi without Karaf
> > - we can have some side effects depending of what's installed in the
> > Karaf runtime (we already had refresh issues in the past, amd
> > cascading refresh)
> >
> > My proposal is to use a new uber bundle approach for ActiveMQ OSGi
> > client and broker. The idea is to provide OSGi bundles that
> > self-contains everything needed to use/run ActiveMQ. The export
> > packages are the same, but the import packages will be very minimal,
> > most the packages will go private.
> > The advantage is that ActiveMQ OSGi doesn't depend on anything at
> > runtime, it's just a single bundle to install (one bundle for client,
> > one bundle for broker), no extra dependency (so not release
> > dependencies like ServiceMix Bundles or Karaf features), dedicated
> > classloader avoiding refreshes, etc.
> > The only drawbacks are the size of the ActiveMQ client & broker
> > bundles (as they ship other packages, is it really a big deal ?) and
> > the fact that ActiveMQ won't share packages with other bundles (I'm
> > thinking about Spring bundles for instance).
> > It's basically using something similar to the apache-activemq
> > distribution but in OSGi/Karaf.
> >
> > Thoughts ?
> >
> > Regards
> > JB
>
> --
> --
> François
>

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

[Jean-Baptiste Onofré]

Hi,

I disagree, I don't understand why people are against uber bundle. The
export packages stay the same, so ActiveMQ can still "collaborate"
with other bundles. Most of import (not all) will go private, not
necessary all (I'm on a PoC right now).

Regards
JB

On Tue, Sep 12, 2023 at 5:48 AM Christoph Läubrich  wrote:
>
> Making "uberbundles" is really bad not only for file-size, OSGi was made
> with sharing in mind and embedding "everything" will make this
> impossible if you not at the same time rexport the packages what has
> other implications.
>
> Also keep in mind that he activemq could not participate in any other
> things so it never should expose any object from "inside" to the user
> code, also if you now has a refresh you replace these (local) refreshes
> with one big classloader that looses all its state at once, not sure if
> this is better here.
>
> If you want to avoid such issues it is generally better to reduce the
> dependency count, e.g. check if this SMX bundles are really required or
> if they are just used for historic reasons (e.g many things today can be
> replaced by standard java features).
>
> Regarding coupling "OSGi with Karaf" I know for sure some projects using
> activemq without karaf, so this is again just a convenience thing, it is
> easier to use with a karaf feature, but if you have other deployment
> targets why not check what they use and make it convenient there as well?
>
> Am 11.09.23 um 14:07 schrieb Jean-Baptiste Onofré:
> > Hi all,
> >
> > As you know, ActiveMQ 5.19.x is in preparation with importants
> > changes: JMS 2, Jakarta namespace, Spring 6, ...
> >
> > For ActiveMQ 5.19.x, I propose to change the OSGi packaging (client
> > and broker). Today we have OSGi bundles for client and broker, with
> > Karaf features installing all dependent features/bundles (spring,
> > commons-*, etc).
> > This approach has few issues:
> > - any update requires SMX bundles or Karaf features, coupling ActiveMQ
> > OSGi with Karaf (jetty, spring, ...)
> > - it's very hard to install ActiveMQ OSGi without Karaf
> > - we can have some side effects depending of what's installed in the
> > Karaf runtime (we already had refresh issues in the past, amd
> > cascading refresh)
> >
> > My proposal is to use a new uber bundle approach for ActiveMQ OSGi
> > client and broker. The idea is to provide OSGi bundles that
> > self-contains everything needed to use/run ActiveMQ. The export
> > packages are the same, but the import packages will be very minimal,
> > most the packages will go private.
> > The advantage is that ActiveMQ OSGi doesn't depend on anything at
> > runtime, it's just a single bundle to install (one bundle for client,
> > one bundle for broker), no extra dependency (so not release
> > dependencies like ServiceMix Bundles or Karaf features), dedicated
> > classloader avoiding refreshes, etc.
> > The only drawbacks are the size of the ActiveMQ client & broker
> > bundles (as they ship other packages, is it really a big deal ?) and
> > the fact that ActiveMQ won't share packages with other bundles (I'm
> > thinking about Spring bundles for instance).
> > It's basically using something similar to the apache-activemq
> > distribution but in OSGi/Karaf.
> >
> > Thoughts ?
> >
> > Regards
> > JB

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré]

Hi,

I agree and it's actually something we likely discussed while ago
related to renaming as for me we have two really different subprojects
(https://lists.apache.org/thread/f0rqkq01xgyogqownx38k1mdsy69lzvm).

IMHO, ActiveMQ should use 6.x, 7.x, 8.x; ... versioning (and so jump
to 6.x now with Spring 6, Jakarta, and other breaking changes) and
Artemis uses his versioning (2.x; ...).
That's exactly why I proposed to use clear different naming for the community.

So big +1 (as happy to see this discussion again as I started similar
while ago without success, timing is probably better now).

Regards
JB

On Mon, Sep 11, 2023 at 11:14 PM Christopher Shannon
 wrote:
>
> First, I realize that this thread is likely to cause a fight based on past
> history and probably not go anywhere, but with the work being done
> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> ActiveMQ 6.0 discussion.
>
> With all the breaking changes currently targeted for version 5.19.x, such
> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> upgrades and now potentially major OSGi changes, it makes zero sense to me
> to have this next AMQ version as version 5.19.0 as it's completely
> incompatible with the previous version 5.18.x. Users are likely going to be
> in for a rude awakening when trying to upgrade and will be quite confused
> as to why so much is different.
>
> The Jakarta changes should really be a major version upgrade so that it's
> much more clear to users that it's very different from the previous
> version. Another major benefit of going with version 6.0 is that it frees
> up the previous javax releases to continue on with 5.19 or 5.20 because we
> will likely need to support the older javax releases for quite a while.
>
> Also, from my point of view it seems pretty clear that the original goal
> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> its own branding and versioning for several years now and will likely
> continue that way and not change so I don't really see that as a reason to
> not bump AMQ 5.x to 6.x with all the major breaking changes.
>
> Anyways, I figure there won't be much agreement here but thought I should
> at least throw it out there before we go and release 5.19.x with such major
> breaking changes.

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

[Jean-Baptiste Onofré]

About your points:
- I agree with the overhead but is it really an issue ? Having an
atomic bundle is not a bad thing imho
- that's why I said "most of" import packages and today, AMQ broker is
a black box in Karaf/OSGi, so I don't see a difference here
- nobody is doing Spring update or Jetty update in ActiveMQ without
upgrading the whole ActiveMQ, and actually I think it's a good thing
as it's more predictable
- I'm not sure projects actually really try and it really depends of
the use case. Definitely for a library it's not a good approach, but
for "middleware" like AMQ it works fine. I experimented with the same
approach for Camel components and it works just fine. The big
advantage is to avoid OSGi coupling at build time for developers (else
the consequence will be that OSGi will be just removed from the
project like in Camel 4).

Just background: today, ActiveMQ 5.19.x (or 6.x :)) requires updates
that are not yet available in OSGi/Karaf (Spring 6, Jetty 11, jakarta,
..., even if I rushed to provide the SMX bundles required for that,
but it also needs JDK17+). So, as I want to release this new major AMQ
version soon, I have to find a more sustainable approach (to avoid 5+
external releases just for OSGi).

Regards
JB

On Tue, Sep 12, 2023 at 6:26 AM Christoph Läubrich  wrote:
>
>  > I disagree
>
> on what particular point?
>
>  > I don't understand why people are against uber bundle.
>
> Because it has many bad properties:
>
> - You duplicate the code in your bundle, especially for large frameworks
> like spring this can be a major overhead, if someone else is using that
> framework it will be loaded effectively twice (or three time or four if
> other follow your example)
>
> - You will expose your code to subtile class space problem, how will you
> test/ensure that none of the "private" dependencies will ever leak to
> the outside if you still want to allow collaboration?
>
> - Every update to a dependency will require a full ActiveMQ release as
> it is no longer possible to upgrade the dependency independently
>
> - I don't know any project that followed this path with success,
> felix-http even has dropped now their support for embedded jetty (what
> is one of the rare case where this could work quite well).
>
>
> Am 12.09.23 um 06:15 schrieb Jean-Baptiste Onofré:
> > Hi,
> >
> > I disagree, I don't understand why people are against uber bundle. The
> > export packages stay the same, so ActiveMQ can still "collaborate"
> > with other bundles. Most of import (not all) will go private, not
> > necessary all (I'm on a PoC right now).
> >
> > Regards
> > JB
> >
> > On Tue, Sep 12, 2023 at 5:48 AM Christoph Läubrich  
> > wrote:
> >>
> >> Making "uberbundles" is really bad not only for file-size, OSGi was made
> >> with sharing in mind and embedding "everything" will make this
> >> impossible if you not at the same time rexport the packages what has
> >> other implications.
> >>
> >> Also keep in mind that he activemq could not participate in any other
> >> things so it never should expose any object from "inside" to the user
> >> code, also if you now has a refresh you replace these (local) refreshes
> >> with one big classloader that looses all its state at once, not sure if
> >> this is better here.
> >>
> >> If you want to avoid such issues it is generally better to reduce the
> >> dependency count, e.g. check if this SMX bundles are really required or
> >> if they are just used for historic reasons (e.g many things today can be
> >> replaced by standard java features).
> >>
> >> Regarding coupling "OSGi with Karaf" I know for sure some projects using
> >> activemq without karaf, so this is again just a convenience thing, it is
> >> easier to use with a karaf feature, but if you have other deployment
> >> targets why not check what they use and make it convenient there as well?
> >>
> >> Am 11.09.23 um 14:07 schrieb Jean-Baptiste Onofré:
> >>> Hi all,
> >>>
> >>> As you know, ActiveMQ 5.19.x is in preparation with importants
> >>> changes: JMS 2, Jakarta namespace, Spring 6, ...
> >>>
> >>> For ActiveMQ 5.19.x, I propose to change the OSGi packaging (client
> >>> and broker). Today we have OSGi bundles for client and broker, with
> >>> Karaf features installing all dependent features/bundles (spring,
> >>> commons-*, etc).
> >>> This approach has few issues:
> >>> - any update req

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

[Jean-Baptiste Onofré]

Ok fair enough.

I will update the features and OSGi bundles accordingly.

Regards
JB

Le mar. 12 sept. 2023 à 10:41, Robbie Gemmell  a
écrit :

> I'm really glad someone already noted the various disadvantages of
> uber jars that I thought of when reading the original email. Saved me
> some typing.
>
> I'd only expand upon the "Every update to a dependency will require a
> full ActiveMQ release" point to more directly call it out as being a
> security concern as well. You can't as easily establish what
> potentially vulnerable bits are being used in an uberjar, and even if
> you know everything in there you then still need the whole thing
> released.
>
> On Tue, 12 Sept 2023 at 05:26, Christoph Läubrich 
> wrote:
> >
> >  > I disagree
> >
> > on what particular point?
> >
> >  > I don't understand why people are against uber bundle.
> >
> > Because it has many bad properties:
> >
> > - You duplicate the code in your bundle, especially for large frameworks
> > like spring this can be a major overhead, if someone else is using that
> > framework it will be loaded effectively twice (or three time or four if
> > other follow your example)
> >
> > - You will expose your code to subtile class space problem, how will you
> > test/ensure that none of the "private" dependencies will ever leak to
> > the outside if you still want to allow collaboration?
> >
> > - Every update to a dependency will require a full ActiveMQ release as
> > it is no longer possible to upgrade the dependency independently
> >
> > - I don't know any project that followed this path with success,
> > felix-http even has dropped now their support for embedded jetty (what
> > is one of the rare case where this could work quite well).
> >
> >
> > Am 12.09.23 um 06:15 schrieb Jean-Baptiste Onofré:
> > > Hi,
> > >
> > > I disagree, I don't understand why people are against uber bundle. The
> > > export packages stay the same, so ActiveMQ can still "collaborate"
> > > with other bundles. Most of import (not all) will go private, not
> > > necessary all (I'm on a PoC right now).
> > >
> > > Regards
> > > JB
> > >
> > > On Tue, Sep 12, 2023 at 5:48 AM Christoph Läubrich <
> m...@laeubi-soft.de> wrote:
> > >>
> > >> Making "uberbundles" is really bad not only for file-size, OSGi was
> made
> > >> with sharing in mind and embedding "everything" will make this
> > >> impossible if you not at the same time rexport the packages what has
> > >> other implications.
> > >>
> > >> Also keep in mind that he activemq could not participate in any other
> > >> things so it never should expose any object from "inside" to the user
> > >> code, also if you now has a refresh you replace these (local)
> refreshes
> > >> with one big classloader that looses all its state at once, not sure
> if
> > >> this is better here.
> > >>
> > >> If you want to avoid such issues it is generally better to reduce the
> > >> dependency count, e.g. check if this SMX bundles are really required
> or
> > >> if they are just used for historic reasons (e.g many things today can
> be
> > >> replaced by standard java features).
> > >>
> > >> Regarding coupling "OSGi with Karaf" I know for sure some projects
> using
> > >> activemq without karaf, so this is again just a convenience thing, it
> is
> > >> easier to use with a karaf feature, but if you have other deployment
> > >> targets why not check what they use and make it convenient there as
> well?
> > >>
> > >> Am 11.09.23 um 14:07 schrieb Jean-Baptiste Onofré:
> > >>> Hi all,
> > >>>
> > >>> As you know, ActiveMQ 5.19.x is in preparation with importants
> > >>> changes: JMS 2, Jakarta namespace, Spring 6, ...
> > >>>
> > >>> For ActiveMQ 5.19.x, I propose to change the OSGi packaging (client
> > >>> and broker). Today we have OSGi bundles for client and broker, with
> > >>> Karaf features installing all dependent features/bundles (spring,
> > >>> commons-*, etc).
> > >>> This approach has few issues:
> > >>> - any update requires SMX bundles or Karaf features, coupling
> ActiveMQ
> > >>> OSGi with Karaf (jetty, spring, ...)
> > >&g

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré]

As we didn’t have consensus I paused on this one. But happy to prepare a
formal website PR with dedicated area etc.

Regards
JB

Le mar. 12 sept. 2023 à 10:54, Robbie Gemmell  a
écrit :

> Have you got any work towards the linked proposals idea of refreshing
> the old 5.x docs etc on the website under its component area?
>
> On Tue, 12 Sept 2023 at 05:23, Jean-Baptiste Onofré 
> wrote:
> >
> > Hi,
> >
> > I agree and it's actually something we likely discussed while ago
> > related to renaming as for me we have two really different subprojects
> > (https://lists.apache.org/thread/f0rqkq01xgyogqownx38k1mdsy69lzvm).
> >
> > IMHO, ActiveMQ should use 6.x, 7.x, 8.x; ... versioning (and so jump
> > to 6.x now with Spring 6, Jakarta, and other breaking changes) and
> > Artemis uses his versioning (2.x; ...).
> > That's exactly why I proposed to use clear different naming for the
> community.
> >
> > So big +1 (as happy to see this discussion again as I started similar
> > while ago without success, timing is probably better now).
> >
> > Regards
> > JB
> >
> > On Mon, Sep 11, 2023 at 11:14 PM Christopher Shannon
> >  wrote:
> > >
> > > First, I realize that this thread is likely to cause a fight based on
> past
> > > history and probably not go anywhere, but with the work being done
> > > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > > ActiveMQ 6.0 discussion.
> > >
> > > With all the breaking changes currently targeted for version 5.19.x,
> such
> > > as the Jakarta switch from javax, requiring JDK 17, major Spring and
> Jetty
> > > upgrades and now potentially major OSGi changes, it makes zero sense
> to me
> > > to have this next AMQ version as version 5.19.0 as it's completely
> > > incompatible with the previous version 5.18.x. Users are likely going
> to be
> > > in for a rude awakening when trying to upgrade and will be quite
> confused
> > > as to why so much is different.
> > >
> > > The Jakarta changes should really be a major version upgrade so that
> it's
> > > much more clear to users that it's very different from the previous
> > > version. Another major benefit of going with version 6.0 is that it
> frees
> > > up the previous javax releases to continue on with 5.19 or 5.20
> because we
> > > will likely need to support the older javax releases for quite a while.
> > >
> > > Also, from my point of view it seems pretty clear that the original
> goal
> > > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has
> had
> > > its own branding and versioning for several years now and will likely
> > > continue that way and not change so I don't really see that as a
> reason to
> > > not bump AMQ 5.x to 6.x with all the major breaking changes.
> > >
> > > Anyways, I figure there won't be much agreement here but thought I
> should
> > > at least throw it out there before we go and release 5.19.x with such
> major
> > > breaking changes.
>

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

[Jean-Baptiste Onofré]

Just to be clear: I will keep the current approach upgrading to spring 6
etc. In the meantime, I will work on SMX/Karaf requirements for ActiveMQ.

Regards
JB

Le mar. 12 sept. 2023 à 10:51, Jean-Baptiste Onofré  a
écrit :

> Ok fair enough.
>
> I will update the features and OSGi bundles accordingly.
>
> Regards
> JB
>
> Le mar. 12 sept. 2023 à 10:41, Robbie Gemmell 
> a écrit :
>
>> I'm really glad someone already noted the various disadvantages of
>> uber jars that I thought of when reading the original email. Saved me
>> some typing.
>>
>> I'd only expand upon the "Every update to a dependency will require a
>> full ActiveMQ release" point to more directly call it out as being a
>> security concern as well. You can't as easily establish what
>> potentially vulnerable bits are being used in an uberjar, and even if
>> you know everything in there you then still need the whole thing
>> released.
>>
>> On Tue, 12 Sept 2023 at 05:26, Christoph Läubrich 
>> wrote:
>> >
>> >  > I disagree
>> >
>> > on what particular point?
>> >
>> >  > I don't understand why people are against uber bundle.
>> >
>> > Because it has many bad properties:
>> >
>> > - You duplicate the code in your bundle, especially for large frameworks
>> > like spring this can be a major overhead, if someone else is using that
>> > framework it will be loaded effectively twice (or three time or four if
>> > other follow your example)
>> >
>> > - You will expose your code to subtile class space problem, how will you
>> > test/ensure that none of the "private" dependencies will ever leak to
>> > the outside if you still want to allow collaboration?
>> >
>> > - Every update to a dependency will require a full ActiveMQ release as
>> > it is no longer possible to upgrade the dependency independently
>> >
>> > - I don't know any project that followed this path with success,
>> > felix-http even has dropped now their support for embedded jetty (what
>> > is one of the rare case where this could work quite well).
>> >
>> >
>> > Am 12.09.23 um 06:15 schrieb Jean-Baptiste Onofré:
>> > > Hi,
>> > >
>> > > I disagree, I don't understand why people are against uber bundle. The
>> > > export packages stay the same, so ActiveMQ can still "collaborate"
>> > > with other bundles. Most of import (not all) will go private, not
>> > > necessary all (I'm on a PoC right now).
>> > >
>> > > Regards
>> > > JB
>> > >
>> > > On Tue, Sep 12, 2023 at 5:48 AM Christoph Läubrich <
>> m...@laeubi-soft.de> wrote:
>> > >>
>> > >> Making "uberbundles" is really bad not only for file-size, OSGi was
>> made
>> > >> with sharing in mind and embedding "everything" will make this
>> > >> impossible if you not at the same time rexport the packages what has
>> > >> other implications.
>> > >>
>> > >> Also keep in mind that he activemq could not participate in any other
>> > >> things so it never should expose any object from "inside" to the user
>> > >> code, also if you now has a refresh you replace these (local)
>> refreshes
>> > >> with one big classloader that looses all its state at once, not sure
>> if
>> > >> this is better here.
>> > >>
>> > >> If you want to avoid such issues it is generally better to reduce the
>> > >> dependency count, e.g. check if this SMX bundles are really required
>> or
>> > >> if they are just used for historic reasons (e.g many things today
>> can be
>> > >> replaced by standard java features).
>> > >>
>> > >> Regarding coupling "OSGi with Karaf" I know for sure some projects
>> using
>> > >> activemq without karaf, so this is again just a convenience thing,
>> it is
>> > >> easier to use with a karaf feature, but if you have other deployment
>> > >> targets why not check what they use and make it convenient there as
>> well?
>> > >>
>> > >> Am 11.09.23 um 14:07 schrieb Jean-Baptiste Onofré:
>> > >>> Hi all,
>> > >>>
>> > >>> As you know, ActiveMQ 5.19.x is in preparation with importants
>> > >>>

Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x

[Jean-Baptiste Onofré]

I ack your point (even if I don't necessarily agree regarding my
experience with AMQ/Karaf/OSGi :)), and we have a consensus. As I
said, I will continue the current approach with the required upgrades.

Regards
JB

On Tue, Sep 12, 2023 at 11:01 AM Christoph Läubrich  wrote:
>
>  > I agree with the overhead but is it really an issue
>
> Of course it is an issue (depending on how much you embedd), at least it
> vast disk, cpu, ram and network resources
>
>  > AMQ broker is a black box in Karaf/OSGi
>
> So no configuration? No plugins? No management possible? Client only
> ever use plain JMS standard API?
>
>  > nobody is doing Spring update or Jetty update in ActiveMQ without
>  > upgrading the whole ActiveMQ
>
> Not in ActiveMQ but in OSGi... so if you require Spring version 9.3 or
> later and Spring releases 9.3.1 I can upgrade the Spring bundles and I'm
> done, with uber-jar/bundle/war/... I need to ask for a new ActiveMQ
> release and then get additional delay even if it would be released fast...
>
>  > The big advantage is to avoid OSGi coupling at build time
>  > for developers
>
> Why should a developer ever be "coupled" to OSGi at build time and why
> should this change that there is one or multiple bundles? And even for
> ActiveMQ build itself you can always just generate the OSGi metadata
> separately and don't need to think about OSGi at all.
>
> As Karaf can even wrap bundles dynamically you even don't need OSGi
> metadata at all for third party libs you depend on.
>
>
> Am 12.09.23 um 07:53 schrieb Jean-Baptiste Onofré:
> > About your points:
> > - I agree with the overhead but is it really an issue ? Having an
> > atomic bundle is not a bad thing imho
> > - that's why I said "most of" import packages and today, AMQ broker is
> > a black box in Karaf/OSGi, so I don't see a difference here
> > - nobody is doing Spring update or Jetty update in ActiveMQ without
> > upgrading the whole ActiveMQ, and actually I think it's a good thing
> > as it's more predictable
> > - I'm not sure projects actually really try and it really depends of
> > the use case. Definitely for a library it's not a good approach, but
> > for "middleware" like AMQ it works fine. I experimented with the same
> > approach for Camel components and it works just fine. The big
> > advantage is to avoid OSGi coupling at build time for developers (else
> > the consequence will be that OSGi will be just removed from the
> > project like in Camel 4).
> >
> > Just background: today, ActiveMQ 5.19.x (or 6.x :)) requires updates
> > that are not yet available in OSGi/Karaf (Spring 6, Jetty 11, jakarta,
> > ..., even if I rushed to provide the SMX bundles required for that,
> > but it also needs JDK17+). So, as I want to release this new major AMQ
> > version soon, I have to find a more sustainable approach (to avoid 5+
> > external releases just for OSGi).
> >
> > Regards
> > JB
> >
> > On Tue, Sep 12, 2023 at 6:26 AM Christoph Läubrich  
> > wrote:
> >>
> >>   > I disagree
> >>
> >> on what particular point?
> >>
> >>   > I don't understand why people are against uber bundle.
> >>
> >> Because it has many bad properties:
> >>
> >> - You duplicate the code in your bundle, especially for large frameworks
> >> like spring this can be a major overhead, if someone else is using that
> >> framework it will be loaded effectively twice (or three time or four if
> >> other follow your example)
> >>
> >> - You will expose your code to subtile class space problem, how will you
> >> test/ensure that none of the "private" dependencies will ever leak to
> >> the outside if you still want to allow collaboration?
> >>
> >> - Every update to a dependency will require a full ActiveMQ release as
> >> it is no longer possible to upgrade the dependency independently
> >>
> >> - I don't know any project that followed this path with success,
> >> felix-http even has dropped now their support for embedded jetty (what
> >> is one of the rare case where this could work quite well).
> >>
> >>
> >> Am 12.09.23 um 06:15 schrieb Jean-Baptiste Onofré:
> >>> Hi,
> >>>
> >>> I disagree, I don't understand why people are against uber bundle. The
> >>> export packages stay the same, so ActiveMQ can still "collaborate"
> >>> with other bundles. Most of import (not all) will go pri

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré]

Is it a good time to talk about ActiveMQ "Something" instead of
"Classic" ? (I hate this "classic" naming (it sounds weird to me) and
most of people uses simply Artemis and ActiveMQ as name)

I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother of
Artemis in Greek mythology) to have a clear distinction between the
two subprojects. Thoughts ? :)

If it's too "sensible", please ignore :)

Regards
JB

On Tue, Sep 12, 2023 at 11:11 AM Gary Tully  wrote:
>
> makes sense, but please keep a clear distinction - activemq classic 6.0.0
> activemq X may still evolve to combine the best of both.
>
> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > First, I realize that this thread is likely to cause a fight based on past
> > history and probably not go anywhere, but with the work being done
> > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > ActiveMQ 6.0 discussion.
> >
> > With all the breaking changes currently targeted for version 5.19.x, such
> > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > upgrades and now potentially major OSGi changes, it makes zero sense to me
> > to have this next AMQ version as version 5.19.0 as it's completely
> > incompatible with the previous version 5.18.x. Users are likely going to be
> > in for a rude awakening when trying to upgrade and will be quite confused
> > as to why so much is different.
> >
> > The Jakarta changes should really be a major version upgrade so that it's
> > much more clear to users that it's very different from the previous
> > version. Another major benefit of going with version 6.0 is that it frees
> > up the previous javax releases to continue on with 5.19 or 5.20 because we
> > will likely need to support the older javax releases for quite a while.
> >
> > Also, from my point of view it seems pretty clear that the original goal
> > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > its own branding and versioning for several years now and will likely
> > continue that way and not change so I don't really see that as a reason to
> > not bump AMQ 5.x to 6.x with all the major breaking changes.
> >
> > Anyways, I figure there won't be much agreement here but thought I should
> > at least throw it out there before we go and release 5.19.x with such major
> > breaking changes.
> >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré]

That makes lot of sense to me ! We will have:

- ActiveMQ 5.18.x
- ActiveMQ 6.x.x
- ActiveMQ 7.x.x
- ActiveMQ Artemis 2.x
- ActiveMQ Artemis 3.x

So, I propose to have two "spaces" on website:
http://activemq.apache.org/activemq
http://activemq.apache.org/artemis

The index.html will list the two spaces and users will go to one or another.

Thoughts ?

Regards
JB

On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell  wrote:
>
> ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
>
> On Tue, 12 Sept 2023 at 13:34, Francois Papon
>  wrote:
> >
> > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> >
> > On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > That is how I refer to them, or more fully as ActiveMQ 5.x like below,
> > > and ActiveMQ Artemis.
> > >
> > > Same as last time this was discussed, I dont consider "Classic" part
> > > of the actual name, just a reflective description label, quoted for a
> > > reason.
> > >
> > > On Tue, 12 Sept 2023 at 12:48, fpapon  wrote:
> > >> Why not simply ActiveMQ and Artemis?
> > >>
> > >> This is how people used to name the 2 projects, I never eared someone
> > >> say "ActiveMQ Classic".
> > >>
> > >> regards,
> > >>
> > >> François
> > >>
> > >> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > >>> Same thoughts as last time you proposed it really. Adding Leto would
> > >>> not be an improvement for me, more actually the reverse. I think it's
> > >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > >>> confusing. Describing something as 'classic' is a pretty normal /
> > >>> well-known thing, I think a user even noted that on the original
> > >>> thread.
> > >>>
> > >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré  
> > >>> wrote:
> > >>>> Is it a good time to talk about ActiveMQ "Something" instead of
> > >>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me) and
> > >>>> most of people uses simply Artemis and ActiveMQ as name)
> > >>>>
> > >>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother of
> > >>>> Artemis in Greek mythology) to have a clear distinction between the
> > >>>> two subprojects. Thoughts ? :)
> > >>>>
> > >>>> If it's too "sensible", please ignore :)
> > >>>>
> > >>>> Regards
> > >>>> JB
> > >>>>
> > >>>> On Tue, Sep 12, 2023 at 11:11 AM Gary Tully  wrote:
> > >>>>> makes sense, but please keep a clear distinction - activemq classic 
> > >>>>> 6.0.0
> > >>>>> activemq X may still evolve to combine the best of both.
> > >>>>>
> > >>>>> On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
> > >>>>> christopher.l.shan...@gmail.com> wrote:
> > >>>>>
> > >>>>>> First, I realize that this thread is likely to cause a fight based 
> > >>>>>> on past
> > >>>>>> history and probably not go anywhere, but with the work being done
> > >>>>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > >>>>>> ActiveMQ 6.0 discussion.
> > >>>>>>
> > >>>>>> With all the breaking changes currently targeted for version 5.19.x, 
> > >>>>>> such
> > >>>>>> as the Jakarta switch from javax, requiring JDK 17, major Spring and 
> > >>>>>> Jetty
> > >>>>>> upgrades and now potentially major OSGi changes, it makes zero sense 
> > >>>>>> to me
> > >>>>>> to have this next AMQ version as version 5.19.0 as it's completely
> > >>>>>> incompatible with the previous version 5.18.x. Users are likely 
> > >>>>>> going to be
> > >>>>>> in for a rude awakening when trying to upgrade and will be quite 
> > >>>>>> confused
> > >>>>>> as to why so much is different.
> > >>>>>>
> > >>>>>> The Jakarta changes should really be a major version upgrade so that 
> > >>>>>> it's
> > >>>>>> much more clear to users that it's very different from the previous
> > >>>>>> version. Another major benefit of going with version 6.0 is that it 
> > >>>>>> frees
> > >>>>>> up the previous javax releases to continue on with 5.19 or 5.20 
> > >>>>>> because we
> > >>>>>> will likely need to support the older javax releases for quite a 
> > >>>>>> while.
> > >>>>>>
> > >>>>>> Also, from my point of view it seems pretty clear that the original 
> > >>>>>> goal
> > >>>>>> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis 
> > >>>>>> has had
> > >>>>>> its own branding and versioning for several years now and will likely
> > >>>>>> continue that way and not change so I don't really see that as a 
> > >>>>>> reason to
> > >>>>>> not bump AMQ 5.x to 6.x with all the major breaking changes.
> > >>>>>>
> > >>>>>> Anyways, I figure there won't be much agreement here but thought I 
> > >>>>>> should
> > >>>>>> at least throw it out there before we go and release 5.19.x with 
> > >>>>>> such major
> > >>>>>> breaking changes.
> > >>>>>>
> > >> --
> > >> --
> > >> François
> > >>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré]

Hi Justin

My point is not about the URL (absolutely right we can use our
existing URLs using "components"
https://activemq.apache.org/components/classic/
https://activemq.apache.org/components/artemis/ etc). My point is more
in the content and look'n feel. I think we should restyle/rework the
documentation:
- new more pro & sexy look'n feel
- verifying/updating content
- adding some more kind of examples/use cases

Regards
JB

On Tue, Sep 12, 2023 at 4:03 PM Justin Bertram  wrote:
>
> I still think it's important to have some kind of specific name or tag
> (e.g. "Classic") to differentiate the two brokers, especially on the
> website where the two are "next to" each other. Using a version number just
> doesn't cut it in my opinion. For example, what happens when Artemis'
> version number catches up to 6.x, etc.? You won't be able to use the
> version number anymore to differentiate the two.
>
> Clarity is really important for everyone in the community - especially in
> support scenarios. I work a lot on Stack Overflow with folks using both
> brokers and having a verbal umbrella for each is extremely helpful.
>
>
> Justin
>
> On Tue, Sep 12, 2023 at 8:35 AM Jean-Baptiste Onofré 
> wrote:
>
> > That makes lot of sense to me ! We will have:
> >
> > - ActiveMQ 5.18.x
> > - ActiveMQ 6.x.x
> > - ActiveMQ 7.x.x
> > - ActiveMQ Artemis 2.x
> > - ActiveMQ Artemis 3.x
> >
> > So, I propose to have two "spaces" on website:
> > http://activemq.apache.org/activemq
> > http://activemq.apache.org/artemis
> >
> > The index.html will list the two spaces and users will go to one or
> > another.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell 
> > wrote:
> > >
> > > ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> > >
> > > On Tue, 12 Sept 2023 at 13:34, Francois Papon
> > >  wrote:
> > > >
> > > > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> > > >
> > > > On 12/09/2023 14:14, Robbie Gemmell wrote:
> > > > > That is how I refer to them, or more fully as ActiveMQ 5.x like
> > below,
> > > > > and ActiveMQ Artemis.
> > > > >
> > > > > Same as last time this was discussed, I dont consider "Classic" part
> > > > > of the actual name, just a reflective description label, quoted for a
> > > > > reason.
> > > > >
> > > > > On Tue, 12 Sept 2023 at 12:48, fpapon  wrote:
> > > > >> Why not simply ActiveMQ and Artemis?
> > > > >>
> > > > >> This is how people used to name the 2 projects, I never eared
> > someone
> > > > >> say "ActiveMQ Classic".
> > > > >>
> > > > >> regards,
> > > > >>
> > > > >> François
> > > > >>
> > > > >> On 12/09/2023 13:07, Robbie Gemmell wrote:
> > > > >>> Same thoughts as last time you proposed it really. Adding Leto
> > would
> > > > >>> not be an improvement for me, more actually the reverse. I think
> > it's
> > > > >>> fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
> > > > >>> confusing. Describing something as 'classic' is a pretty normal /
> > > > >>> well-known thing, I think a user even noted that on the original
> > > > >>> thread.
> > > > >>>
> > > > >>> On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> > j...@nanthrax.net> wrote:
> > > > >>>> Is it a good time to talk about ActiveMQ "Something" instead of
> > > > >>>> "Classic" ? (I hate this "classic" naming (it sounds weird to me)
> > and
> > > > >>>> most of people uses simply Artemis and ActiveMQ as name)
> > > > >>>>
> > > > >>>> I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother
> > of
> > > > >>>> Artemis in Greek mythology) to have a clear distinction between
> > the
> > > > >>>> two subprojects. Thoughts ? :)
> > > > >>>>
> > > > >>>> If it's too "sensible", please ignore :)
> > > > >>>>
> > > > >>>> Regards
> > > >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré]

I agree about naming. Let's use "Classic" on the index.html page, but
not necessary on the "component"/subpage (here we can use ActiveMQ as
shortcut).

About the version, it seems we are heading to a consensus. Let's wait
an additional 24 hours, then, if there are no objections, I will use
6.0.0-SNAPSHOT version on main branch, heading to the 6.0.0 release.

Thanks !
Regards
JB

On Thu, Sep 14, 2023 at 12:43 PM Christopher Shannon
 wrote:
>
> I am ok with whatever makes sense to distinguish the brokers. If people are
> starting to use "classic" that is fine. As I previously said I don't think
> we necessarily need to make the naming discussion as part of the versioning
> discussion.
>
> I am planning to leave this thread open for another day or so to see if
> there is more feedback but if there's no big objections I will start a vote
> thread for just bumping the AMQ version to 6.0.0 and we can leave open the
> discussion for what to do about the "Classic" name as a separate topic.
>
> On Thu, Sep 14, 2023 at 5:14 AM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
> > Same, when I have to mention both in the same discussion, I tend to add
> > "classic" for ActiveMQ to make sure there is no confusion with Artemis.
> > But that's basically it.
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Wed, Sep 13, 2023 at 5:43 AM Arthur Naseef 
> > wrote:
> >
> > > As a general practice, I try to avoid unqualified + qualified names
> > > together - it gets confusing.  However, in this case, we have a
> > > long-established history.
> > >
> > > I believe that a formal rename of ActiveMQ would be fairly disruptive
> > for a
> > > small amount of value.
> > >
> > > For the record - I have heard, and started using, the term "ActiveMQ
> > > Classic" when talking about ActiveMQ + Artemis in the same discussion.
> > >
> > > Art
> > >
> > >
> > > On Tue, Sep 12, 2023 at 1:52 PM David Blevins 
> > > wrote:
> > >
> > > >
> > > >
> > > > > On Sep 12, 2023, at 7:15 AM, Jeff Genender 
> > > wrote:
> > > > >
> > > > > +1 to what Christopher said... I have rarely heard AMQ 5.x being
> > > > referred to as classic.  Most of our users just say "ActiveMQ" or
> > > "Artemis".
> > > >
> > > > Same.  I've never heard anyone contact us and say "Classic".  Always
> > just
> > > > "ActiveMQ" and "Artemis"
> > > >
> > > >
> > > > -David
> > > >
> > > > > On 2023/09/12 13:44:15 Christopher Shannon wrote:
> > > > >> I don't really see a need for "Classic" and I think it should be
> > > > dropped.
> > > > >> No one uses it and just refers to it as "ActiveMQ 5.x".
> > > > >>
> > > > >> ActiveMQ Artemis has had its own versioning and brand since the
> > > > beginning
> > > > >> going back many years so I don't think getting rid of "Classic" is
> > an
> > > > issue
> > > > >> or would lead to any confusion since as I said, no one uses it
> > > anyways.
> > > > >>
> > > > >> So I think it makes sense to just go with what JB said for now:
> > > > >>
> > > > >> - ActiveMQ 5.18.x
> > > > >> - ActiveMQ 6.x.x
> > > > >> - ActiveMQ 7.x.x
> > > > >> - ActiveMQ Artemis 2.x
> > > > >> - ActiveMQ Artemis 3.x
> > > > >>
> > > > >> That would be quite clear as to what each version is.
> > > > >>
> > > > >> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré <
> > j...@nanthrax.net
> > > >
> > > > >> wrote:
> > > > >>
> > > > >>> That makes lot of sense to me ! We will have:
> > > > >>>
> > > > >>> - ActiveMQ 5.18.x
> > > > >>> - ActiveMQ 6.x.x
> > > > >>> - ActiveMQ 7.x.x
> > > > >>> - ActiveMQ Artemis 2.x
> > > > >>> - ActiveMQ Artemis 3.x
> > > > >>>
> > > > >>> So, I propose to have two "spaces" on website:
> > &g

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré]

Hi,

The main change is JDK17 required by the update to Spring 6.x, this is
actually the update that implies a new version (ActiveMQ is coupled to
Spring right now).

About jakarta, even on Artemis, I guess you had an impact for the
users as you moved client from javax.jms to jakarta.jms, right ?
Broker side, it's transparent for users, but not client side imho.

Regards
JB

On Thu, Sep 14, 2023 at 5:15 PM Justin Bertram  wrote:
>
> I don't have a deep familiarity with the internals here so some of the
> fundamentals behind the changes aren't clear to me.
>
> Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How
> tightly is "Classic" coupled with Spring?
>
> Is the coupling with Spring also why the code-base is being moved
> whole-sale to Jakarta? It's been a little while now, but when Artemis
> implemented Jakarta support back in early 2021 I don't recall any
> disruption for current users and no major version change was needed. Both
> Java EE and Jakarta EE implementations are based on the same code-base. Is
> something like that not possible here? It would simplify maintenance a lot
> since fixes/features wouldn't have to be back-ported.
>
>
> Justin
>
> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > First, I realize that this thread is likely to cause a fight based on past
> > history and probably not go anywhere, but with the work being done
> > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > ActiveMQ 6.0 discussion.
> >
> > With all the breaking changes currently targeted for version 5.19.x, such
> > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > upgrades and now potentially major OSGi changes, it makes zero sense to me
> > to have this next AMQ version as version 5.19.0 as it's completely
> > incompatible with the previous version 5.18.x. Users are likely going to be
> > in for a rude awakening when trying to upgrade and will be quite confused
> > as to why so much is different.
> >
> > The Jakarta changes should really be a major version upgrade so that it's
> > much more clear to users that it's very different from the previous
> > version. Another major benefit of going with version 6.0 is that it frees
> > up the previous javax releases to continue on with 5.19 or 5.20 because we
> > will likely need to support the older javax releases for quite a while.
> >
> > Also, from my point of view it seems pretty clear that the original goal
> > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > its own branding and versioning for several years now and will likely
> > continue that way and not change so I don't really see that as a reason to
> > not bump AMQ 5.x to 6.x with all the major breaking changes.
> >
> > Anyways, I figure there won't be much agreement here but thought I should
> > at least throw it out there before we go and release 5.19.x with such major
> > breaking changes.
> >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré]

I agree and that's ActiveMQ 5.x stays with javax.jms and ActiveMQ 6.x
changes to jakarta.jms.

So we are fully aligned and it shows that ActiveMQ 6.x is cleaner.
If users want to still use javax.jms then they will use ActiveMQ 5.x,
if they want to use jakarta.jms, they will use ActiveMQ 6.x.

It's clear like this imho.

Regards
JB

On Thu, Sep 14, 2023 at 5:57 PM Robbie Gemmell  wrote:
>
> In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the
> broker side and also uses the same classes as the client for various
> stuff, so it has to be fully converted so you can use broker + client
> in the same application/test without resorting to containers etc. The
> 5.x javax broker and jakarta client simply cant be used in the same
> classloader.
>
> 5.x also uses Spring for various bits and a jakarta conversion means
> using Spring 6, which requires Java 17 as you noted (related aside: 17
> wont be the current LTS as of next week, with Java 21
> releasing...which has effectively been finalised for a month now since
> there was no RC2).
>
> So essentially it is not as simple to have 'javax modules' and
> 'jakarta modules' in the same tree for 5.x like it was for the Artemis
> codebase back in February 2021 when that was originally done. That
> made a lot of sense at the time since noone was really using them back
> then. Going forward, I do think having 2 versions is actually
> preferable, and thats what I choose to do elsewhere, and what I'd say
> most (but, not all) projects are doing at this later point. It does
> mean backporting things if supporting both, but also means a simpler
> build and a nicer testing situation etc, and slightly less user change
> (just updating the version, not knowing new -jakarta dep exists and
> also updating version).
>
> On Thu, 14 Sept 2023 at 16:16, Justin Bertram  wrote:
> >
> > I don't have a deep familiarity with the internals here so some of the
> > fundamentals behind the changes aren't clear to me.
> >
> > Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How
> > tightly is "Classic" coupled with Spring?
> >
> > Is the coupling with Spring also why the code-base is being moved
> > whole-sale to Jakarta? It's been a little while now, but when Artemis
> > implemented Jakarta support back in early 2021 I don't recall any
> > disruption for current users and no major version change was needed. Both
> > Java EE and Jakarta EE implementations are based on the same code-base. Is
> > something like that not possible here? It would simplify maintenance a lot
> > since fixes/features wouldn't have to be back-ported.
> >
> >
> > Justin
> >
> > On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > > First, I realize that this thread is likely to cause a fight based on past
> > > history and probably not go anywhere, but with the work being done
> > > with Jakarta for AMQ 5.x I think it's time to at least bring up the
> > > ActiveMQ 6.0 discussion.
> > >
> > > With all the breaking changes currently targeted for version 5.19.x, such
> > > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> > > upgrades and now potentially major OSGi changes, it makes zero sense to me
> > > to have this next AMQ version as version 5.19.0 as it's completely
> > > incompatible with the previous version 5.18.x. Users are likely going to 
> > > be
> > > in for a rude awakening when trying to upgrade and will be quite confused
> > > as to why so much is different.
> > >
> > > The Jakarta changes should really be a major version upgrade so that it's
> > > much more clear to users that it's very different from the previous
> > > version. Another major benefit of going with version 6.0 is that it frees
> > > up the previous javax releases to continue on with 5.19 or 5.20 because we
> > > will likely need to support the older javax releases for quite a while.
> > >
> > > Also, from my point of view it seems pretty clear that the original goal
> > > for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> > > its own branding and versioning for several years now and will likely
> > > continue that way and not change so I don't really see that as a reason to
> > > not bump AMQ 5.x to 6.x with all the major breaking changes.
> > >
> > > Anyways, I figure there won't be much agreement here but thought I should
> > > at least throw it out there before we go and release 5.19.x with such 
> > > major
> > > breaking changes.
> > >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Jean-Baptiste Onofré]

Hi all,

I updated ActiveMQ main branch to 6.0.0-SNAPSHOT version (including
schemas update, etc).

I will now move forward on the related changes.

Thanks all,
Regards
JB

On Fri, Sep 15, 2023 at 3:27 PM Matt Pavlovich  wrote:
>
> Sounds good, makes sense.
>
> Thanks,
> Matt
>
> > On Sep 14, 2023, at 11:29 AM, Jean-Baptiste Onofré  
> > wrote:
> >
> > I agree and that's ActiveMQ 5.x stays with javax.jms and ActiveMQ 6.x
> > changes to jakarta.jms.
> >
> > So we are fully aligned and it shows that ActiveMQ 6.x is cleaner.
> > If users want to still use javax.jms then they will use ActiveMQ 5.x,
> > if they want to use jakarta.jms, they will use ActiveMQ 6.x.
> >
> > It's clear like this imho.
> >
> > Regards
> > JB
> >
> > On Thu, Sep 14, 2023 at 5:57 PM Robbie Gemmell  
> > wrote:
> >>
> >> In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the
> >> broker side and also uses the same classes as the client for various
> >> stuff, so it has to be fully converted so you can use broker + client
> >> in the same application/test without resorting to containers etc. The
> >> 5.x javax broker and jakarta client simply cant be used in the same
> >> classloader.
> >>
> >> 5.x also uses Spring for various bits and a jakarta conversion means
> >> using Spring 6, which requires Java 17 as you noted (related aside: 17
> >> wont be the current LTS as of next week, with Java 21
> >> releasing...which has effectively been finalised for a month now since
> >> there was no RC2).
> >>
> >> So essentially it is not as simple to have 'javax modules' and
> >> 'jakarta modules' in the same tree for 5.x like it was for the Artemis
> >> codebase back in February 2021 when that was originally done. That
> >> made a lot of sense at the time since noone was really using them back
> >> then. Going forward, I do think having 2 versions is actually
> >> preferable, and thats what I choose to do elsewhere, and what I'd say
> >> most (but, not all) projects are doing at this later point. It does
> >> mean backporting things if supporting both, but also means a simpler
> >> build and a nicer testing situation etc, and slightly less user change
> >> (just updating the version, not knowing new -jakarta dep exists and
> >> also updating version).
> >>
> >> On Thu, 14 Sept 2023 at 16:16, Justin Bertram  wrote:
> >>>
> >>> I don't have a deep familiarity with the internals here so some of the
> >>> fundamentals behind the changes aren't clear to me.
> >>>
> >>> Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How
> >>> tightly is "Classic" coupled with Spring?
> >>>
> >>> Is the coupling with Spring also why the code-base is being moved
> >>> whole-sale to Jakarta? It's been a little while now, but when Artemis
> >>> implemented Jakarta support back in early 2021 I don't recall any
> >>> disruption for current users and no major version change was needed. Both
> >>> Java EE and Jakarta EE implementations are based on the same code-base. Is
> >>> something like that not possible here? It would simplify maintenance a lot
> >>> since fixes/features wouldn't have to be back-ported.
> >>>
> >>>
> >>> Justin
> >>>
> >>> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon <
> >>> christopher.l.shan...@gmail.com> wrote:
> >>>
> >>>> First, I realize that this thread is likely to cause a fight based on 
> >>>> past
> >>>> history and probably not go anywhere, but with the work being done
> >>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> >>>> ActiveMQ 6.0 discussion.
> >>>>
> >>>> With all the breaking changes currently targeted for version 5.19.x, such
> >>>> as the Jakarta switch from javax, requiring JDK 17, major Spring and 
> >>>> Jetty
> >>>> upgrades and now potentially major OSGi changes, it makes zero sense to 
> >>>> me
> >>>> to have this next AMQ version as version 5.19.0 as it's completely
> >>>> incompatible with the previous version 5.18.x. Users are likely going to 
> >>>> be
> >>>> in for a rude awakening when trying to upgrade and will be quite confused
> >

Re: [VOTE] Apache ActiveMQ Artemis 2.31.0 (RC2)

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Fri, Sep 15, 2023 at 9:40 PM Clebert Suconic
 wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.31.0 release.
> This is the 2nd Respin of the release (RC2)
>
> This was a large release overall with many improvements, and I'm proud
> of what we accomplished on this release. Thanks for all who
> contributed to this release by both raising JIRAs or contributing
> changes:
>
> * Improvements on the Artemis CLI:
>
>   * Introduced a new feature, Artemis shell, as part of 2.31.0. When
> you run ./artemis shell, a new terminal screen will help you navigate
> through the CLI commands.
>   * The shell terminal will also be presented when you run ./artemis.
>   * You can use bash auto-complete. Run ./artemis auto-complete to
> generate a bash script that provides auto-complete information for
> your bash shell.
>   * Added a CLI cluster verification tool to help you monitor your
> broker topologies. Type ./artemis check cluster to access this
> functionality.
>   *  You can now use ./artemis queue stat to verify the message counts
> on the entire cluster topology when clustering is in use.
>
> AMQP Federation:
>   * Added AMQP Federation support to broker connections.
>
> * MQTT Session State Persistence:
>
> * Paging JDBC Persistence performance was improved significantly
>
> * The documentation was converted to Ascii Doc.
>
> * Many other bug fixes and improvements, as usual.
>
>
> The full JIRA release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12353446
>
> Ths git commit report is here:
> https://activemq.apache.org/components/artemis/download/commit-report-2.31.0
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.31.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1370
>
> In case you want to give it a try with the maven repo on examples:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
> The release was tagged as 2.31.0 on git
>
> I will update the website after the vote has passed.
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my +1 Binding vote

Re: Time to assemble a board report by Tues, Oct 10

[Jean-Baptiste Onofré]

Hi Bruce,

Thanks for the reminder, I will contribute the ActiveMQ part as we
have a lot to share :)

Regards
JB

On Tue, Sep 26, 2023 at 11:35 PM Bruce Snyder  wrote:
>
> Hi folks,
>
> Please contribute to the next ASF board report via the following file:
>
> https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt
>
> The content in this file will need to be replaced with updated data for the
> current report.
>
> This report is due by Wednesday Octx 11, so I will plan to submit this
> report on Tuesday, Oct 10. So, please get your contributions into the file
> above before this time.
>
> Bruce
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E http://bsnyder.org/ 

Re: Time to assemble a board report by Tues, Oct 10

[Jean-Baptiste Onofré]

Hi Robbie,

It's OK for the ActiveMQ part, nothing more to add.

Thanks
Regards
JB

On Wed, Sep 27, 2023 at 12:02 PM Robbie Gemmell
 wrote:
>
> I started preparing an initial draft earlier, and just pushed now
> before seeing your reply. Feel free to update it.
>
> https://github.com/apache/activemq-website/blob/cb0ab34743d0aa073b9a28a3f1c77b571142328b/src/team/reports/DRAFT-ActiveMQ-board-report.txt
>
> On Wed, 27 Sept 2023 at 09:40, Jean-Baptiste Onofré  wrote:
> >
> > Hi Bruce,
> >
> > Thanks for the reminder, I will contribute the ActiveMQ part as we
> > have a lot to share :)
> >
> > Regards
> > JB
> >
> > On Tue, Sep 26, 2023 at 11:35 PM Bruce Snyder  
> > wrote:
> > >
> > > Hi folks,
> > >
> > > Please contribute to the next ASF board report via the following file:
> > >
> > > https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt
> > >
> > > The content in this file will need to be replaced with updated data for 
> > > the
> > > current report.
> > >
> > > This report is due by Wednesday Octx 11, so I will plan to submit this
> > > report on Tuesday, Oct 10. So, please get your contributions into the file
> > > above before this time.
> > >
> > > Bruce
> > >
> > >
> > > --
> > > perl -e 'print
> > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > > http://bsnyder.org/ <http://bruceblog.org/>

[HEADS UP] Preparing ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Hi guys,

We made good progress on ActiveMQ 6.0.0 preparation, including big changes.
I still have a few changes and refactorings to do, I think I need a
couple of weeks max.

I propose to target mid October to submit ActiveMQ 6.0.0 to vote.
In the meantime, I will start to do a pass/changes on the
components/activemq "space" on the website.

Thanks,
Regards
JB

Re: [HEADS UP] Preparing ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Thanks Matt,

I will do review/merge on your PRs.

Regards
JB

On Mon, Oct 2, 2023 at 4:33 PM Matt Pavlovich  wrote:
>
> Hi JB-
>
> Sounds good, my changes are all merged or in pending PR (2 PRs).
>
> Thanks,
> Matt Pavlovich
>
> > On Oct 2, 2023, at 12:44 AM, Jean-Baptiste Onofré  wrote:
> >
> > Hi guys,
> >
> > We made good progress on ActiveMQ 6.0.0 preparation, including big changes.
> > I still have a few changes and refactorings to do, I think I need a
> > couple of weeks max.
> >
> > I propose to target mid October to submit ActiveMQ 6.0.0 to vote.
> > In the meantime, I will start to do a pass/changes on the
> > components/activemq "space" on the website.
> >
> > Thanks,
> > Regards
> > JB
>

Re: [HEADS UP] Preparing ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Hi guys

We still have work do to for ActiveMQ 6.0.0 especially fixes and CVE to
address around HTTP, etc.

I’m working on it, I hope to have all done during the weekend.

In the meantime, I will have PRs for the website, updating the version
policy and reshaping the component/ActiveMQ area.

I will keep you posted asap.

Regards
JB

Le lun. 2 oct. 2023 à 07:44, Jean-Baptiste Onofré  a
écrit :

> Hi guys,
>
> We made good progress on ActiveMQ 6.0.0 preparation, including big changes.
> I still have a few changes and refactorings to do, I think I need a
> couple of weeks max.
>
> I propose to target mid October to submit ActiveMQ 6.0.0 to vote.
> In the meantime, I will start to do a pass/changes on the
> components/activemq "space" on the website.
>
> Thanks,
> Regards
> JB
>

[PROPOSAL] Switch to GitHub issues/actions after ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Hi guys,

Even if we are pretty busy and focused on ActiveMQ 6.0.0 release
preparation (as said in another email, I should be able to submit the
release to vote next week), I think we can anticipate a little the
future of ActiveMQ.
ActiveMQ 6.0.0 is a major milestone for the project, heading to a more
modern approach (I started a PoC to remove Spring dep and using SPI
like approach at broker side, I will keep you posted about that) for
the codebase, website, and our developer experience.

I would like to discuss:
1. Moving from Apache Jenkins to GitHub Actions, using multiple
workflows, more decoupled, with potentially more "executors" to build
and leveraging GitHub Actions "modules".
2. Moving from Apache Jira to GitHub Issues. Several Apache projects
already use GitHub Issues. At OPS4J we also migrated from Jira to GH
Issues. We were able to import everything from Jira without losing
data. I think it would also be a good opportunity to do some cleanup,
maybe starting with only tickets for 6.x.

Thoughts ?

Regards
JB

Re: [PROPOSAL] Switch to GitHub issues/actions after ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Hi Krzysztof

The proposal is for ActiveMQ. But if other parts of ActiveMQ umbrella want
to move to GitHub issues, I can help.

Thanks !
Regards
JB

Le ven. 13 oct. 2023 à 20:31, Havret  a écrit :

> Hi JB,
>
> In my humble opinion, moving to GitHub issues would greatly benefit all
> projects under the ActiveMQ umbrella. Using Jira has been cumbersome.
>
> Best,
> Krzysztof
>
> On Fri, Oct 13, 2023 at 6:05 PM Jean-Baptiste Onofré 
> wrote:
>
> > Hi guys,
> >
> > Even if we are pretty busy and focused on ActiveMQ 6.0.0 release
> > preparation (as said in another email, I should be able to submit the
> > release to vote next week), I think we can anticipate a little the
> > future of ActiveMQ.
> > ActiveMQ 6.0.0 is a major milestone for the project, heading to a more
> > modern approach (I started a PoC to remove Spring dep and using SPI
> > like approach at broker side, I will keep you posted about that) for
> > the codebase, website, and our developer experience.
> >
> > I would like to discuss:
> > 1. Moving from Apache Jenkins to GitHub Actions, using multiple
> > workflows, more decoupled, with potentially more "executors" to build
> > and leveraging GitHub Actions "modules".
> > 2. Moving from Apache Jira to GitHub Issues. Several Apache projects
> > already use GitHub Issues. At OPS4J we also migrated from Jira to GH
> > Issues. We were able to import everything from Jira without losing
> > data. I think it would also be a good opportunity to do some cleanup,
> > maybe starting with only tickets for 6.x.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
>

Re: [PROPOSAL] Switch to GitHub issues/actions after ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Hi Justin,

As we have two components on Jira (one for ActiveMQ, one for Artemis),
I proposed "only" for ActiveMQ.

The general idea is to use a more modern approach for ActiveMQ:
- not need to request a specific Jira account, just use github
- increase our contributors as the "new" comers are more familiar with
GH ecosystem (outside of Apache)
- the risk of migrating is more to lose some metadata (even if it
didn't happen when migrating shiro or ops4j)
- the migration plan is pretty simple, we already have the tooling
almost there with INFRA

Regards
JB

On Mon, Oct 16, 2023 at 6:28 PM Justin Bertram  wrote:
>
> It may be better to break this up into separate [DISCUSS] threads - one for
> Apache Jenkins and GitHub Actions and one for Apache Jira and GitHub Issues.
>
> In any event, it would be good to get clear details on a few different
> points:
>
>  - What specifically are the problems with the existing solution?
>  - How are those problems addressed by the proposed solution? Are there
> additional features in the proposed solution that will enable new
> opportunities that don't currently exist?
>  - What are the risks of migrating?
>  - What is the migration plan?
>
> Once these details are clear we will be able to make an informed decision
> about what action we should take.
>
> Lastly, I think these issues should be considered across ActiveMQ as a
> whole and not just for any individual component. I believe that having
> different ways of doing the same thing for different components on the same
> project is going to be confusing and frustrating for users and developers
> alike.
>
>
> Justin
>
> On Fri, Oct 13, 2023 at 11:13 AM Jean-Baptiste Onofré 
> wrote:
>
> > Hi guys,
> >
> > Even if we are pretty busy and focused on ActiveMQ 6.0.0 release
> > preparation (as said in another email, I should be able to submit the
> > release to vote next week), I think we can anticipate a little the
> > future of ActiveMQ.
> > ActiveMQ 6.0.0 is a major milestone for the project, heading to a more
> > modern approach (I started a PoC to remove Spring dep and using SPI
> > like approach at broker side, I will keep you posted about that) for
> > the codebase, website, and our developer experience.
> >
> > I would like to discuss:
> > 1. Moving from Apache Jenkins to GitHub Actions, using multiple
> > workflows, more decoupled, with potentially more "executors" to build
> > and leveraging GitHub Actions "modules".
> > 2. Moving from Apache Jira to GitHub Issues. Several Apache projects
> > already use GitHub Issues. At OPS4J we also migrated from Jira to GH
> > Issues. We were able to import everything from Jira without losing
> > data. I think it would also be a good opportunity to do some cleanup,
> > maybe starting with only tickets for 6.x.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> >

Re: [PROPOSAL] Switch to GitHub issues/actions after ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

>
> For what it's worth, there are big, popular projects at Apache which
> continue to use Jira.

It depends what projects we are talking, I have a lot of examples of
projects that using GH.
That's true projects are still using Jira, maybe they are
thinking/discussing moving to GH (I know some projects in this case
:)).

>
> > the risk of migrating is more to lose some metadata
>
> Losing metadata is not necessarily trivial so it's worth clarifying what
> metadata is at risk of being lost.
>
> I'm not terribly familiar with GitHub Issues. I've reporting issues using
> it, but I haven't managed a project that used it. Are there features that
> Jira has and GitHub Issues doesn't? For example, can you perform bulk edits
> in GitHub Issues? Can you vote on issues? Is there an API to access issue
> data?

The only feature that I think it's missing if that it's not possible
to have multiple release per issue, but it could mitigate.
It's possible to vote on issues and attach PRs and yes you have API.
You can also have a lot of plugins usable in PRs/Actions (labeler,
dependabot, etc).
I think that, regarding projects using GH (again, large projects like
Beam, Iceberg, etc), we should have everything we need in ActiveMQ (I
don't see anything specific in ActiveMQ compared to other projects).

>
> If later we wanted to migrate from GitHub Issues to another platform would
> we be able to access all our data?

Yes, we can always extract the data, and it can be also dealt by ASF INFRA.

>
> All these questions may have been answered during migrations for other
> projects. Do we have a list of which projects have migrated? If so, I will
> comb through their mailing lists and educate myself. For what it's worth,
> the discussion on the Shiro dev list was pretty short.
>
> > the migration plan is pretty simple, we already have the tooling almost
> there with INFRA
>
> The plan may be simple, but it's still not clear what the plan actually is.
> If the tooling is "almost there" then what's there an what isn't?

By almost there, I mean that it's there and we can just ask to trigger.

>
> Would the plan be to make all the Jira projects read-only and migrate open
> issues? If so, do all the existing comments on the open issues get migrated?

Yes, all will be migrated: issues, releases, comments.

>
>
> To be clear, I'm not saying we *shouldn't* migrate. It's just that the
> details aren't clear so I can't make an informed decision yet.

Sure, thanks for that. And that's why we are discussing that on the
mailing list :)

Regards
JB

>
>
> Justin
>
> [1] https://activemq.apache.org/issues
> [2]
> https://survey.stackoverflow.co/2023/#most-popular-technologies-office-stack-async
>
> On Mon, Oct 16, 2023 at 12:26 PM Jean-Baptiste Onofré 
> wrote:
>
> > Hi Justin,
> >
> > As we have two components on Jira (one for ActiveMQ, one for Artemis),
> > I proposed "only" for ActiveMQ.
> >
> > The general idea is to use a more modern approach for ActiveMQ:
> > - not need to request a specific Jira account, just use github
> > - increase our contributors as the "new" comers are more familiar with
> > GH ecosystem (outside of Apache)
> > - the risk of migrating is more to lose some metadata (even if it
> > didn't happen when migrating shiro or ops4j)
> > - the migration plan is pretty simple, we already have the tooling
> > almost there with INFRA
> >
> > Regards
> > JB
> >
> > On Mon, Oct 16, 2023 at 6:28 PM Justin Bertram 
> > wrote:
> > >
> > > It may be better to break this up into separate [DISCUSS] threads - one
> > for
> > > Apache Jenkins and GitHub Actions and one for Apache Jira and GitHub
> > Issues.
> > >
> > > In any event, it would be good to get clear details on a few different
> > > points:
> > >
> > >  - What specifically are the problems with the existing solution?
> > >  - How are those problems addressed by the proposed solution? Are there
> > > additional features in the proposed solution that will enable new
> > > opportunities that don't currently exist?
> > >  - What are the risks of migrating?
> > >  - What is the migration plan?
> > >
> > > Once these details are clear we will be able to make an informed decision
> > > about what action we should take.
> > >
> > > Lastly, I think these issues should be considered across ActiveMQ as a
> > > whole and not just for any individual component. I believe that having
> > > different w

Re: [PROPOSAL] Switch to GitHub issues/actions after ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Hi

On Wed, Oct 18, 2023 at 6:41 AM Justin Bertram  wrote:
>
> > Correct, it's two "isolated" Jira spaces.
>
> We have four distinct Jira projects:
>  - https://issues.apache.org/jira/projects/AMQ
>  - https://issues.apache.org/jira/projects/ARTEMIS
>  - https://issues.apache.org/jira/projects/AMQNET
>  - https://issues.apache.org/jira/projects/AMQCPP
>
> We also have 21 Git repos [1] with mirrors on GitHub:
>  - activemq
>  - activemq-activeio
>  - activemq-apollo (archived)
>  - activemq-artemis
>  - activemq-artemis-native
>  - activemq-cli-tools
>  - activemq-cpp
>  - activemq-nms-amqp
>  - activemq-nms-api
>  - activemq-nms-ems
>  - activemq-nms-msmq
>  - activemq-nms-openwire
>  - activemq-nms-openwire-generator
>  - activemq-nms-stomp
>  - activemq-nms-xms
>  - activemq-nms-zmq
>  - activemq-openwire
>  - activemq-protobuf
>  - activemq-stomp
>  - activemq-web
>  - activemq-website
>
> As noted previously, those 4 Jira projects would be set to read-only and
> any open/unresolved issues would be migrated to GitHub Issues.

Again, the initial proposal is just for ActiveMQ. The idea is to do
all for ActiveMQ to provide the steps to follow for other components.
If we move all components, we have the choice to enable issues or not
for GitHub space/repository.
The repo would contain .asf.yaml defines the repo settings (enabling
or not issues, discussions, etc):

github:
  description: "Apache ActiveMQ"
  homepage: https://activemq.apache.org/
  labels:
- activemq
- mom
- mqtt
- jms
- amqp
- cloud
  ghp_branch: gh-pages
  features:
wiki: false
issues: true
projects: false
  enabled_merge_buttons:
squash: true
merge: true
rebase: true

This is just an example.

> > I strongly believe that we could increase our contributors (especially
> newcomers) thanks to GH as people are familiar with it.
>
> Did the other projects which migrated to GitHub Issues do so to increase
> their contributions? If so, was it effective?
>
> If we had *no* presence on GitHub I would 100% agree that putting our repos
> there would increase contributions due to widespread familiarity with the
> Git integration it offers. It's just not clear to me that GitHub *Issues*
> itself would provide the same kind of benefit. It's worth noting that
> currently there's nothing stopping anybody from sending a PR to any of our
> repos on GitHub.
>
> Is there something specific about adopting GitHub Issues in particular
> (i.e. not GitHub in general) that you think will increase contributions?

It's hard to have numbers, and I agree with your feedback that we have
already PR.
Let me take the devil advocate: why camel-quarkus is using GH ? why
Apache Iceberg is using GH ?
The reason is because GH issues/PR/workflows integration is fine and a
lot of newcomers are familiar with that.
Onboarding is probably easier.
If you don't think so, that's fair, but I have a different perspective
on that :)

>
> > In the past, we moved from CVS to SVN and from SVN to Git, for the exact
> same reason: features and "modern" approach.
>
> We're talking about issue management and not source control, though, right?
> Has ActiveMQ ever changed issue management? In my opinion, Git is a *huge*
> upgrade over SVN. Migrating from Jira to GitHub Issues seems more like a
> lateral move than an upgrade at this point. I asked previously if there
> were additional features in GitHub Issues that will enable new
> opportunities that don't currently exist in Jira, but I've not seen an
> explanation of any such features.

The opposite is also true: why not move as we have the same features :)
That's true Jira has much more features than GH issues, but we are not using it.
If we would use Kanban, custom fields, etc, I would agree, but it's
not the case currently.

I'm a little puzzled here: I get your points and they are fair,
feedback from others is pretty positive.

So, do you think we should move to a formal move for consensus ?
I can take more times to concretely list the Jira/GH Issues points and
share here.

Regards
JB

>
> On Tue, Oct 17, 2023 at 1:13 AM Jean-Baptiste Onofré 
> wrote:
>
> > Hi Justin
> >
> > On Mon, Oct 16, 2023 at 10:48 PM Justin Bertram 
> > wrote:
> > >
> > > > As we have two components on Jira (one for ActiveMQ, one for
> > Artemis)...
> > >
> > > We have 2 brokers and 2 clients under the ActiveMQ umbrella each of which
> > > have their own Jira project [1].
> >
> > Correct, it's two "isolated" Jira spaces.
> > Some projects have components for subprojects (Karaf for instance,
> > partly Camel), some 

Re: [HEADS UP] Preparing ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Hi guys,

A quick update about ActiveMQ 6.0.0.

I fixed the issues detected, I will open the corresponding PRs soon.

The target date to submit the release to vote is the end of this week.

I will keep you posted.

Regards
JB

On Mon, Oct 2, 2023 at 7:44 AM Jean-Baptiste Onofré  wrote:
>
> Hi guys,
>
> We made good progress on ActiveMQ 6.0.0 preparation, including big changes.
> I still have a few changes and refactorings to do, I think I need a
> couple of weeks max.
>
> I propose to target mid October to submit ActiveMQ 6.0.0 to vote.
> In the meantime, I will start to do a pass/changes on the
> components/activemq "space" on the website.
>
> Thanks,
> Regards
> JB

Re: [PROPOSAL] Switch to GitHub issues/actions after ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Yes, my point was we have the same features as base.

For me, the key differences are:
1. User management, authentication, and span handling
2. Better integration with PR and Actions/Workflows
3. Release/version handling is probably better on Jira, but GH Issues
milestone support is sufficient for us

Just my $0.01

Regards
JB

On Wed, Oct 18, 2023 at 3:27 PM Francois Papon
 wrote:
>
> About the features Github also have projects, roadmap, kanban
>
> I cannot see which features are missing for the common ASF projects.
>
> On 18/10/2023 11:40, Jean-Baptiste Onofré wrote:
> > The opposite is also true: why not move as we have the same features
> > 🙂 That's true Jira has much more features than GH issues, but we are
> > not using it. If we would use Kanban, custom fields, etc, I would
> > agree, but it's not the case currently.

Re: [PROPOSAL] Switch to GitHub issues/actions after ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Fair point.

My proposal (as explained in a previous message) is to move ActiveMQ
first, and then the rest.
Of course if the community agrees (PMC members with the input from
users/contributors).

I'm focusing on ActiveMQ 6.0.0 right now, but it would be good to have
a consensus just after.

Thanks
Regards
JB

On Wed, Oct 18, 2023 at 4:53 PM Christopher Shannon
 wrote:
>
> I've thought about this some more and I think we should probably be
> consistent with all projects.
>
> Justin has made a good point about there being 21 projects/repos. I think
> the switch would be fine to GH issues, but if we did it I think we should
> be consistent and have all projects managed the same way. It would be fine
> to start with one project and move the others but I don't think it's a
> great idea if we only have 1 project isolated with GH issues and the other
> 20 projects in Jira.
>
> So I think we would need the PMC to agree to move all the projects to GH
> for issue tracking and I don't think that support will be there to do that.
>
> On Wed, Oct 18, 2023 at 10:04 AM Jean-Baptiste Onofré 
> wrote:
>
> > Yes, my point was we have the same features as base.
> >
> > For me, the key differences are:
> > 1. User management, authentication, and span handling
> > 2. Better integration with PR and Actions/Workflows
> > 3. Release/version handling is probably better on Jira, but GH Issues
> > milestone support is sufficient for us
> >
> > Just my $0.01
> >
> > Regards
> > JB
> >
> > On Wed, Oct 18, 2023 at 3:27 PM Francois Papon
> >  wrote:
> > >
> > > About the features Github also have projects, roadmap, kanban
> > >
> > > I cannot see which features are missing for the common ASF projects.
> > >
> > > On 18/10/2023 11:40, Jean-Baptiste Onofré wrote:
> > > > The opposite is also true: why not move as we have the same features
> > > > 🙂 That's true Jira has much more features than GH issues, but we are
> > > > not using it. If we would use Kanban, custom fields, etc, I would
> > > > agree, but it's not the case currently.
> >

Re: [HEADS UP] Preparing ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Hi guys,

I'm glad to provide an update about ActiveMQ 6.0.0: after a full week
of fixes, tests, etc, I made good progress. However, I still have a
few Jira to address (and have already started) and corresponding
tests.

The target date (hard) for the release vote is Wednesday (my time).

So, expect the vote on Wednesday :)

Thanks
Regards
JB

On Wed, Oct 18, 2023 at 3:01 PM Jean-Baptiste Onofré  wrote:
>
> Hi guys,
>
> A quick update about ActiveMQ 6.0.0.
>
> I fixed the issues detected, I will open the corresponding PRs soon.
>
> The target date to submit the release to vote is the end of this week.
>
> I will keep you posted.
>
> Regards
> JB
>
> On Mon, Oct 2, 2023 at 7:44 AM Jean-Baptiste Onofré  wrote:
> >
> > Hi guys,
> >
> > We made good progress on ActiveMQ 6.0.0 preparation, including big changes.
> > I still have a few changes and refactorings to do, I think I need a
> > couple of weeks max.
> >
> > I propose to target mid October to submit ActiveMQ 6.0.0 to vote.
> > In the meantime, I will start to do a pass/changes on the
> > components/activemq "space" on the website.
> >
> > Thanks,
> > Regards
> > JB

[VOTE] Apache ActiveMQ 5.18.3 release

[Jean-Baptiste Onofré]

Hi all,

I submit Apache ActiveMQ 5.18.3 release to your vote. This release is
a maintenance release on the 5.18.x series bringing:
- fix on destinations create when message is delayed
- fix on moving message to DLQ when produce via HTTP and TTL is reached
- improvement on KahaDB memory consumption
- improvement on OpenWire marshaller on Throwable class type
- implementation of JMS 2.x XA methods
- fix on JDK17+ support
- a lot of dependency updates
- and much more!

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353355

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1373/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.3/

Git tag: activemq-5.18.3

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours or as soon as we will
have 3 binding votes.

Thanks !
Regards
JB

[VOTE] Apache ActiveMQ 5.17.6 release

[Jean-Baptiste Onofré]

Hi all,

I submit Apache ActiveMQ 5.17.6 release to your vote. This release is
a maintenance release on the 5.17.x series bringing:
- improvement on KahaDB memory consumption
- add additional fields on JMX Connection MBean
- improvement on OpenWire marshaller on Throwable class type
- a lot of dependency updates

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353377

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1374/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.6/

Git tag: activemq-5.17.6

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours or as soon as we will
have 3 binding votes.

Thanks !
Regards
JB

[VOTE] Apache ActiveMQ 5.16.7 release

[Jean-Baptiste Onofré]

Hi guys,

I submit Apache ActiveMQ 5.16.7 release to your vote.
We did a single improvement in this release:
- improvement on OpenWire marshaller on Throwable class type

Here's the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353758

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1375/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.7/

Git tag: activemq-5.16.7

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours or as soon as we will
have 3 binding votes.

Thanks !
Regards
JB

Re: [VOTE] Apache ActiveMQ 5.18.3 release

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Wed, Oct 25, 2023 at 7:37 AM Jean-Baptiste Onofré  wrote:
>
> Hi all,
>
> I submit Apache ActiveMQ 5.18.3 release to your vote. This release is
> a maintenance release on the 5.18.x series bringing:
> - fix on destinations create when message is delayed
> - fix on moving message to DLQ when produce via HTTP and TTL is reached
> - improvement on KahaDB memory consumption
> - improvement on OpenWire marshaller on Throwable class type
> - implementation of JMS 2.x XA methods
> - fix on JDK17+ support
> - a lot of dependency updates
> - and much more!
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353355
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1373/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.3/
>
> Git tag: activemq-5.18.3
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours or as soon as we will
> have 3 binding votes.
>
> Thanks !
> Regards
> JB

Re: [VOTE] Apache ActiveMQ 5.17.6 release

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Wed, Oct 25, 2023 at 10:01 AM Jean-Baptiste Onofré  wrote:
>
> Hi all,
>
> I submit Apache ActiveMQ 5.17.6 release to your vote. This release is
> a maintenance release on the 5.17.x series bringing:
> - improvement on KahaDB memory consumption
> - add additional fields on JMX Connection MBean
> - improvement on OpenWire marshaller on Throwable class type
> - a lot of dependency updates
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353377
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1374/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.6/
>
> Git tag: activemq-5.17.6
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours or as soon as we will
> have 3 binding votes.
>
> Thanks !
> Regards
> JB

Re: [VOTE] Apache ActiveMQ 5.16.7 release

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Wed, Oct 25, 2023 at 4:34 PM Jean-Baptiste Onofré  wrote:
>
> Hi guys,
>
> I submit Apache ActiveMQ 5.16.7 release to your vote.
> We did a single improvement in this release:
> - improvement on OpenWire marshaller on Throwable class type
>
> Here's the Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353758
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1375/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.7/
>
> Git tag: activemq-5.16.7
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours or as soon as we will
> have 3 binding votes.
>
> Thanks !
> Regards
> JB

[RESULT][VOTE] Apache ActiveMQ 5.18.3 release

[Jean-Baptiste Onofré]

Hi,

this vote passed with the following result:

+1 (binding): Chris Shannon, Robbie Gemmell, Tim Bish, Jeff Genender, JB Onofré
+1 (non binding): Jamie Goodyear

I'm promoting the artifacts on Maven Central and dist.apache.org, then
I will update Jira and I will prepare the release announcement (email
and website).

Thanks all for your vote !

Regards
JB

On Wed, Oct 25, 2023 at 7:37 AM Jean-Baptiste Onofré  wrote:
>
> Hi all,
>
> I submit Apache ActiveMQ 5.18.3 release to your vote. This release is
> a maintenance release on the 5.18.x series bringing:
> - fix on destinations create when message is delayed
> - fix on moving message to DLQ when produce via HTTP and TTL is reached
> - improvement on KahaDB memory consumption
> - improvement on OpenWire marshaller on Throwable class type
> - implementation of JMS 2.x XA methods
> - fix on JDK17+ support
> - a lot of dependency updates
> - and much more!
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353355
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1373/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.3/
>
> Git tag: activemq-5.18.3
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours or as soon as we will
> have 3 binding votes.
>
> Thanks !
> Regards
> JB

[RESULT][VOTE] Apache ActiveMQ 5.17.6 release

[Jean-Baptiste Onofré]

Hi guys,

this vote passed with the following result:

+1 (binding): Chris Shannon, Robbie Gemmell, Tim Bish, Jeff Genender,
JB Onofré, Clebert Suconic
+1 (non binding): Jamie Goodyear

I'm promoting the artifacts on Maven Central and dist.apache.org, then
I will update Jira and prepare announcement.

Thanks all for your vote!

Regards
JB

On Wed, Oct 25, 2023 at 10:01 AM Jean-Baptiste Onofré  wrote:
>
> Hi all,
>
> I submit Apache ActiveMQ 5.17.6 release to your vote. This release is
> a maintenance release on the 5.17.x series bringing:
> - improvement on KahaDB memory consumption
> - add additional fields on JMX Connection MBean
> - improvement on OpenWire marshaller on Throwable class type
> - a lot of dependency updates
>
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353377
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1374/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.6/
>
> Git tag: activemq-5.17.6
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours or as soon as we will
> have 3 binding votes.
>
> Thanks !
> Regards
> JB

[RESULT][VOTE] Apache ActiveMQ 5.16.7 release

[Jean-Baptiste Onofré]

Hi all,

this vote passed with the following result:

+1 (binding): JB Onofré, Chris Shannon, Justin Bertram, Clebert
Suconic, Robbie Gemmell, Tim Bish
+1 (non binding): Jamie Goodyear

I'm promoting the artifacts on Maven Central and dist.apache.org, then
I will update Jira and do the announcement.

Thanks all for your vote!

Regards
JB

On Wed, Oct 25, 2023 at 4:34 PM Jean-Baptiste Onofré  wrote:
>
> Hi guys,
>
> I submit Apache ActiveMQ 5.16.7 release to your vote.
> We did a single improvement in this release:
> - improvement on OpenWire marshaller on Throwable class type
>
> Here's the Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353758
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1375/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.7/
>
> Git tag: activemq-5.16.7
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours or as soon as we will
> have 3 binding votes.
>
> Thanks !
> Regards
> JB

[ANN] Apache ActiveMQ 5.18.3 has been released!

[Jean-Baptiste Onofré]

The ActiveMQ team is pleased to announce Apache ActiveMQ 5.18.3 release.

It's a maintenance release on the ActiveMQ 5.18.x series, bringing:
- fix on destinations create when message is delayed
- fix on moving message to DLQ when produce via HTTP and TTL is reached
- improvement on KahaDB memory consumption
- improvement on OpenWire marshaller on Throwable class type
- implementation of JMS 2.x XA methods
- fix on JDK17+ support
- a lot of dependency updates
- and much more!

You can find details on the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353355

You can download ActiveMQ 5.18.3 here:
https://activemq.apache.org/components/classic/download/

Enjoy!

Regards
--
The Apache ActiveMQ team

[ANN] Apache ActiveMQ 5.17.6 has been released!

[Jean-Baptiste Onofré]

The ActiveMQ team is pleased to announce Apache ActiveMQ 5.17.6 release.

It's a maintenance release on the ActiveMQ 5.17.x series, bringing:
- improvement on KahaDB memory consumption
- add additional fields on JMX Connection MBean
- improvement on OpenWire marshaller on Throwable class type
- a lot of dependency updates

You can find details on the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353377

You can download ActiveMQ 5.17.6 here:
https://activemq.apache.org/components/classic/download/

Enjoy!

Regards
--
The Apache ActiveMQ team

[ANN] Apache ActiveMQ 5.16.7 has been released!

[Jean-Baptiste Onofré]

The ActiveMQ team is pleased to announce Apache ActiveMQ 5.16.7 release.

It's a maintenance release on the ActiveMQ 5.16.x series, bringing:
- improvement on OpenWire marshaller on Throwable class type

You can find details on the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353758

You can download ActiveMQ 5.16.7 here:
https://activemq.apache.org/download-archives

Enjoy!

Regards
--
The Apache ActiveMQ team

Re: [DISCUSS] moving the artemis examples to their own git repository

[Jean-Baptiste Onofré]

Yeah, I think it's a good idea to separate the example:
- they can leave with their own lifecycle
- they don't "impact" build on the main

+1 for me

Regards
JB

On Thu, Oct 26, 2023 at 12:12 PM Robbie Gemmell
 wrote:
>
> I'd like to move the artemis examples out of the main build+repo and
> into a specific repo of their own.
>
> There are a significant number of them, most of which rarely change,
> and I think it would be nicer to have them sitting standalone. Having
> them in-build somewhat complicates things as they are, and also quite
> significantly slows down the release process currently. The repo/build
> also tends to be marked for security issues that are only related to
> the examples components (obviously we'd still want to update things in
> the separate repo, but theyd at least be separate). The nightly
> snapshot deploy job takes an age, mostly due to the examples. There is
> really no reason we should be deploying them, so I'd also stop doing
> that in a shift; I wouldnt actually envisage us releasing the examples
> at all. We would set up the CI to continue building them similarly to
> as we do now, theyd just sit separately.
>
> Several other projects also use separate repos for their examples,
> especially those with many of them. Specific cases I can think of
> coming across most regularly are probably the multiple variants of
> Camel, and Quarkus. On searching here at the ASF there do appear to be
> various other projects that do this too:
> https://github.com/orgs/apache/repositories?language=&q=examples&sort=&type=all
>
> Thoughts?
>
> Robbie

[VOTE] Apache ActiveMQ 5.15.16 release

[Jean-Baptiste Onofré]

Hi all,

I submit ActiveMQ 5.15.16 to your vote. We did one improvement on this release:
- improvement on OpenWire marshaller on Throwable class type

Here's the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353758

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1378/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.16/

Git tag: activemq-5.15.16

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours or as soon as we will
have 3 binding votes.

Thanks !
Regards
JB

Re: [HEADS UP] Preparing ActiveMQ 6.0.0

[Jean-Baptiste Onofré]

Hi guys,

As you probably saw, we did a bunch of ActiveMQ and Artemis releases
during the past two days.

Unfortunately, due to that, I didn't have a lot of time to complete
ActiveMQ 6.0.0 release preparation. I will back on this tonight and I
will work on this during the whole weekend. I plan to submit 6.0.0 to
vote on Monday.

Regards
JB

On Sun, Oct 22, 2023 at 6:21 PM Jean-Baptiste Onofré  wrote:
>
> Hi guys,
>
> I'm glad to provide an update about ActiveMQ 6.0.0: after a full week
> of fixes, tests, etc, I made good progress. However, I still have a
> few Jira to address (and have already started) and corresponding
> tests.
>
> The target date (hard) for the release vote is Wednesday (my time).
>
> So, expect the vote on Wednesday :)
>
> Thanks
> Regards
> JB
>
> On Wed, Oct 18, 2023 at 3:01 PM Jean-Baptiste Onofré  
> wrote:
> >
> > Hi guys,
> >
> > A quick update about ActiveMQ 6.0.0.
> >
> > I fixed the issues detected, I will open the corresponding PRs soon.
> >
> > The target date to submit the release to vote is the end of this week.
> >
> > I will keep you posted.
> >
> > Regards
> > JB
> >
> > On Mon, Oct 2, 2023 at 7:44 AM Jean-Baptiste Onofré  
> > wrote:
> > >
> > > Hi guys,
> > >
> > > We made good progress on ActiveMQ 6.0.0 preparation, including big 
> > > changes.
> > > I still have a few changes and refactorings to do, I think I need a
> > > couple of weeks max.
> > >
> > > I propose to target mid October to submit ActiveMQ 6.0.0 to vote.
> > > In the meantime, I will start to do a pass/changes on the
> > > components/activemq "space" on the website.
> > >
> > > Thanks,
> > > Regards
> > > JB

Re: [VOTE] Apache ActiveMQ 5.15.16 release

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On Thu, Oct 26, 2023 at 1:00 PM Jean-Baptiste Onofré  wrote:
>
> Hi all,
>
> I submit ActiveMQ 5.15.16 to your vote. We did one improvement on this 
> release:
> - improvement on OpenWire marshaller on Throwable class type
>
> Here's the Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353758
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1378/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.16/
>
> Git tag: activemq-5.15.16
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours or as soon as we will
> have 3 binding votes.
>
> Thanks !
> Regards
> JB

[RESULT][VOTE] Apache ActiveMQ 5.15.16 release

[Jean-Baptiste Onofré]

Hi all,

this vote passed with the following result:

+1 (binding): Chris Shannon, JB Onofré, Clebert Suconic
+1 (non binding): Matt Pavlovich

I'm promoting the artifacts on Maven Central and dist.apache.org, then
I will update Jira and the website in preparation for the
announcement.

Thanks all for your vote!

Regards
JB

On Thu, Oct 26, 2023 at 1:00 PM Jean-Baptiste Onofré  wrote:
>
> Hi all,
>
> I submit ActiveMQ 5.15.16 to your vote. We did one improvement on this 
> release:
> - improvement on OpenWire marshaller on Throwable class type
>
> Here's the Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353758
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1378/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.16/
>
> Git tag: activemq-5.15.16
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours or as soon as we will
> have 3 binding votes.
>
> Thanks !
> Regards
> JB

Re: HEADS-UP: ActiveMQ 6.0.0 - apache-activemq 6.0.0 artifact exists in Maven Central

[Jean-Baptiste Onofré]

Thanks Art :)

Le jeu. 26 oct. 2023 à 19:25, Arthur Naseef  a écrit :

> BTW, I just found this while doing something unrelated to our 6.0.0
> release.
>
> Maven central already has an apache-activemq artifact released with version
> 6.0.0:
>
> https://mvnrepository.com/artifact/org.apache.activemq/apache-activemq
>
>
> Perhaps we can get that one removed?
>
> It looks like there are no files, just the metadata?
>
> Art
>