Re: [RESULT][VOTE] Apache ActiveMQ Artemis Console 1.0.0

[Robbie Gemmell]

On Tue, 8 Oct 2024 at 11:12, Andy Taylor  wrote:
>
> The vote passed with 4 Binding +1 votes and 1 non-binding +1 vote.
>
>
> The following votes were received:
>
> Binding:
> Clebert Suconic
> Domenico Francesco Bruscino
> Timothy Bish
> Robbie Gemmell
>
> Non-binding:
> Andy Taylor
>
> Thanks everybody for taking the time on this release, for all the
> contributions and the time spent evaluating the Candidate Release.
>
>
> I will release the staging repo, if a PMC member can release the dist
> artifacts. Once everything is synced I will update the website and send the
> announcement.
>
> Andy

I reviewed your website update PR
https://github.com/apache/activemq-website/pull/144 for adding the
component/release. I have now pushed the changes along with various
fixups and small improvements in a followup.

There are other improvements I would like to make, to generate release
content updates more in line with the broker releases, but those are
bigger and can come later as the content present now will be unchanged
from the user perspective. So it makes sense to publish it now,
allowing proceeding to announcing the release and enabling people to
use it.

Robbie

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Let's compile the October board report by Oct 8

[Robbie Gemmell]

Kanchana is assigned as the Shephard for the ActiveMQ report this go round.

On Tue, 8 Oct 2024 at 16:46, Bruce Snyder  wrote:
>
> Yeah, I'm not sure who kanchana is but I just published it again.
>
> Thank you to everyone who contributed to this board report!
>
> Bruce
>
> On Tue, Oct 8, 2024 at 5:29 AM Robbie Gemmell 
> wrote:
>
> > Though I now see the first draft was already submitted early on Sunday
> > Oct 6th by kanchana. Maybe they thought the left-as-draft was an
> > oversight? Unclear.
> >
> > I believe you can just submit it again anyway, and it doesnt seem like
> > anyone has reviewed it yet so that should be fine.
> >
> > On Tue, 8 Oct 2024 at 12:22, Robbie Gemmell 
> > wrote:
> > >
> > > I updated the report draft to cover the release of ActiveMQ Artemis
> > > Console 1.0.0 today.
> > >
> > > On Mon, 7 Oct 2024 at 17:07, Justin Bertram  wrote:
> > > >
> > > > I provided a couple updates for Artemis and reformatted a few things to
> > > > maintain consistency with previous reports [1].
> > > >
> > > >
> > > > Justin
> > > >
> > > > [1] https://whimsy.apache.org/board/minutes/ActiveMQ.html
> > > >
> > > > On Mon, Oct 7, 2024 at 10:39 AM Bruce Snyder 
> > wrote:
> > > >
> > > > > Last call to contribute to the board report as I will be submitting
> > it
> > > > > tomorrow. The report is still looking pretty bare with contributions
> > only
> > > > > for JB at this point.
> > > > >
> > > > > Please make five minutes to contribute before tomorrow to flesh out
> > the
> > > > > report further.
> > > > >
> > > > > Thank you!
> > > > >
> > > > > Bruce
> > > > >
> > > > > On Sat, Oct 5, 2024 at 8:28 AM Jean-Baptiste Onofré  > >
> > > > > wrote:
> > > > >
> > > > > > Hi Bruce,
> > > > > >
> > > > > > I added the "Classic" section earlier this week.
> > > > > >
> > > > > > Regards
> > > > > > JB
> > > > > >
> > > > > > On Fri, Oct 4, 2024 at 8:41 PM Bruce Snyder <
> > bruce.sny...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > This is a reminder to help compile the latest report to the ASF
> > board.
> > > > > > > There are only four days until Oct 8 when I will be submitting
> > the
> > > > > > report,
> > > > > > > so please take five minutes today to contribute!
> > > > > > >
> > > > > > > On Mon, Sep 30, 2024 at 9:58 AM Bruce Snyder <
> > bruce.sny...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Thank you, JB!
> > > > > > > >
> > > > > > > > Bruce
> > > > > > > >
> > > > > > > > On Sun, Sep 29, 2024 at 9:37 AM Jean-Baptiste Onofré <
> > > > > j...@nanthrax.net>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> Hi Bruce
> > > > > > > >>
> > > > > > > >> I will complete the ActiveMQ Classic part asap.
> > > > > > > >>
> > > > > > > >> Thanks !
> > > > > > > >> Regards
> > > > > > > >> JB
> > > > > > > >>
> > > > > > > >> On Sat, Sep 28, 2024 at 3:31 PM Bruce Snyder <
> > > > > bruce.sny...@gmail.com>
> > > > > > > >> wrote:
> > > > > > > >> >
> > > > > > > >> > It's time to assemble the latest report to the board. Let's
> > aim to
> > > > > > > >> submit
> > > > > > > >> > this report by Oct 8.
> > > > > > > >> >
> > > > > > > >> > To contribute to the board report, please following the
> > steps
> > > > > below:
> > > > > > > >> >
> > > > > > > >> > 1) Log in to the Reporter tool via the following URL:
> > > > > > > >&

Re: Let's compile the October board report by Oct 8

[Robbie Gemmell]

Though I now see the first draft was already submitted early on Sunday
Oct 6th by kanchana. Maybe they thought the left-as-draft was an
oversight? Unclear.

I believe you can just submit it again anyway, and it doesnt seem like
anyone has reviewed it yet so that should be fine.

On Tue, 8 Oct 2024 at 12:22, Robbie Gemmell  wrote:
>
> I updated the report draft to cover the release of ActiveMQ Artemis
> Console 1.0.0 today.
>
> On Mon, 7 Oct 2024 at 17:07, Justin Bertram  wrote:
> >
> > I provided a couple updates for Artemis and reformatted a few things to
> > maintain consistency with previous reports [1].
> >
> >
> > Justin
> >
> > [1] https://whimsy.apache.org/board/minutes/ActiveMQ.html
> >
> > On Mon, Oct 7, 2024 at 10:39 AM Bruce Snyder  wrote:
> >
> > > Last call to contribute to the board report as I will be submitting it
> > > tomorrow. The report is still looking pretty bare with contributions only
> > > for JB at this point.
> > >
> > > Please make five minutes to contribute before tomorrow to flesh out the
> > > report further.
> > >
> > > Thank you!
> > >
> > > Bruce
> > >
> > > On Sat, Oct 5, 2024 at 8:28 AM Jean-Baptiste Onofré 
> > > wrote:
> > >
> > > > Hi Bruce,
> > > >
> > > > I added the "Classic" section earlier this week.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On Fri, Oct 4, 2024 at 8:41 PM Bruce Snyder 
> > > > wrote:
> > > > >
> > > > > This is a reminder to help compile the latest report to the ASF board.
> > > > > There are only four days until Oct 8 when I will be submitting the
> > > > report,
> > > > > so please take five minutes today to contribute!
> > > > >
> > > > > On Mon, Sep 30, 2024 at 9:58 AM Bruce Snyder 
> > > > wrote:
> > > > >
> > > > > > Thank you, JB!
> > > > > >
> > > > > > Bruce
> > > > > >
> > > > > > On Sun, Sep 29, 2024 at 9:37 AM Jean-Baptiste Onofré <
> > > j...@nanthrax.net>
> > > > > > wrote:
> > > > > >
> > > > > >> Hi Bruce
> > > > > >>
> > > > > >> I will complete the ActiveMQ Classic part asap.
> > > > > >>
> > > > > >> Thanks !
> > > > > >> Regards
> > > > > >> JB
> > > > > >>
> > > > > >> On Sat, Sep 28, 2024 at 3:31 PM Bruce Snyder <
> > > bruce.sny...@gmail.com>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > It's time to assemble the latest report to the board. Let's aim 
> > > > > >> > to
> > > > > >> submit
> > > > > >> > this report by Oct 8.
> > > > > >> >
> > > > > >> > To contribute to the board report, please following the steps
> > > below:
> > > > > >> >
> > > > > >> > 1) Log in to the Reporter tool via the following URL:
> > > > > >> > https://reporter.apache.org/wizard/?activemq
> > > > > >> > 2) Begin entering your contributions
> > > > > >> > 3) Be sure to save your contributions as a DRAFT
> > > > > >> >
> > > > > >> > Please DO NOT PUBLISH the report yet.
> > > > > >> >
> > > > > >> > PLEASE NOTE: While logged in to the Reporter tool, please DO NOT
> > > > click
> > > > > >> the
> > > > > >> > 'Publish to Whimsy' button. I will plan to review and submit the
> > > > report
> > > > > >> on
> > > > > >> > Oct 8.
> > > > > >> >
> > > > > >> > Please let me know if you have any questions.
> > > > > >> >
> > > > > >> > Bruce
> > > > > >> >
> > > > > >> > --
> > > > > >> > perl -e 'print
> > > > > >> >
> > > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > > > > >>
> > > > > >>
> > > -
> > > > > >> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> > > > > >> For additional commands, e-mail: dev-h...@activemq.apache.org
> > > > > >> For further information, visit: https://activemq.apache.org/contact
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > --
> > > > > > perl -e 'print
> > > > > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > > > );'
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > perl -e 'print
> > > > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > > );'
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> > > > For additional commands, e-mail: dev-h...@activemq.apache.org
> > > > For further information, visit: https://activemq.apache.org/contact
> > > >
> > > >
> > > >
> > >
> > > --
> > > perl -e 'print
> > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > >

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Let's compile the October board report by Oct 8

[Robbie Gemmell]

I updated the report draft to cover the release of ActiveMQ Artemis
Console 1.0.0 today.

On Mon, 7 Oct 2024 at 17:07, Justin Bertram  wrote:
>
> I provided a couple updates for Artemis and reformatted a few things to
> maintain consistency with previous reports [1].
>
>
> Justin
>
> [1] https://whimsy.apache.org/board/minutes/ActiveMQ.html
>
> On Mon, Oct 7, 2024 at 10:39 AM Bruce Snyder  wrote:
>
> > Last call to contribute to the board report as I will be submitting it
> > tomorrow. The report is still looking pretty bare with contributions only
> > for JB at this point.
> >
> > Please make five minutes to contribute before tomorrow to flesh out the
> > report further.
> >
> > Thank you!
> >
> > Bruce
> >
> > On Sat, Oct 5, 2024 at 8:28 AM Jean-Baptiste Onofré 
> > wrote:
> >
> > > Hi Bruce,
> > >
> > > I added the "Classic" section earlier this week.
> > >
> > > Regards
> > > JB
> > >
> > > On Fri, Oct 4, 2024 at 8:41 PM Bruce Snyder 
> > > wrote:
> > > >
> > > > This is a reminder to help compile the latest report to the ASF board.
> > > > There are only four days until Oct 8 when I will be submitting the
> > > report,
> > > > so please take five minutes today to contribute!
> > > >
> > > > On Mon, Sep 30, 2024 at 9:58 AM Bruce Snyder 
> > > wrote:
> > > >
> > > > > Thank you, JB!
> > > > >
> > > > > Bruce
> > > > >
> > > > > On Sun, Sep 29, 2024 at 9:37 AM Jean-Baptiste Onofré <
> > j...@nanthrax.net>
> > > > > wrote:
> > > > >
> > > > >> Hi Bruce
> > > > >>
> > > > >> I will complete the ActiveMQ Classic part asap.
> > > > >>
> > > > >> Thanks !
> > > > >> Regards
> > > > >> JB
> > > > >>
> > > > >> On Sat, Sep 28, 2024 at 3:31 PM Bruce Snyder <
> > bruce.sny...@gmail.com>
> > > > >> wrote:
> > > > >> >
> > > > >> > It's time to assemble the latest report to the board. Let's aim to
> > > > >> submit
> > > > >> > this report by Oct 8.
> > > > >> >
> > > > >> > To contribute to the board report, please following the steps
> > below:
> > > > >> >
> > > > >> > 1) Log in to the Reporter tool via the following URL:
> > > > >> > https://reporter.apache.org/wizard/?activemq
> > > > >> > 2) Begin entering your contributions
> > > > >> > 3) Be sure to save your contributions as a DRAFT
> > > > >> >
> > > > >> > Please DO NOT PUBLISH the report yet.
> > > > >> >
> > > > >> > PLEASE NOTE: While logged in to the Reporter tool, please DO NOT
> > > click
> > > > >> the
> > > > >> > 'Publish to Whimsy' button. I will plan to review and submit the
> > > report
> > > > >> on
> > > > >> > Oct 8.
> > > > >> >
> > > > >> > Please let me know if you have any questions.
> > > > >> >
> > > > >> > Bruce
> > > > >> >
> > > > >> > --
> > > > >> > perl -e 'print
> > > > >> >
> > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > > > >>
> > > > >>
> > -
> > > > >> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> > > > >> For additional commands, e-mail: dev-h...@activemq.apache.org
> > > > >> For further information, visit: https://activemq.apache.org/contact
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > > --
> > > > > perl -e 'print
> > > > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > > );'
> > > > >
> > > >
> > > >
> > > > --
> > > > perl -e 'print
> > > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > );'
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> > > For additional commands, e-mail: dev-h...@activemq.apache.org
> > > For further information, visit: https://activemq.apache.org/contact
> > >
> > >
> > >
> >
> > --
> > perl -e 'print
> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E >

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [RESULT][VOTE] Apache ActiveMQ Artemis Console 1.0.0

[Robbie Gemmell]

On Tue, 8 Oct 2024 at 11:12, Andy Taylor  wrote:
>
> The vote passed with 4 Binding +1 votes and 1 non-binding +1 vote.
>
>
> The following votes were received:
>
> Binding:
> Clebert Suconic
> Domenico Francesco Bruscino
> Timothy Bish
> Robbie Gemmell
>
> Non-binding:
> Andy Taylor
>
> Thanks everybody for taking the time on this release, for all the
> contributions and the time spent evaluating the Candidate Release.
>
>
> I will release the staging repo, if a PMC member can release the dist
> artifacts. Once everything is synced I will update the website and send the
> announcement.
>
> Andy

I created a matching subdir in the dist release area at
release/activemq/activemq-artemis-console and copied in the 1.0.0
dir/files from the dev area.

It should sync to downloads.a.o and then in turn the CDN (dlcdn.a.o) soon.

Robbie

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [VOTE] Apache ActiveMQ Artemis Console 1.0.0

[Robbie Gemmell]

+1

I checked things out as follows:
- Verified the signature + checksum files.
- Checked for LICENCE + NOTICE files in the archives.
- Used "mvn apache-rat:check" to check headers in the source archive.
- Ran the build from the source archive on JDK17.
- Used the jetty plugin to serve the console standalone, connecting it
  remotely to a pure 2.37.0 broker instance.
- I tried the modified-2.37.0 integration from the draft PR
  https://github.com/apache/activemq-artemis/pull/5245
- I used the modified-2.37.0 to upgrade the pure-2.37.0 broker instance.
- I diffed the archives with the previous RC2 attempt to check only the
  expected things changed in the source archive.

Robbie

On Wed, 2 Oct 2024 at 10:26, Andy Taylor  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis Console 1.0.0 release.
> This is RC3.
>
> This is the 1st release of the ActiveMQ Console so only has 1 jira
>
> [ARTEMIS-4680] - Upgrade the console to use HawtIO 4
>
> The release notes can be found here:
> https://issues.apache.org/jira/projects/ARTEMIS/versions/12354639
>
> Source and Binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-console/1.0.0/
>
> The Maven staging repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1409
>
> If you would like to validate the release you can either:
>
> 1. Check out the source, build and follow the readme instructions
> (README.md) to deploy and smoke test the console
>
> or
>
> 2. Download the binary distribution and deploy in a web container
>
> or
>
> 3. Use a branch I have created based on Artemis 2.37.0 to build Artemis
> with the console embedded, see
> https://github.com/apache/activemq-artemis/pull/5245
>
>
> It is tagged in the git repo as 1.0.0
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my +1

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [VOTE] Apache ActiveMQ Artemis Console 1.0.0

[Robbie Gemmell]

Note: people should run e.g. "git fetch --tags --force" on their
console checkout if they have worked with the console repo previously,
to ensure you dont have stale tags, since 1.0.0 has been re-tagged.

On Wed, 2 Oct 2024 at 10:26, Andy Taylor  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis Console 1.0.0 release.
> This is RC3.
>
> This is the 1st release of the ActiveMQ Console so only has 1 jira
>
> [ARTEMIS-4680] - Upgrade the console to use HawtIO 4
>
> The release notes can be found here:
> https://issues.apache.org/jira/projects/ARTEMIS/versions/12354639
>
> Source and Binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-console/1.0.0/
>
> The Maven staging repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1409
>
> If you would like to validate the release you can either:
>
> 1. Check out the source, build and follow the readme instructions
> (README.md) to deploy and smoke test the console
>
> or
>
> 2. Download the binary distribution and deploy in a web container
>
> or
>
> 3. Use a branch I have created based on Artemis 2.37.0 to build Artemis
> with the console embedded, see
> https://github.com/apache/activemq-artemis/pull/5245
>
>
> It is tagged in the git repo as 1.0.0
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my +1

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [VOTE] Apache ActiveMQ Artemis Console 1.0.0

[Robbie Gemmell]

I raised https://github.com/apache/activemq-artemis-console/pull/34 to
address the missing license file in the source release archive, and
improve the rat plugin config to allow simple manual verifications.

On Mon, 30 Sept 2024 at 17:41, Robbie Gemmell  wrote:
>
> -1
>
> Overall it looks good, however the source archive LICENCE file
> references a sub file that isnt actually included in the archive
> (artemis-console-extension/artemis-extension/.yarn/releases/LICENSE-yarn.txt).
> It is in the repo, it is just a trivial issue with the assembly
> creation process including 1 file out of this build-updated-dir
> instead of the two that it should have; trivial fix is to also include
> the other file.
>
> I checked things over as follows:
> - I verified the signature and checksum files.
>
> - I checked for licence+notice files in the archives. I noticed the
> above lissue first. Another niggle in the space of licences, but just
> an annoyance not a blocker, is that the RAT plugin config could be
> improved so that it applied to manual CLI invocations as well as the
> standard build. RAT is always being run as part of the build, which is
> perhaps unnecessary but not a big overhead in this case, however the
> config for that is specific to that execution and so if instead
> manually running "mvn apache-rat:check" on the CLI to verify things
> specifically, it then fails because a couple of .md files (e.g
> README.md for one) dont get excluded like they are during the
> execution within the regular build cycle. They should just share the
> same config.
>
> - I gave the source build a run, and started up the console standalone
> using the jetty maven plugin per the readme, connecting it to a
> running 2.37.0 artemis instance.
>
> - I also tried the modified-2.37.0 integration from the draft PR
> https://github.com/apache/activemq-artemis/pull/5245. I noticed some
> issues with that, all on the main artemis repo side, which I pushed
> some commits to resolve some of and commented on the rest. With the
> fixes I made in place, I also tried running the upgrade command from
> the branch to update an existing 2.37.0 instance to the modified
> variant with new console.
>
> Robbie
>
> On Mon, 23 Sept 2024 at 14:47, Andy Taylor  wrote:
> >
> > I would like to propose an Apache ActiveMQ Artemis Console 1.0.0 release.
> >
> > This is the 1st release of the ActiveMQ Console so only has 1 jira
> >
> > [ARTEMIS-4680] - Upgrade the console to use HawtIO 4
> >
> > The release notes can be found here:
> > https://issues.apache.org/jira/projects/ARTEMIS/versions/12354639
> >
> > Source and Binary distributions can be found here:
> > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-console/1.0.0/
> >
> > The Maven staging repository is here:
> > https://repository.apache.org/content/repositories/orgapacheactivemq-1405
> >
> > If you would like to validate the release you can either:
> >
> > 1. Check out the source, build and follow the readme instructions
> > (README.md) to deploy and smoke test the console
> >
> > or
> >
> > 2. Download the binary distribution and deploy in a we container
> >
> > or
> >
> > 3. Use a branch I have created based on Artemis 2.37.0 to build Artemis
> > with the console embedded, see
> > https://github.com/apache/activemq-artemis/pull/5245
> >
> >
> > It is tagged in the git repo as 1.0.0
> >
> > [ ] +1 approve this release
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my +1

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [VOTE] Apache ActiveMQ Artemis Console 1.0.0

[Robbie Gemmell]

-1

Overall it looks good, however the source archive LICENCE file
references a sub file that isnt actually included in the archive
(artemis-console-extension/artemis-extension/.yarn/releases/LICENSE-yarn.txt).
It is in the repo, it is just a trivial issue with the assembly
creation process including 1 file out of this build-updated-dir
instead of the two that it should have; trivial fix is to also include
the other file.

I checked things over as follows:
- I verified the signature and checksum files.

- I checked for licence+notice files in the archives. I noticed the
above lissue first. Another niggle in the space of licences, but just
an annoyance not a blocker, is that the RAT plugin config could be
improved so that it applied to manual CLI invocations as well as the
standard build. RAT is always being run as part of the build, which is
perhaps unnecessary but not a big overhead in this case, however the
config for that is specific to that execution and so if instead
manually running "mvn apache-rat:check" on the CLI to verify things
specifically, it then fails because a couple of .md files (e.g
README.md for one) dont get excluded like they are during the
execution within the regular build cycle. They should just share the
same config.

- I gave the source build a run, and started up the console standalone
using the jetty maven plugin per the readme, connecting it to a
running 2.37.0 artemis instance.

- I also tried the modified-2.37.0 integration from the draft PR
https://github.com/apache/activemq-artemis/pull/5245. I noticed some
issues with that, all on the main artemis repo side, which I pushed
some commits to resolve some of and commented on the rest. With the
fixes I made in place, I also tried running the upgrade command from
the branch to update an existing 2.37.0 instance to the modified
variant with new console.

Robbie

On Mon, 23 Sept 2024 at 14:47, Andy Taylor  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis Console 1.0.0 release.
>
> This is the 1st release of the ActiveMQ Console so only has 1 jira
>
> [ARTEMIS-4680] - Upgrade the console to use HawtIO 4
>
> The release notes can be found here:
> https://issues.apache.org/jira/projects/ARTEMIS/versions/12354639
>
> Source and Binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-console/1.0.0/
>
> The Maven staging repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1405
>
> If you would like to validate the release you can either:
>
> 1. Check out the source, build and follow the readme instructions
> (README.md) to deploy and smoke test the console
>
> or
>
> 2. Download the binary distribution and deploy in a we container
>
> or
>
> 3. Use a branch I have created based on Artemis 2.37.0 to build Artemis
> with the console embedded, see
> https://github.com/apache/activemq-artemis/pull/5245
>
>
> It is tagged in the git repo as 1.0.0
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my +1

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Issue with transitive dependency on commons-collections

[Robbie Gemmell]

Oops, I got distracted while typing originally, and didnt spot Justin
already said the same thing by the time I actually hit send. Oh well
:)

On Wed, 21 Aug 2024 at 17:07, Robbie Gemmell  wrote:
>
> Most of the uses in the codebase are transitive, from others commons
> dependencies, so you would need to check that we don't use the bits of
> those dependencies that require it and then specifically exclude it,
> otherwise you won't actually be able to get rid of it.
>
> On Wed, 21 Aug 2024 at 16:18, Justin Bertram  wrote:
> >
> > The ActiveMQ Artemis code-base doesn't use
> > org.apache.commons.collections.list.SetUniqueList so this problem doesn't
> > apply.
> >
> > That said, moving to commons-collections4 is a good idea. I've opened
> > ARTEMIS-5006 [1] for this.
> >
> >
> > Justin
> >
> > [1] https://issues.apache.org/jira/browse/ARTEMIS-5006
> >
> > On Wed, Aug 21, 2024 at 9:17 AM  wrote:
> >
> > > Hello,
> > >
> > >
> > >
> > > the security scanner in my company raised an issue with
> > > commons-collections,
> > > which is a transative dependency from Artemis:
> > >
> > >
> > >
> > > Part of our „mvn dependeny:tree“
> > >
> > > +- org.apache.activemq:artemis-junit-5:jar:2.36.0:test
> > >
> > > +- org.apache.activemq:artemis-server:jar:2.31.2:test
> > >
> > >\- commons-collections:commons-collections:jar:3.2.2:compile
> > >
> > >
> > >
> > > AFAIK the 3.x of commons-collections is EOL in favor to collections4 – 
> > > also
> > > with new GAV coordinates
> > >
> > > org.apache.commons
> > >
> > > commons-collections4
> > >
> > >
> > >
> > >
> > >
> > > Some details about that security issue:
> > >
> > >
> > >
> > > Score
> > >
> > > vulnerability sonatype-2024-3350 with severity >= 7 (severity = 8.7)
> > >
> > >
> > >
> > > Explanation
> > >
> > > The Apache commons-collections packages are vulnerable to a Denial of
> > > Service (DoS) attack. The add() method of the SetUniqueList class
> > > mishandles
> > > the order of operations when invoking its parent List implementation.
> > > Consequently, adding an instance of itself results in infinite recursion
> > > and
> > > deviates from the behavior defined by the standard JRE List contract. A
> > > remote attacker who can cause an application to add SetUniqueList 
> > > instances
> > > to themselves can exploit this vulnerability to crash the affected
> > > application with a StackOverflowError exception.
> > >
> > >
> > >
> > > Version Affected
> > >
> > > [3.2,3.2.2]
> > >
> > >
> > >
> > > Root Cause
> > >
> > >
> > >
> > >
> > >
> > > commons-collections-3.2.2.redhat-2.jarorg/apache/commons/collections/list/Se
> > > tUniqueList.class[3.0, )
> > >
> > >
> > >
> > > Advisories
> > >
> > >
> > >
> > > Project
> > >
> > > https://issues.apache.org/jira/browse/COLLECTIONS-701
> > >
> > >
> > >
> > > CVSS Details
> > >
> > >
> > >
> > > Sonatype CVSS 4
> > >
> > > 8.7
> > >
> > > CVSS Vector
> > >
> > > CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
> > >
> > >
> > >
> > >
> > >
> > > That issue is fixed for 4.3.
> > >
> > >
> > >
> > >
> > >
> > > Do you plan to update to collections4?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > cheers
> > >
> > > Jan Matèrne
> > >
> > >

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Issue with transitive dependency on commons-collections

[Robbie Gemmell]

Most of the uses in the codebase are transitive, from others commons
dependencies, so you would need to check that we don't use the bits of
those dependencies that require it and then specifically exclude it,
otherwise you won't actually be able to get rid of it.

On Wed, 21 Aug 2024 at 16:18, Justin Bertram  wrote:
>
> The ActiveMQ Artemis code-base doesn't use
> org.apache.commons.collections.list.SetUniqueList so this problem doesn't
> apply.
>
> That said, moving to commons-collections4 is a good idea. I've opened
> ARTEMIS-5006 [1] for this.
>
>
> Justin
>
> [1] https://issues.apache.org/jira/browse/ARTEMIS-5006
>
> On Wed, Aug 21, 2024 at 9:17 AM  wrote:
>
> > Hello,
> >
> >
> >
> > the security scanner in my company raised an issue with
> > commons-collections,
> > which is a transative dependency from Artemis:
> >
> >
> >
> > Part of our „mvn dependeny:tree“
> >
> > +- org.apache.activemq:artemis-junit-5:jar:2.36.0:test
> >
> > +- org.apache.activemq:artemis-server:jar:2.31.2:test
> >
> >\- commons-collections:commons-collections:jar:3.2.2:compile
> >
> >
> >
> > AFAIK the 3.x of commons-collections is EOL in favor to collections4 – also
> > with new GAV coordinates
> >
> > org.apache.commons
> >
> > commons-collections4
> >
> >
> >
> >
> >
> > Some details about that security issue:
> >
> >
> >
> > Score
> >
> > vulnerability sonatype-2024-3350 with severity >= 7 (severity = 8.7)
> >
> >
> >
> > Explanation
> >
> > The Apache commons-collections packages are vulnerable to a Denial of
> > Service (DoS) attack. The add() method of the SetUniqueList class
> > mishandles
> > the order of operations when invoking its parent List implementation.
> > Consequently, adding an instance of itself results in infinite recursion
> > and
> > deviates from the behavior defined by the standard JRE List contract. A
> > remote attacker who can cause an application to add SetUniqueList instances
> > to themselves can exploit this vulnerability to crash the affected
> > application with a StackOverflowError exception.
> >
> >
> >
> > Version Affected
> >
> > [3.2,3.2.2]
> >
> >
> >
> > Root Cause
> >
> >
> >
> >
> >
> > commons-collections-3.2.2.redhat-2.jarorg/apache/commons/collections/list/Se
> > tUniqueList.class[3.0, )
> >
> >
> >
> > Advisories
> >
> >
> >
> > Project
> >
> > https://issues.apache.org/jira/browse/COLLECTIONS-701
> >
> >
> >
> > CVSS Details
> >
> >
> >
> > Sonatype CVSS 4
> >
> > 8.7
> >
> > CVSS Vector
> >
> > CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
> >
> >
> >
> >
> >
> > That issue is fixed for 4.3.
> >
> >
> >
> >
> >
> > Do you plan to update to collections4?
> >
> >
> >
> >
> >
> >
> >
> > cheers
> >
> > Jan Matèrne
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [VOTE] Apache ActiveMQ Artemis Console 1.0.0

[Robbie Gemmell]

On Thu, 15 Aug 2024 at 12:50, Andy Taylor  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis Console 1.0.0 release.
>
> This is the 1st release of the ActiveMQ Console so only has 1 jira
>
> [ARTEMIS-4680] - Upgrade the console to use HawtIO 4
>
> The release notes can be found here:
> https://issues.apache.org/jira/projects/ARTEMIS/versions/12354639
>
> Source and Web distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-console/1.0.0/
>
> The Maven staging repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1402
>
> If you would like to validate the release you can either:
>
> 1. Check out the source, build and follow the readme instructions
> (README.md) to deploy and smoke test the console
>
> or
>
> 2. Use a branch I have created based on Artemis 2.36.0 to build Artemis
> with the console embedded, see
> https://github.com/apache/activemq-artemis/pull/5149
>
>
> It is tagged in the git repo as 
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my +1
>
> Andy

-1

I gave the '2.36.0 test integration' PR a look over and commented on
some issues in recent days, though seemingly mostly to do with the PR
itself rather than the console bit under vote here, except for a
warning from hawtio 4.0.0. I also tried the source build and local
'mvn jetty:run' based development usage (where the warning wasn't
present), successfully doing a specified manual connect to a
standalone/external artemis broker (2.37.0 RC2 in this case). I
verified the checksums and signatures.

I was actually surprised to find the .war file in the dist repo
directly. Are you intending this console convenience binary war to go
on the website as a standalone download linking to the war on the dist
CDN? As opposed to e.g the download for artemis-native [1], which is
source-only since it is incorporated as a binary in the main artemis
distribution convenience binary that folks are noted about on the main
download page[2]? It would need a full binary assembly with NOTICE and
LICENCE files covering the contents especially around the hawtio +
react bits etc, as is done in the main artemis convenience binary
distribution for the existing console bits.

[1] https://activemq.apache.org/components/artemis/download/native_download
[2] https://activemq.apache.org/components/artemis/download/

Robbie

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [VOTE] ActiveMQ Artemis 2.37.0 (CR2)

[Robbie Gemmell]

On Fri, 16 Aug 2024 at 16:11, Clebert Suconic  wrote:
>
>  I would like to propose an Apache ActiveMQ Artemis 2.37.0 release.
>
> I would like to highlight:
>
> - We fixed an issue with compatibility between 2.31.1 and 2.32.0:
> https://issues.apache.org/jira/browse/ARTEMIS-4986
>
> - We introduced profiles differentiating the broker execution from
> tools on the CLI.
>
>
> For a full release notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12354977
>
>
> The git report:
> https://activemq.apache.org/components/artemis/download/commit-report-2.37.0
>
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.37.0
>
>
> The Maven staging repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1403
>
>
>
> If you would like to validate the release:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases
>
> The release is tagged as 2.37.0 in the git repository
>
> Notice the release was retagged since CR1 failed. Please make sure you
> do git fetch --tags --force
>
> 2.37.0 is tagged as this commit:
>
> commit 0ec68a93d3421b824f1086cbb45e343ec6acf59b (tag: 2.37.0)
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> For additional commands, e-mail: dev-h...@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>

+1

I checked things over as follows:
- Verified the signature + checksum files.
- Checked for LICENCE + NOTICE files in the archives.
- Checked licence headers in the source archive by running:
  "mvn apache-rat:check"
- Ran the Qpid JMS main HelloWorld against a broker from the binary
archive on JDK 17.
- Ran the source build and the AMQP integration tests on JDK 17 with:
  "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
-Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
test"
- Verified the build reproducibility using the tooling at Reproducible
Central, raised draft PR:
  https://github.com/jvm-repo-rebuild/reproducible-central/pull/194

Robbie

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: HEADS-UP ActiveMQ Artemis release

[Robbie Gemmell]

I hadn't checked my emails and only just saw this.

I merged https://github.com/apache/activemq-artemis/pull/5136 earlier
for https://issues.apache.org/jira/browse/ARTEMIS-4785 and
https://issues.apache.org/jira/browse/ARTEMIS-4702. Those changes are
not really appropriate for a 2.36.1. I'd also say the subtask
https://issues.apache.org/jira/browse/ARTEMIS-4702 that you merged
previously for that same overall task isnt either. Looking at the
wider set, there are certainly those that aren't strictly bug fixes.

So I'd go with 2.37.0 as previously expected personally, or else
branch to take those all out.

Robbie

On Tue, 13 Aug 2024 at 21:59, Clebert Suconic  wrote:
>
> I would like to do a release tomorrow, so I would address this issue,
> which is a compatibility issue introduced after 2.30.0..Users may do a
> rolling upgrade between 2.30.0 and latest versions, and this would not
> work properly unless the following is addressed:
>
> https://issues.apache.org/jira/browse/ARTEMIS-4986?
>
>
>
> Looking at the current payload we would name it as 2.36.1 (as it seems
> only bug fixes currently)... let me know if you object and if I should
> rather name it 2.37.0
>
>
>
> Cheers.
>
>
>
> --
> Clebert Suconic
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> For additional commands, e-mail: dev-h...@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [DISCUSS] HornetQ Acceptor on default acceptor for ActiveMQ Artemis

[Robbie Gemmell]

I think removing it is a good idea and dont expect removing it now
would actually be a big issue, however given it has been there for so
long I also dont see that it urgently needs to go away now. Anyone
that doesnt want it there already has simple ways to prevent it being
there, so I'd probably just remove it in a 3.0 personally (neednt be
all that far away either, i.e relatively speaking there's not much
time diff overall). Perhaps just raise a Jira to track the task? At
least anyone following those would see the intent.

On Wed, 7 Aug 2024 at 04:43, Clebert Suconic  wrote:
>
> I just realized we still create the following acceptor on every server we 
> start:
>
>
>  
>
>   name="hornetq">tcp://0.0.0.0:5445?anycastPrefix=jms.queue.;multicastPrefix=jms.topic.;protocols=HORNETQ,STOMP;useEpoll=true
>
>
>
> And I think we should stop. 61616 would still respond to HornetQ
> protocol. It just don't make sense (for a few. years already .. don't
> know how we missed) to keep this acceptor.
>
>
> I think we should switch the defaults on the CLI create to have it off
> by default, and add a new parameter as --enable-hornetq-acceptor.
>
> --
> Clebert Suconic
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> For additional commands, e-mail: dev-h...@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [VOTE] Apache ActiveMQ Classic 6.1.3 release

[Robbie Gemmell]

That feels more like something that could change in a future release if
needed, rather than a blocker demanding a respin of this one.

Plenty of boms don't do that, even for widely used foundational things like
Netty:
https://repo1.maven.org/maven2/io/netty/netty-bom/4.1.112.Final/netty-bom-4.1.112.Final.pom


On Sat, 3 Aug 2024, 18:20 Matt Pavlovich,  wrote:

> Hi JB-
>
> Unfortunately, I believe I need to -1 on this.
>
> I believe the current best practice for bom is to have a fixed version,
> instead of ${project.version}.
>
> See Camel:
>
> https://repo1.maven.org/maven2/org/apache/camel/camel-bom/4.7.0/camel-bom-4.7.0.pom
>
> See Spring:
>
> https://repo1.maven.org/maven2/org/springframework/spring-framework-bom/6.1.11/spring-framework-bom-6.1.11.pom
>
> -Matt Pavlovich
>
> > On Aug 2, 2024, at 1:50 AM, Jean-Baptiste Onofré 
> wrote:
> >
> > Hi everyone,
> >
> > I submit Apache ActiveMQ Classic 6.1.3 release to your vote.
> >
> > This release includes 16 fixes and updates, especially:
> > - add a BoM
> > - fixes on the Message REST API, especially concurrent access
> > - Spring 6.1.11 update
> > - fix NoClassDefFound on bin/activemq export command line
> > - several dependency updates
> >
> > You can take a look on Release Notes for details:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12354559
> >
> > Maven Staging Repository:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1400/
> >
> > Dist Staging Repository:
> > https://dist.apache.org/repos/dist/dev/activemq/activemq/6.1.3/
> >
> > Git tag: activemq-6.1.3
> >
> > Please vote to approve this release:
> > [ ] +1 Approve the release
> > [ ] 0 I don't care
> > [ ] -1 Don't approve the release (please provide specific comment)
> >
> > This vote will be open for at least 72 hours.
> >
> > Thanks!
> > Regards
> > JB
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> > For additional commands, e-mail: dev-h...@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> >
> >
>
>

Re: [VOTE] Apache ActiveMQ Artemis 2.36.0 release

[Robbie Gemmell]

On Fri, 26 Jul 2024 at 01:01, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.36.0 release.
>
>
> I would like to highlight the following:
>
> * Numerous dependency upgrades triggered by integration with GitHub's
> Dependabot.
> * Stability improvement for use-cases involving slower IO devices
> (e.g. NFS) and the NIO journal via
> https://issues.apache.org/jira/browse/ARTEMIS-4949
> * Code optimization in the address manager to decrease CPU utilization
> and increase broker scalability for use-cases involving a large number
> of addresses and queues courtesy of
> https://issues.apache.org/jira/browse/ARTEMIS-4814
> * Stability improvement for use-cases involving STOMP clients
> connecting over WebSockets via
> https://issues.apache.org/jira/browse/ARTEMIS-3509.
> * Lots of internal "code gardening" improvements for developers to
> make the code-base simpler and more consistent.
>
>
>
> The release notes can be found here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=&projectId=12315920
>
>
> Ths git commit report is here:
> https://activemq.apache.org/components/artemis/download/commit-report-2.36.0
>
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.36.0
>
>
> The Maven staging repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1399
>
>
> If you would like to validate the release:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases
>
>
> It is tagged in the git repo as  2.36.0
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>

+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked for LICENCE and NOTICE files in the archives.
- Checked licence headers in the source archive by running:
  "mvn apache-rat:check"
- Ran the Qpid JMS main HelloWorld against a broker from the binary
archive on JDK 17.
- Ran the source build and the AMQP integration tests on JDK 17 with:
  "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
-Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
test"
- Ran the examples repo CI jobs with modification to use the staged
2.36.0 maven bits.

Robbie

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: activemq.apache.org website down?

[Robbie Gemmell]

Site is back up now.

On Wed, 10 Jul 2024 at 10:23, Robbie Gemmell  wrote:
>
> There is an issue with various projects websites just now, it is being
> investigated.
>
> On Wed, 10 Jul 2024 at 09:55, Lionel Cons  wrote:
> >
> > I've tried from several hosts and I get a 404 each time...
> >
> > $ wget https://activemq.apache.org/
> > --2024-07-10 10:52:31--  https://activemq.apache.org/
> > Resolving activemq.apache.org (activemq.apache.org)... 2a04:4e42::644, 
> > 151.101.2.132
> > Connecting to activemq.apache.org 
> > (activemq.apache.org)|2a04:4e42::644|:443... connected.
> > HTTP request sent, awaiting response... 404 Not Found
> > 2024-07-10 10:52:31 ERROR 404: Not Found.
> >
> > Cheers,
> >
> > Lionel
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> > For additional commands, e-mail: dev-h...@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: activemq.apache.org website down?

[Robbie Gemmell]

There is an issue with various projects websites just now, it is being
investigated.

On Wed, 10 Jul 2024 at 09:55, Lionel Cons  wrote:
>
> I've tried from several hosts and I get a 404 each time...
>
> $ wget https://activemq.apache.org/
> --2024-07-10 10:52:31--  https://activemq.apache.org/
> Resolving activemq.apache.org (activemq.apache.org)... 2a04:4e42::644, 
> 151.101.2.132
> Connecting to activemq.apache.org 
> (activemq.apache.org)|2a04:4e42::644|:443... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2024-07-10 10:52:31 ERROR 404: Not Found.
>
> Cheers,
>
> Lionel
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> For additional commands, e-mail: dev-h...@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [HEADS-UP] Maven version enforcements on 3.9.3+ for ActiveMQ Artemis

[Robbie Gemmell]

I reworked the artemis-commons module pom so that the pom output by
the shade plugin is the same regardless which of the maven versions or
profile combinations was in use, versus 3.8.x having 3 different
possible outputs previously (tested 4 variants before/after with both
3.8.7 and 3.9.4 specifically). So we shouldnt need to consider
enforcing a higher version [for this reason] now.

https://issues.apache.org/jira/browse/ARTEMIS-4822

On Tue, 18 Jun 2024 at 17:10, Robbie Gemmell  wrote:
>
> I was looking into why the artemis-commons pom seemed to not be
> reproducible in the recent releases, since I previously did some work
> to get it reproducible some months ago for a completely different
> issue.
>
> I was eventually able to piece together that use of Maven 3.9.2+ (I
> was on 3.9.4 at the start, whilst reproducible-central was using
> 3.9.3), coupled with whether the release profile is active or not,
> explained the slight difference from what is on central for 2.34.0 and
> which was published with 3.8.x
>
> I suggested that Clebert upgrade locally to 3.9.3+ (from looking at
> the release notes) to do future releases. He suggested just enforcing
> that as minimum maven version in the release profile, which I said we
> could (we already enforce a lower minimum version I believe), but
> should give a heads up first since it might trip up other folks still
> on older versions as he originally was.
>
> On Tue, 18 Jun 2024 at 16:59, Clebert Suconic  
> wrote:
> >
> > So... I was thinking about eventually enforcing 3.9.3+ as we talked
> > about... but that might break people's CI...
> >
> > For now we recommend using 3.9.3 on releasing, but we may add an enforcer 
> > rule.
> >
> > On Tue, Jun 18, 2024 at 11:58 AM Clebert Suconic
> >  wrote:
> > >
> > > If you are release ActiveMQ Artemis, please use Maven 3.9.3+ as it
> > > improves reproducibility of the release. There are some minor issues
> > > with the way artemis commons is built (shading) and having 3.9.3+
> > > during the release would improve its reproducibility. (I don't take it
> > > as a major issue but it's better to upgrade... ).
> > >
> > >
> > > I was talking "in person" with Robbie Gemmel about this and he might
> > > have more context about it.
> > > --
> > > Clebert Suconic
> >
> >
> >
> > --
> > Clebert Suconic
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> > For additional commands, e-mail: dev-h...@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [HEADS-UP] Maven version enforcements on 3.9.3+ for ActiveMQ Artemis

[Robbie Gemmell]

I was looking into why the artemis-commons pom seemed to not be
reproducible in the recent releases, since I previously did some work
to get it reproducible some months ago for a completely different
issue.

I was eventually able to piece together that use of Maven 3.9.2+ (I
was on 3.9.4 at the start, whilst reproducible-central was using
3.9.3), coupled with whether the release profile is active or not,
explained the slight difference from what is on central for 2.34.0 and
which was published with 3.8.x

I suggested that Clebert upgrade locally to 3.9.3+ (from looking at
the release notes) to do future releases. He suggested just enforcing
that as minimum maven version in the release profile, which I said we
could (we already enforce a lower minimum version I believe), but
should give a heads up first since it might trip up other folks still
on older versions as he originally was.

On Tue, 18 Jun 2024 at 16:59, Clebert Suconic  wrote:
>
> So... I was thinking about eventually enforcing 3.9.3+ as we talked
> about... but that might break people's CI...
>
> For now we recommend using 3.9.3 on releasing, but we may add an enforcer 
> rule.
>
> On Tue, Jun 18, 2024 at 11:58 AM Clebert Suconic
>  wrote:
> >
> > If you are release ActiveMQ Artemis, please use Maven 3.9.3+ as it
> > improves reproducibility of the release. There are some minor issues
> > with the way artemis commons is built (shading) and having 3.9.3+
> > during the release would improve its reproducibility. (I don't take it
> > as a major issue but it's better to upgrade... ).
> >
> >
> > I was talking "in person" with Robbie Gemmel about this and he might
> > have more context about it.
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> For additional commands, e-mail: dev-h...@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
For additional commands, e-mail: dev-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [VOTE] Archive unused or out-of-date repos

[Robbie Gemmell]

On Tue, 23 Apr 2024 at 18:58, Justin Bertram  wrote:
>
> Following up from the previous discussion thread on this subject, I'd like
> to propose a vote for archiving the following repos:
>
>  - activemq-stomp - https://github.com/apache/activemq-stomp
>  - activemq-activeio - https://github.com/apache/activemq-activeio
>  - activemq-web - https://github.com/apache/activemq-web
>  - activemq-nms-ems - https://github.com/apache/activemq-nms-ems
>  - activemq-nms-xms - https://github.com/apache/activemq-nms-xms
>  - activemq-nms-zmq - https://github.com/apache/activemq-nms-zmq
>  - activemq-nms-msmq - https://github.com/apache/activemq-nms-msmq
>
> Here's my +1.
>
>
> Justin

+1

Re: [DISCUSS] Delete unused or out-of-date repos

[Robbie Gemmell]

For activemq-web, I wouldnt see much issue in deleting that, since it
was purely for the website (which has changed and moved on over
several years since) and it doesnt seem like the repo was really used
for much at all before attention switched to the activemq-website repo
instead, which is where the updated website was actually first served
from. It only has 1 commit in it, and 4 open unmerged PRs.

For the rest of the repos, I'd say we dont tend to delete repos with
old code/specs in it, even if its not seemingly that useful anymore or
the stuff moved to another repo. I would just archive any of them that
we decided are not going to be used again.

On Fri, 19 Apr 2024 at 06:01, Justin Bertram  wrote:
>
> I agree 100% with the following:
>
>   Good to archive/read-only:
>- activemq-activeio
>- activemq-nms-ems
>- activemq-nms-xms
>- activemq-nms-zmq
>- activemq-nms-msmq
>
>   Should stay open for now:
>- activemq-protobuf
>
> I still think these are worth deleting:
>  - activemq-stomp
>  - activemq-web
>
> The activemq-stomp repo pretty clearly became
> https://github.com/stomp/stomp-spec. See this commit [1] for details. I
> don't see any value in keeping this repo, even in read-only form.
>
> The activemq-web repo was an intermediate dump that eventually became
> https://github.com/apache/activemq-website/. Again, I don't see any value
> in keeping this repo.
>
> I'm iffy on activemq-nms-stomp and could go either way (i.e. archiving or
> keeping open). I certainly agree that STOMP is a useful protocol, but
> anybody is still free to use it even if this repo is archived. It has good
> support across platforms and languages. It's not clear to me why anybody
> would use the NMS STOMP implementation when AMQP and OpenWire
> implementations exist. Furthermore, if someone really wanted to use STOMP
> why not simply use one of the existing .NET STOMP clients? Nobody has filed
> a bug or asked for a release in ages as far as I know.
>
>
> Justin
>
> [1]
> https://github.com/stomp/stomp-spec/commit/5e8edb9cd52927bbdd3acee5cf9940c571ef00b7
>
> On Thu, Apr 18, 2024 at 8:45 PM Matt Pavlovich  wrote:
>
> > Hi Justin-
> >
> > What about moving several to archived/read-only vs delete? Or at least
> > archive/read-only for a period of time before deleting them altogether?
> >
> > Good to archive/read-only:
> > - [x] activemq-stomp (looks like stomp website)
> > - [x] activemq-web (looks like deprecated repo activemq-website is current)
> > - [x] activemq-activeio I removed this as an active dependency last year
> > ahead of 6.0.0 release.
> > - [x] activemq-nms.. ems, xms, zmq and msmq imho, these are good to
> > archive— mostly unmaintained and deprecated/older protocols and brokers.
> >
> > Might be good to keep open:
> > - [x] activemq-nms-stomp - STOMP is still a useful protocol, but the code
> > module is mostly unmaintained
> >
> > Should stay open for now:
> > - [x] activemq-protobuf — This is still referenced by ActiveMQ Classic. I
> > plan to re-home this back to the main tree for JDK modernization and
> > protobuf upgrade, etc. but we there may be some unforeseen reason to
> > release an update out of this repo.
> >
> > Thanks!
> > Matt Pavlovich
> >
> > > On Apr 18, 2024, at 2:40 PM, Justin Bertram  wrote:
> > >
> > > During the process of researching the proposed move to GitHub Issues I
> > > reviewed all ActiveMQ Git repos [1]. I noticed a handful that haven't
> > been
> > > updated in a long time and appear to be defunct:
> > >
> > > - activemq-stomp - https://github.com/apache/activemq-stomp
> > > - activemq-activeio - https://github.com/apache/activemq-activeio
> > > - activemq-protobuf - https://github.com/apache/activemq-protobuf
> > > - activemq-web - https://github.com/apache/activemq-web
> > > - activemq-nms-ems - https://github.com/apache/activemq-nms-ems
> > > - activemq-nms-xms - https://github.com/apache/activemq-nms-xms
> > > - activemq-nms-zmq - https://github.com/apache/activemq-nms-zmq
> > > - activemq-nms-msmq - https://github.com/apache/activemq-nms-msmq
> > > - activemq-nms-stomp* - *https://github.com/apache/activemq-nms-stomp
> > >
> > > Most of these repos haven't seen a meaningful update in almost a decade.
> > > Does anybody have concerns with deleting any of these?
> > >
> > > My goal here is to simplify our code footprint and clarify what
> > code-bases
> > > are functional and actively maintained.
> > >
> > >
> > > Justin
> > >
> > > [1]
> > >
> > https://github.com/orgs/apache/repositories?language=&q=activemq&sort=&type=all
> >
> >

Re: [PROPOSAL] Enable GH issues

[Robbie Gemmell]

We should start a new thread about Discussions so it can be clearly
and specifically discussed..i.e not on this thread or the other
previous thread both originally about Issues.

On Thu, 18 Apr 2024 at 16:32, Christopher Shannon
 wrote:
>
> I think overall it would be a positive thing, it gives a place for people
> to ask questions without having to raise a Jira.
>
> I guess the one downside is it would be something else to monitor...there's
> already Jira, Slack, and the mailing lists.
>
> I think one thing that would be helpful for monitoring is for the
> discussions to be mirrored to email so people can monitor it in one spot,
> and even respond to by email if they want. I assume that the discussions
> can be emailed just like the notifications for PRs so that people don't
> need to check.  I'm not sure if it would be better for the discussion
> threads to be  mixed in with the existing notifications for PRs or another
> mailing list. We can always set up filters so sharing the existing
> notification list is probably ok.
>
> On Thu, Apr 18, 2024 at 10:50 AM Justin Bertram  wrote:
>
> > Enabling GitHub Discussions is not something we've really discussed
> > thoroughly. I mentioned it in my review only briefly as a "future
> > consideration." I don't think we've got consensus yet.
> >
> >
> > Justin
> >
> > On Thu, Apr 18, 2024 at 8:47 AM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > > Is there anything stopping us from enabling Github Discussions for now?
> > It
> > > seems like we had consensus on that part.
> > >
> > > On Tue, Apr 16, 2024 at 2:15 PM Matt Pavlovich 
> > wrote:
> > >
> > > > Robbie/JB-
> > > >
> > > > Good calls outs, thanks! I did not mean to skew into contribution guide
> > > as
> > > > far as I did. I will take a pass at cleaning up.
> > > >
> > > > Thanks,
> > > > Matt
> > > >
> > > > > On Apr 16, 2024, at 11:56 AM, Robbie Gemmell <
> > robbie.gemm...@gmail.com
> > > >
> > > > wrote:
> > > > >
> > > > > The security bits are also detailed in all the repositories already
> > by
> > > > > default at the org level, e.g
> > > > > https://github.com/apache/activemq-artemis/?tab=security-ov-file (or
> > > > > repositories can define their own policy, e.g
> > > > > https://github.com/apache/activemq/?tab=security-ov-file#readme ).
> > > > > Though we can of course make references to it clearer.
> > > > >
> > > > > On Tue, 16 Apr 2024 at 17:48, Jean-Baptiste Onofré 
> > > > wrote:
> > > > >>
> > > > >> Hi Matt
> > > > >>
> > > > >> Imho, we are mixing two topics here:
> > > > >> 1. The ticket management system
> > > > >> 2. The contribution guide
> > > > >>
> > > > >> So, let me try to clarify:
> > > > >>
> > > > >> [PROPOSAL]
> > > > >>
> > > > >> I'm in favor of GH Issues, but we don't yet have a strong consensus
> > > > >> about that. I would propose a new thread about that to give a chance
> > > > >> to anyone to speak, and move to a vote.
> > > > >>
> > > > >> [README/CONTRIBUTION GUIDE]
> > > > >>
> > > > >> First, ICLA is not strictly required before committership (the
> > Apache
> > > > >> 2.0 license already covered contributor, it has been discussed on
> > > > >> LEGAL Jira).
> > > > >> Second, you don't report security issues on a mailing list, you go
> > to
> > > > >> secur...@apache.org.
> > > > >> Explaining how to report issue, create PR, contribute (e.g.
> > > > >> contribution guide) is fine and welcome.
> > > > >>
> > > > >> Regards
> > > > >> JB
> > > > >>
> > > > >> On Tue, Apr 16, 2024 at 5:37 PM Matt Pavlovich 
> > > > wrote:
> > > > >>>
> > > > >>> @dev-
> > > > >>>
> > > > >>> I appreciate all the good feedback and discussion. A number of good
> > > > points, suggestions and perspectives. Overall, I see an uptick in
> > > community
> > > > interest in co

Re: [PROPOSAL] Enable GH issues

[Robbie Gemmell]

This isnt about discussions in PRs, it is about enabling the
Discussions tab in a github repository. Basically a threaded forum
style view where people can...discuss :)

On Thu, 18 Apr 2024 at 15:27, Bruce Snyder  wrote:
>
> Good question, Chris. I don't believe so and I agree allowing discussions
> in PRs is critical.
>
> Bruce
>
> On Thu, Apr 18, 2024 at 7:40 AM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > Is there anything stopping us from enabling Github Discussions for now? It
> > seems like we had consensus on that part.
> >
> > On Tue, Apr 16, 2024 at 2:15 PM Matt Pavlovich  wrote:
> >
> > > Robbie/JB-
> > >
> > > Good calls outs, thanks! I did not mean to skew into contribution guide
> > as
> > > far as I did. I will take a pass at cleaning up.
> > >
> > > Thanks,
> > > Matt
> > >
> > > > On Apr 16, 2024, at 11:56 AM, Robbie Gemmell  > >
> > > wrote:
> > > >
> > > > The security bits are also detailed in all the repositories already by
> > > > default at the org level, e.g
> > > > https://github.com/apache/activemq-artemis/?tab=security-ov-file (or
> > > > repositories can define their own policy, e.g
> > > > https://github.com/apache/activemq/?tab=security-ov-file#readme ).
> > > > Though we can of course make references to it clearer.
> > > >
> > > > On Tue, 16 Apr 2024 at 17:48, Jean-Baptiste Onofré 
> > > wrote:
> > > >>
> > > >> Hi Matt
> > > >>
> > > >> Imho, we are mixing two topics here:
> > > >> 1. The ticket management system
> > > >> 2. The contribution guide
> > > >>
> > > >> So, let me try to clarify:
> > > >>
> > > >> [PROPOSAL]
> > > >>
> > > >> I'm in favor of GH Issues, but we don't yet have a strong consensus
> > > >> about that. I would propose a new thread about that to give a chance
> > > >> to anyone to speak, and move to a vote.
> > > >>
> > > >> [README/CONTRIBUTION GUIDE]
> > > >>
> > > >> First, ICLA is not strictly required before committership (the Apache
> > > >> 2.0 license already covered contributor, it has been discussed on
> > > >> LEGAL Jira).
> > > >> Second, you don't report security issues on a mailing list, you go to
> > > >> secur...@apache.org.
> > > >> Explaining how to report issue, create PR, contribute (e.g.
> > > >> contribution guide) is fine and welcome.
> > > >>
> > > >> Regards
> > > >> JB
> > > >>
> > > >> On Tue, Apr 16, 2024 at 5:37 PM Matt Pavlovich 
> > > wrote:
> > > >>>
> > > >>> @dev-
> > > >>>
> > > >>> I appreciate all the good feedback and discussion. A number of good
> > > points, suggestions and perspectives. Overall, I see an uptick in
> > community
> > > interest in contributing to ActiveMQ and that’s a great thing! I believe
> > > that modernizing the toolkit, reducing contribution friction and lowering
> > > load on committers/PMC will help keep the community healthy going forward
> > > =).
> > > >>>
> > > >>> I've made a pass at summarizing the points and take-aways from the
> > > [DISCUSS] thread below. Please reply with suggested add/edit/removes.
> > > >>>
> > > >>> [Key community Use Cases]
> > > >>>
> > > >>> UC-1. Issue - User opens an Issue and may or may not intend (or be
> > > able) to produce a PR to address the report.
> > > >>>
> > > >>> UC-2. PR-onl - User opens a PR without an Issue to address their
> > > requested fix.
> > > >>>
> > > >>> UC-3. Security report - User identifies a security issue and needs to
> > > report
> > > >>>
> > > >>>
> > > >>> [Proposal]
> > > >>>
> > > >>> Action-1. Enable GH issues and flip JIRA to read-only
> > > >>>
> > > >>> Action-2. Update README in repo to be more of a 'how to engage with
> > > the community' vs a project overview
> > > >>>
> > > >>>
> > > >>> [Update README document to include]
> > > >>>
> > > >>> Update-1. Provide a link for users to create an issue
> > > >>>
> > > >>> Update-2. Provide a link to the mailing list for reporting a security
> > > issue
> > > >>>
> > > >>> Update-3. Provide a link for users to submit a CLA
> > > >>>
> > > >>>
> > > >>> [Committer/PMC operating]
> > > >>>
> > > >>> Op-A. For use case #2 where user creates a PR without an issue,
> > before
> > > approval committer/pmc may instruct contributor to provide signed CLA and
> > > open a corresponding issue if the complexity warrants. The PR comment can
> > > then be updated with the issue id for reference and linking.
> > > >>>
> > > >>> Op-B. Use of GHT Project(s) for planning and tracking Issue & PR for
> > > releases.
> > > >>>
> > > >>> Thanks,
> > > >>> Matt Pavlovich
> > >
> > >
> >
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E http://bsnyder.org/ <http://bruceblog.org/>

Re: [PROPOSAL] Enable GH issues

[Robbie Gemmell]

We need a clear agreement specifically about enabling Discussions and
on which repositories, since Infra will have to enable it for us on
them, Discussions is not self-service.

Might be simplest to just start a thread, and then when its clear,
either start a vote or do a lazy consensus statement that the request
will be placed on .

On Thu, 18 Apr 2024 at 14:41, Christopher Shannon
 wrote:
>
> Is there anything stopping us from enabling Github Discussions for now? It
> seems like we had consensus on that part.
>
> On Tue, Apr 16, 2024 at 2:15 PM Matt Pavlovich  wrote:
>
> > Robbie/JB-
> >
> > Good calls outs, thanks! I did not mean to skew into contribution guide as
> > far as I did. I will take a pass at cleaning up.
> >
> > Thanks,
> > Matt
> >
> > > On Apr 16, 2024, at 11:56 AM, Robbie Gemmell 
> > wrote:
> > >
> > > The security bits are also detailed in all the repositories already by
> > > default at the org level, e.g
> > > https://github.com/apache/activemq-artemis/?tab=security-ov-file (or
> > > repositories can define their own policy, e.g
> > > https://github.com/apache/activemq/?tab=security-ov-file#readme ).
> > > Though we can of course make references to it clearer.
> > >
> > > On Tue, 16 Apr 2024 at 17:48, Jean-Baptiste Onofré 
> > wrote:
> > >>
> > >> Hi Matt
> > >>
> > >> Imho, we are mixing two topics here:
> > >> 1. The ticket management system
> > >> 2. The contribution guide
> > >>
> > >> So, let me try to clarify:
> > >>
> > >> [PROPOSAL]
> > >>
> > >> I'm in favor of GH Issues, but we don't yet have a strong consensus
> > >> about that. I would propose a new thread about that to give a chance
> > >> to anyone to speak, and move to a vote.
> > >>
> > >> [README/CONTRIBUTION GUIDE]
> > >>
> > >> First, ICLA is not strictly required before committership (the Apache
> > >> 2.0 license already covered contributor, it has been discussed on
> > >> LEGAL Jira).
> > >> Second, you don't report security issues on a mailing list, you go to
> > >> secur...@apache.org.
> > >> Explaining how to report issue, create PR, contribute (e.g.
> > >> contribution guide) is fine and welcome.
> > >>
> > >> Regards
> > >> JB
> > >>
> > >> On Tue, Apr 16, 2024 at 5:37 PM Matt Pavlovich 
> > wrote:
> > >>>
> > >>> @dev-
> > >>>
> > >>> I appreciate all the good feedback and discussion. A number of good
> > points, suggestions and perspectives. Overall, I see an uptick in community
> > interest in contributing to ActiveMQ and that’s a great thing! I believe
> > that modernizing the toolkit, reducing contribution friction and lowering
> > load on committers/PMC will help keep the community healthy going forward
> > =).
> > >>>
> > >>> I've made a pass at summarizing the points and take-aways from the
> > [DISCUSS] thread below. Please reply with suggested add/edit/removes.
> > >>>
> > >>> [Key community Use Cases]
> > >>>
> > >>> UC-1. Issue - User opens an Issue and may or may not intend (or be
> > able) to produce a PR to address the report.
> > >>>
> > >>> UC-2. PR-onl - User opens a PR without an Issue to address their
> > requested fix.
> > >>>
> > >>> UC-3. Security report - User identifies a security issue and needs to
> > report
> > >>>
> > >>>
> > >>> [Proposal]
> > >>>
> > >>> Action-1. Enable GH issues and flip JIRA to read-only
> > >>>
> > >>> Action-2. Update README in repo to be more of a 'how to engage with
> > the community' vs a project overview
> > >>>
> > >>>
> > >>> [Update README document to include]
> > >>>
> > >>> Update-1. Provide a link for users to create an issue
> > >>>
> > >>> Update-2. Provide a link to the mailing list for reporting a security
> > issue
> > >>>
> > >>> Update-3. Provide a link for users to submit a CLA
> > >>>
> > >>>
> > >>> [Committer/PMC operating]
> > >>>
> > >>> Op-A. For use case #2 where user creates a PR without an issue, before
> > approval committer/pmc may instruct contributor to provide signed CLA and
> > open a corresponding issue if the complexity warrants. The PR comment can
> > then be updated with the issue id for reference and linking.
> > >>>
> > >>> Op-B. Use of GHT Project(s) for planning and tracking Issue & PR for
> > releases.
> > >>>
> > >>> Thanks,
> > >>> Matt Pavlovich
> >
> >

Re: rename activemq-artemis-console-plugin repo

[Robbie Gemmell]

Renaming it seems reasonable if it is not actually going to be just a
plugin anymore.

If everyone agrees, creating a new repo and deleting the old one might
be the quicker approach, since we can do the former ourselves whilst
the rest needs Infra to handle. They might also be more willing to
remove the other without a vote if pointed to discussion and a
replacement repo already existing.

On Thu, 18 Apr 2024 at 12:41, Andy Taylor  wrote:
>
> Devs,
>
> Recently we had a new repo created for the new Artemis console I am working
> on. At the time the console was going to be a plugin similar to what we
> have, however after some design changes it is not more of an extension of
> hawtIO and not shipped as a plugin. The benefit here is that we now only
> need to deploy 1 endpoint in Jetty.
>
> That being the case I would like to rename the repo, or create a new one,
> named activemq-artemis-console which falls more in line with what the
> project actually is.
>
> What do you all think?
>
> If there are no objections I will get this done next week?
>
> Andy T

Re: [PROPOSAL] Enable GH issues

[Robbie Gemmell]

The security bits are also detailed in all the repositories already by
default at the org level, e.g
https://github.com/apache/activemq-artemis/?tab=security-ov-file (or
repositories can define their own policy, e.g
https://github.com/apache/activemq/?tab=security-ov-file#readme ).
Though we can of course make references to it clearer.

On Tue, 16 Apr 2024 at 17:48, Jean-Baptiste Onofré  wrote:
>
> Hi Matt
>
> Imho, we are mixing two topics here:
> 1. The ticket management system
> 2. The contribution guide
>
> So, let me try to clarify:
>
> [PROPOSAL]
>
> I'm in favor of GH Issues, but we don't yet have a strong consensus
> about that. I would propose a new thread about that to give a chance
> to anyone to speak, and move to a vote.
>
> [README/CONTRIBUTION GUIDE]
>
> First, ICLA is not strictly required before committership (the Apache
> 2.0 license already covered contributor, it has been discussed on
> LEGAL Jira).
> Second, you don't report security issues on a mailing list, you go to
> secur...@apache.org.
> Explaining how to report issue, create PR, contribute (e.g.
> contribution guide) is fine and welcome.
>
> Regards
> JB
>
> On Tue, Apr 16, 2024 at 5:37 PM Matt Pavlovich  wrote:
> >
> > @dev-
> >
> > I appreciate all the good feedback and discussion. A number of good points, 
> > suggestions and perspectives. Overall, I see an uptick in community 
> > interest in contributing to ActiveMQ and that’s a great thing! I believe 
> > that modernizing the toolkit, reducing contribution friction and lowering 
> > load on committers/PMC will help keep the community healthy going forward 
> > =).
> >
> > I've made a pass at summarizing the points and take-aways from the 
> > [DISCUSS] thread below. Please reply with suggested add/edit/removes.
> >
> > [Key community Use Cases]
> >
> > UC-1. Issue - User opens an Issue and may or may not intend (or be able) to 
> > produce a PR to address the report.
> >
> > UC-2. PR-onl - User opens a PR without an Issue to address their requested 
> > fix.
> >
> > UC-3. Security report - User identifies a security issue and needs to report
> >
> >
> > [Proposal]
> >
> > Action-1. Enable GH issues and flip JIRA to read-only
> >
> > Action-2. Update README in repo to be more of a 'how to engage with the 
> > community' vs a project overview
> >
> >
> > [Update README document to include]
> >
> > Update-1. Provide a link for users to create an issue
> >
> > Update-2. Provide a link to the mailing list for reporting a security issue
> >
> > Update-3. Provide a link for users to submit a CLA
> >
> >
> > [Committer/PMC operating]
> >
> > Op-A. For use case #2 where user creates a PR without an issue, before 
> > approval committer/pmc may instruct contributor to provide signed CLA and 
> > open a corresponding issue if the complexity warrants. The PR comment can 
> > then be updated with the issue id for reference and linking.
> >
> > Op-B. Use of GHT Project(s) for planning and tracking Issue & PR for 
> > releases.
> >
> > Thanks,
> > Matt Pavlovich

Re: [PROPOSAL] Enable GH issues

[Robbie Gemmell]

I'm not really going to add much in this thread that I didnt already
in the other thread, especially given I'd prefer to stick to JIRA as
it is...though on one specific point below, that wasnt mentioned in
the other thread that I recall...

"Update-3. Provide a link for users to submit a CLA"

Only committers absolutely need an ICLA now (a long time ago it was
decided that the act of explicitly attaching patches to JIRAs or
raising PRs etc, already constituted implicit agreement to contribute
and the right to do so etc, whilst committers also then have to review
such submissions before inclusion), while significant contributors can
also file them, e.g. given extent of contribution or likelihood they
may become committers. People we invite as committers due to
appropriate contributions, we already explicitly indicate they will
need one and how to do it.

We probably shouldnt be encouraging anyone and everyone that doesn't
actually need to to submit a CLA to do so and I'd guess the secretary
probably wouldn't thank us for increasing their load without real
need, for folks that will likely not contribute significantly enough
over time or eventually become committers. I would not be adding that
to the readme personally.

On Tue, 16 Apr 2024 at 16:37, Matt Pavlovich  wrote:
>
> @dev-
>
> I appreciate all the good feedback and discussion. A number of good points, 
> suggestions and perspectives. Overall, I see an uptick in community interest 
> in contributing to ActiveMQ and that’s a great thing! I believe that 
> modernizing the toolkit, reducing contribution friction and lowering load on 
> committers/PMC will help keep the community healthy going forward =).
>
> I've made a pass at summarizing the points and take-aways from the [DISCUSS] 
> thread below. Please reply with suggested add/edit/removes.
>
> [Key community Use Cases]
>
> UC-1. Issue - User opens an Issue and may or may not intend (or be able) to 
> produce a PR to address the report.
>
> UC-2. PR-onl - User opens a PR without an Issue to address their requested 
> fix.
>
> UC-3. Security report - User identifies a security issue and needs to report
>
>
> [Proposal]
>
> Action-1. Enable GH issues and flip JIRA to read-only
>
> Action-2. Update README in repo to be more of a 'how to engage with the 
> community' vs a project overview
>
>
> [Update README document to include]
>
> Update-1. Provide a link for users to create an issue
>
> Update-2. Provide a link to the mailing list for reporting a security issue
>
> Update-3. Provide a link for users to submit a CLA
>
>
> [Committer/PMC operating]
>
> Op-A. For use case #2 where user creates a PR without an issue, before 
> approval committer/pmc may instruct contributor to provide signed CLA and 
> open a corresponding issue if the complexity warrants. The PR comment can 
> then be updated with the issue id for reference and linking.
>
> Op-B. Use of GHT Project(s) for planning and tracking Issue & PR for releases.
>
> Thanks,
> Matt Pavlovich

Re: add key for releasing

[Robbie Gemmell]

I copied the content to the release area file and removed the dev area
copy again to prevent them from diverging in future.

You can also add your key fingerprint to your ASF account using
https://id.apache.org/, having published it to a public keyserver,
such that it is later matched and then shows up at
https://people.apache.org/keys/committer/

On Mon, 15 Apr 2024 at 17:57, Andy Taylor  wrote:
>
> PMC
>
> I need to upload a key so I can carry out some Artemis Console releases. I
> have added my public key to
> https://dist.apache.org/repos/dist/dev/activemq/KEYS could someone update
> the actual https://dist.apache.org/repos/dist/release/activemq/KEYS file
> please>
>
> Cheers
>
> Andy

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell]

The security reporting/followup follow the process/requirements set
out by security@ so we cant really just change things around
that...though if there ideas, then perhaps they can be discussed with
them toward being generally applicable.

I believe there are private subversion repo areas for PMCs (never use
it though), not sure whether there are facilities yet for PMC git
repos.

On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich  wrote:
>
> Got it, that makes sense. I think we could achieve the same effect w/ a 
> private repo (ie "activmeq-pmc”) and enable what ever product features makes 
> sense— issues, discussion, etc.
>
> I agree, moving off of mailing list would be beneficial for certain 
> discussions (esp security reports) b/c of things like attachments, links, etc 
> often become a security challenge w/ email.
>
> -Matt
>
> > On Apr 5, 2024, at 6:58 PM, Clebert Suconic  
> > wrote:
> >
> > I haven’t used it on the Apache Jira but I use private comments all the
> > time on my company JIRA for things that would be related to security and
> > injeritently private.
> >
> > I thought we could eventually start using a feature like that and I thought
> > it would be a nice feature to keep.  But if everybody think we should keep
> > everything open and just use private list for private comments that’s fine.
> >
> > On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich  wrote:
> >
> >> Hi Clebert-
> >>
> >> How widely used are private comments today?
> >>
> >> I ran a search and I do not see any private comments in use with the
> >> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
> >> JQL incorrect?
> >>
> >> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
> >> project = ARTEMIS AND issueFunction in commented(“role PMC")
> >>
> >> An available solution would be to use a private GH repo would secure all
> >> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
> >> could have issues-only or discussion-only for CVE discussions.
> >>
> >> I think private comment is a wonky concept, as it is easy to get that
> >> toggled incorrectly. I think it is better to restrict access to a secured
> >> area vs trying to feather comments.
> >>
> >> Thanks,
> >> Matt
> >>
> >>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic 
> >> wrote:
> >>>
> >>> Is there a private comment capability on GitHub?  To me that’s a breaking
> >>> deal feature and I have never seen it.
> >>>
> >>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> >>> bruscin...@gmail.com> wrote:
> >>>
> >>>> I don't have a strong opinion on migrating from Jira to GitHub Issues.
> >>>> I would prefer GitHub Issues only for its better integration and because
> >>>> new users that reach from the GitHub repository could be confused to not
> >>>> find the `Issues` tabs (most of the GitHub projects use it).
> >>>>
> >>>> Also GitHub Issues has a good REST interface, I'm using it in
> >>>> GithubIssueManager[1].
> >>>>
> >>>> @Justin Bertram  thanks the detailed doc!!!
> >>>>
> >>>> [1]
> >>>>
> >>>>
> >> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
> >>>>
> >>>> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic  >>>
> >>>> wrote:
> >>>>
> >>>>> I would prefer to keep JIRA for their REST interface.
> >>>>>
> >>>>> Also: one thing to notice is the possibility of using private comments
> >>>>> in JIRA. Say you ever have a security issue. I think you can have PMC
> >>>>> private comments on JIRAs. I'm not sure you have the same in github
> >>>>> issues.
> >>>>>
> >>>>>
> >>>>> I didn't see a note about private comments on Justin's detailed doc
> >>>>> (nice Doc BTW), but the private comments may be handy on handling
> >>>>> sensitive issues.
> >>>>>
> >>>>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <
> >> robbie.gemm...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> The 'track version as Project&

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell]

On the lack of Issues tab, though it doesnt seem to have been too much
of an issue so far, we could certainly improve that by ensuring each
repo README always covers how to raise things (or just links to the
website page that covers it; I think some repos already do). Plus,
opening Discussions again might be a suitable alternative for many of
the things that get raised as issues but are actually just questions.

On Fri, 5 Apr 2024 at 17:15, Domenico Francesco Bruscino
 wrote:
>
> I don't have a strong opinion on migrating from Jira to GitHub Issues.
> I would prefer GitHub Issues only for its better integration and because
> new users that reach from the GitHub repository could be confused to not
> find the `Issues` tabs (most of the GitHub projects use it).
>
> Also GitHub Issues has a good REST interface, I'm using it in
> GithubIssueManager[1].
>
> @Justin Bertram  thanks the detailed doc!!!
>
> [1]
> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
>
> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic 
> wrote:
>
> > I would prefer to keep JIRA for their REST interface.
> >
> > Also: one thing to notice is the possibility of using private comments
> > in JIRA. Say you ever have a security issue. I think you can have PMC
> > private comments on JIRAs. I'm not sure you have the same in github
> > issues.
> >
> >
> > I didn't see a note about private comments on Justin's detailed doc
> > (nice Doc BTW), but the private comments may be handy on handling
> > sensitive issues.
> >
> > On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell 
> > wrote:
> > >
> > > The 'track version as Project' thing is interesting, though kinda
> > > further underscores the limitations of Milestones which are really the
> > > main surfaced way of handling versions.
> > >
> > > I'll bet some folks on the 'users' side of things looking at released
> > > issues later would even miss that you are doing that (I would), since
> > > Projects are kinda separate and get even further hidden away upon
> > > completion; closed Projects are hidden/collapsed in the Issue/PR view
> > > on expectations they are no longer 'interesting', requiring you to
> > > spot that and expand the closed-projects view on each Issue/PR to see
> > > the Project later. Which to be fair I think is actually decent
> > > behaviour in general for their main use cases, since they aren't
> > > really aimed to be used as versions but more for using the 'swimlane'
> > > etc views given for managing/planning overall outstanding tasks to a
> > > point of completion and will then most typically be
> > > forgotten/less-interesting detail.
> > >
> > > On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> > >  wrote:
> > > >
> > > > I am also on the Accumulo PMC and on that project we use Github issues
> > > > and no longer use Jira. This switch was made before my time so I'm not
> > > > sure of the reasoning. Personally, I don't really care too much either
> > > > way as I've used both but I will just point out 2 things from my
> > > > experience with it.
> > > >
> > > > 1) For version tracking, we use projects and not milestones. I don't
> > > > know if this is the best way to do things but that's what we have been
> > > > using and seems to work ok as you can list multiple projects
> > > > (versions) for an Issue or PR:
> > > > https://github.com/apache/accumulo/projects?type=classic
> > > >
> > > > 2) Robbie's point about whether or not Issues get opened is a really
> > > > good point and something that is not consistent at all in Accumulo.
> > > > What I have found is it is all over the place. In some cases people
> > > > just open PRs and essentially are self documenting issues with the
> > > > fix. In other cases people open up issues and then open up PRs. It
> > > > does get confusing sometimes since they share the same numbering and
> > > > name space. It may make sense to try and establish some guidelines if
> > > > we go with Github Issues just so we are consistent about it.
> > > >
> > > > On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich 
> > wrote:
> > > > >
> > > > >
> > > > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
> > robbie.gemm...@gmail.com&g

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell]

Whilst Jira can certainly do that, I dont believe we have ever used it
in that fashion here, and so I dont see that it could be considered a
break either way. Also, the process of e.g privately reporting
security issues wouldnt change in any event, it would remain as it is
now (and is detailed on each github repository already due to some org
level defaults).

On Fri, 5 Apr 2024 at 17:48, Clebert Suconic  wrote:
>
> Is there a private comment capability on GitHub?  To me that’s a breaking
> deal feature and I have never seen it.
>
> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> bruscin...@gmail.com> wrote:
>
> > I don't have a strong opinion on migrating from Jira to GitHub Issues.
> > I would prefer GitHub Issues only for its better integration and because
> > new users that reach from the GitHub repository could be confused to not
> > find the `Issues` tabs (most of the GitHub projects use it).
> >
> > Also GitHub Issues has a good REST interface, I'm using it in
> > GithubIssueManager[1].
> >
> > @Justin Bertram  thanks the detailed doc!!!
> >
> > [1]
> >
> > https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
> >
> > On Fri, 5 Apr 2024 at 17:41, Clebert Suconic 
> > wrote:
> >
> > > I would prefer to keep JIRA for their REST interface.
> > >
> > > Also: one thing to notice is the possibility of using private comments
> > > in JIRA. Say you ever have a security issue. I think you can have PMC
> > > private comments on JIRAs. I'm not sure you have the same in github
> > > issues.
> > >
> > >
> > > I didn't see a note about private comments on Justin's detailed doc
> > > (nice Doc BTW), but the private comments may be handy on handling
> > > sensitive issues.
> > >
> > > On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell 
> > > wrote:
> > > >
> > > > The 'track version as Project' thing is interesting, though kinda
> > > > further underscores the limitations of Milestones which are really the
> > > > main surfaced way of handling versions.
> > > >
> > > > I'll bet some folks on the 'users' side of things looking at released
> > > > issues later would even miss that you are doing that (I would), since
> > > > Projects are kinda separate and get even further hidden away upon
> > > > completion; closed Projects are hidden/collapsed in the Issue/PR view
> > > > on expectations they are no longer 'interesting', requiring you to
> > > > spot that and expand the closed-projects view on each Issue/PR to see
> > > > the Project later. Which to be fair I think is actually decent
> > > > behaviour in general for their main use cases, since they aren't
> > > > really aimed to be used as versions but more for using the 'swimlane'
> > > > etc views given for managing/planning overall outstanding tasks to a
> > > > point of completion and will then most typically be
> > > > forgotten/less-interesting detail.
> > > >
> > > > On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> > > >  wrote:
> > > > >
> > > > > I am also on the Accumulo PMC and on that project we use Github
> > issues
> > > > > and no longer use Jira. This switch was made before my time so I'm
> > not
> > > > > sure of the reasoning. Personally, I don't really care too much
> > either
> > > > > way as I've used both but I will just point out 2 things from my
> > > > > experience with it.
> > > > >
> > > > > 1) For version tracking, we use projects and not milestones. I don't
> > > > > know if this is the best way to do things but that's what we have
> > been
> > > > > using and seems to work ok as you can list multiple projects
> > > > > (versions) for an Issue or PR:
> > > > > https://github.com/apache/accumulo/projects?type=classic
> > > > >
> > > > > 2) Robbie's point about whether or not Issues get opened is a really
> > > > > good point and something that is not consistent at all in Accumulo.
> > > > > What I have found is it is all over the place. In some cases people
> > > > > just open PRs and essentially are self documenting issues with the
> > > > > fix. In other cases people open u

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell]

The 'track version as Project' thing is interesting, though kinda
further underscores the limitations of Milestones which are really the
main surfaced way of handling versions.

I'll bet some folks on the 'users' side of things looking at released
issues later would even miss that you are doing that (I would), since
Projects are kinda separate and get even further hidden away upon
completion; closed Projects are hidden/collapsed in the Issue/PR view
on expectations they are no longer 'interesting', requiring you to
spot that and expand the closed-projects view on each Issue/PR to see
the Project later. Which to be fair I think is actually decent
behaviour in general for their main use cases, since they aren't
really aimed to be used as versions but more for using the 'swimlane'
etc views given for managing/planning overall outstanding tasks to a
point of completion and will then most typically be
forgotten/less-interesting detail.

On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
 wrote:
>
> I am also on the Accumulo PMC and on that project we use Github issues
> and no longer use Jira. This switch was made before my time so I'm not
> sure of the reasoning. Personally, I don't really care too much either
> way as I've used both but I will just point out 2 things from my
> experience with it.
>
> 1) For version tracking, we use projects and not milestones. I don't
> know if this is the best way to do things but that's what we have been
> using and seems to work ok as you can list multiple projects
> (versions) for an Issue or PR:
> https://github.com/apache/accumulo/projects?type=classic
>
> 2) Robbie's point about whether or not Issues get opened is a really
> good point and something that is not consistent at all in Accumulo.
> What I have found is it is all over the place. In some cases people
> just open PRs and essentially are self documenting issues with the
> fix. In other cases people open up issues and then open up PRs. It
> does get confusing sometimes since they share the same numbering and
> name space. It may make sense to try and establish some guidelines if
> we go with Github Issues just so we are consistent about it.
>
> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich  wrote:
> >
> >
> > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell  
> > > wrote:
> > >
> > > To the later point around Discussions, I do think enabling those could
> > > be good either way since, just like with Jira, people will often
> > > create Issues to ask questions rather than e.g mail a mailing list.
> > > They might use a Discussion instead though.
> >
> > +1 agree that having discussions enabled would be an upgrade for users, big 
> > improvement over mailing lists.
> >
> > > On Tue, 2 Apr 2024 at 20:52, Justin Bertram  wrote:
> > >>
> > >> There's been a few threads about this general subject, but most have
> > >> concentrated on Classic in particular. I think it's worth discussing
> > >> migration of ActiveMQ as a whole and diving a bit deeper into the details
> > >> of why a migration makes (or doesn't make) sense and what the challenges
> > >> may be.
> > >>
> > >> To this end I've put together this document [1]. I hope it will be of
> > >> service to the community as we consider this option.
> > >>
> > >>
> > >> Justin
> > >>
> > >> [1]
> > >> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> >

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell]

I prefer Jira for issue tracking, I think it's better at it,
particularly for cases like 5.x / 6.x having multiple active release
streams with lots of backports, given the limitations of Milestone
handling and how people tend to treat xref'ing to fully compensate for
that (i.e they often dont bother).

I would be fine with adopting Issues too though, I use Issues plenty
elsewhere where it's enabled by default and the only option anyway
hehe.

I expect most users reporting things would prefer Issues at this
point, especially anyone intende to raise a PR, and most particularly
all the folks without Jira accounts already (of course, I also think
many of those asking for accounts dont actually need one; see
Discussions note at end).

I dont actually think every component needs to use the exact same
labels etc. People are already used to just about every other GitHub
repo they encounter at this point which uses Issue having their own
labels. For me, the labels just need to make sense in themselves.
Though the default ones are simple, so I'd be fine with them, which
would then just happen to be consistent.

It's not clear to me anyone proposing to move to Issues actually
intended thus far to migrate any of the [open] issues from Jira to
Github Issues, so much as just start using Github Issues and thus
effectively 'clearing the cruft' by leaving it where it is, then
raising new issues going forward?

To the later point around Discussions, I do think enabling those could
be good either way since, just like with Jira, people will often
create Issues to ask questions rather than e.g mail a mailing list.
They might use a Discussion instead though.

On Tue, 2 Apr 2024 at 20:52, Justin Bertram  wrote:
>
> There's been a few threads about this general subject, but most have
> concentrated on Classic in particular. I think it's worth discussing
> migration of ActiveMQ as a whole and diving a bit deeper into the details
> of why a migration makes (or doesn't make) sense and what the challenges
> may be.
>
> To this end I've put together this document [1]. I hope it will be of
> service to the community as we consider this option.
>
>
> Justin
>
> [1]
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell]

On Wed, 3 Apr 2024 at 21:14, Matt Pavlovich  wrote:
>
> Hello @dev-
>
> I argue that we are effectively already using GitHub for issues, JIRA is just 
> getting a back-port sync of the discussion. The reality is that code-change 
> discussions are occurring on the PRs, not in JIRA or mailing lists-- and that 
> makes sense. It is far easier to have a discussion while referencing the line 
> of code and providing a checklist of issues to resolve to the committer. The 
> GitHub-to-JIRA synchronization is noisy and generates a lot of text in the 
> JIRA comments that aren't really legible.
>

That argument seems centered on the code discussion on a PR being the
main interesting bit of a Jira / Issue. For me, and I expect a lot of
users, I'd say it is often rather more the initial description/report
for e.g what a bug is, the collating of the [often multiple and
separate] commits made to fix it, and the release version tracking,
that tend to be as much or more interesting aspect of a Jira than what
are often just 'working thoughts' comments on a PR to get from the
initial proposed change to whatever is pushed. For that stuff, indeed
the PR is often a better place for to see that in-context. This would
be true for me, and again I expect a lot of users, regardless whether
it was an Issue or a Jira being used to track things (or at least,
would be supposing people adequately xref commits/Issues to make up
for the limitations in Issues/PRs use of Milestones to track
versions...i.e they can only point to 1).

(On the comments, the Github updates on our Jira's go in as 'work log'
entries rather than regular comments, so they actually aren't in the
way normally)

> The JIRA issue-to-PR process is cumbersome, there's now even a "NO-JIRA" 
> process to work around that reality -- and that has led to back-and-forth on 
> certain issues that start NO-JIRA, and then need to have a JIRA created and 
> vice-versa.
>

Thats been happening since before PRs were an option, started due to
direct commit/push behaviour where PRs wouldnt have existed anyway,
and could essentially still happen with Issues too depending on what
approach were to be decided on for Issue <-> PR relationship, i.e
whether an issue is always needed or if a PR alone is sufficient.

It was me that initially coined the NO-JIRA thing over at Qpid  > 10
years ago, as an escape for a commit hook that required a Jira ref, to
help prod people that were not creating Jiras for
actually-quite-important/notable changes out of pure laziness, and
make it clear it wasnt then 'just an oversight' it was omitted. Alas,
since the ASF operated on a single foundation-wide Subversion
repository at the time, and due to the way the hook had to actually
operate as a result, it was found to be too slow to justify applying
it to every commit at the ASF just for one/some projects benefit to
prod people to be less lazy, and so that side ultimately didnt happen.
The commit message bit stuck around though, migrated, and has over
time become just as abused as reference'less commit logs were. Doh :)

The equivalent while having Issues instead of Jira's would center
around deciding if we wanted to always have an Issue for a given
change even if a PR is being raised, given that whilst they do share a
number space they are still defaulted to mostly being distinct things
in the UI and URLs. I expect many people making changes often won't
bother to raise an Issue, just the PR (or again, sometimes neither).
Most people not interested in making changes (i.e most user reports)
will of course just raise an Issue alone. Often people will raise a
non-xref'd PR for the same thing even though the Issue exists, since
they didnt raise or notice that Issue themselves originally (same
happen with Jira's too). This is an annoyance I find with Issues and
PRs, sharing a number space and being treated similarly by many, while
still being considered quite separate especially in the UI and URls
(the main annoyance being Milestone handling, where you can only have
1, which I find it means most projects just have useless or no release
notes for their non-latest releases as a result, and you really just
need to look at the tags and commits to see what you need)


> Issues:
>  - Customizable templates that can enforce policy to reduce back-and-forth 
> with in-experienced issue submitters.

I find those templates as much just increase the number of Issues
littered with templates not actually filled in.

>
> Release notes:
>  - Simple generation, template-izable and ability to customize at release 
> time (ie to remove any NO-JIRA type things that don't need to be in release 
> notes)
>
> In terms of migration complexity, I think the numbers make the migration 
> effort look larger than the actual reality on the ground. We are really 
> talking about 2 active repos (activemq & artemis) and 1 periodically updated 
> repo (nms).
>
> Migration can be over time and on a project-by-project or repo-by-repo basis. 
> The 

Re: Upgrading the Artemis Console

[Robbie Gemmell]

Seems good to me

On Mon, 18 Mar 2024 at 17:35, Andy Taylor  wrote:
>
> so I am open to names, how about artemis-console-plugin v1.0.0
>
> On Mon, 18 Mar 2024 at 17:24, Clebert Suconic 
> wrote:
>
> > +1 on activemq-artemis-console-plugin
> >
> >
> > As Robbie said, you will need different versions for it. I feel like
> > it would be easier to use a different name... but I don't mind what
> > you have to do. Whatever makes it easier to be implemented.
> >
> >
> > On Mon, Mar 18, 2024 at 1:10 PM Robbie Gemmell 
> > wrote:
> > >
> > > On the module name, if it stays the same then consideration would also
> > > need to be given to the version. It would need to be higher than
> > > before to keep using the same name, but using a broker version isnt
> > > necessarily that obvious if we dont expect to release it on the same
> > > schedule as the broker.
> > >
> > > On Mon, 18 Mar 2024 at 16:46, Andy Taylor 
> > wrote:
> > > >
> > > > +1 for  avtivemq-artemis-console-plugin but I think we should keep the
> > > > artifact name as it is now for consistency, i.e. artemis-plugin
> > > >
> > > > On Mon, 18 Mar 2024 at 16:29, Robbie Gemmell  > >
> > > > wrote:
> > > >
> > > > > We should discuss the name then someone can create it via
> > > > > https://selfserve.apache.org
> > > > >
> > > > > It would be something of the form activemq-artemis- for
> > > > > consistency. Regarding , what is actually going in it, a console
> > > > > 'plugin' ?
> > > > >
> > > > > So perhaps activemq-artemis-console-plugin ?
> > > > >
> > > > > On Mon, 18 Mar 2024 at 07:46, Andy Taylor 
> > wrote:
> > > > > >
> > > > > > Lets go with a separate repo then, @clebert or anyone, can you
> > create me
> > > > > a
> > > > > > new repo or talk me thru how to do it. What shall we call this new
> > > > > > component/repo, considering we will still have an artemis-console
> > module
> > > > > in
> > > > > > the artemis repo?
> > > > > >
> > > > > > Clebert, I will add this new fields in your PR to the new console
> > as
> > > > > well.
> > > > > >
> > > > > > Andy
> > > > > >
> > > > > > On Fri, 15 Mar 2024 at 19:03, Clebert Suconic <
> > clebert.suco...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I think we have a consensus on a separate repo.
> > > > > > >
> > > > > > >
> > > > > > > @Andy:  me an Anton, we wre adding a field for internal queues
> > in the
> > > > > admin
> > > > > > > console. If you could make sure we keep that on the new one
> > please ?
> > > > > Or
> > > > > > > let us know how to adjust it?
> > > > > > >
> > > > > > >
> > > > > > > https://github.com/apache/activemq-artemis/pull/4856
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Mar 14, 2024 at 10:29 AM Justin Bertram <
> > jbert...@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1 for a separate repo
> > > > > > > >
> > > > > > > >
> > > > > > > > Justin
> > > > > > > >
> > > > > > > > On Thu, Mar 14, 2024 at 3:56 AM Andy Taylor <
> > andy.tayl...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Clebert, I think it will be weeks rather than days so I
> > would just
> > > > > > > > release
> > > > > > > > > when you are ready.
> > > > > > > > >
> > > > > > > > > Robbie, I think for now a separate repo is my preferred
> > solution,
> > > > > the
> > > > > > > > > console can actually be run outside of embedded artemis so
> > > > > development
> > > > > > > is
> > > > > > > >

Re: Upgrading the Artemis Console

[Robbie Gemmell]

On the module name, if it stays the same then consideration would also
need to be given to the version. It would need to be higher than
before to keep using the same name, but using a broker version isnt
necessarily that obvious if we dont expect to release it on the same
schedule as the broker.

On Mon, 18 Mar 2024 at 16:46, Andy Taylor  wrote:
>
> +1 for  avtivemq-artemis-console-plugin but I think we should keep the
> artifact name as it is now for consistency, i.e. artemis-plugin
>
> On Mon, 18 Mar 2024 at 16:29, Robbie Gemmell 
> wrote:
>
> > We should discuss the name then someone can create it via
> > https://selfserve.apache.org
> >
> > It would be something of the form activemq-artemis- for
> > consistency. Regarding , what is actually going in it, a console
> > 'plugin' ?
> >
> > So perhaps activemq-artemis-console-plugin ?
> >
> > On Mon, 18 Mar 2024 at 07:46, Andy Taylor  wrote:
> > >
> > > Lets go with a separate repo then, @clebert or anyone, can you create me
> > a
> > > new repo or talk me thru how to do it. What shall we call this new
> > > component/repo, considering we will still have an artemis-console module
> > in
> > > the artemis repo?
> > >
> > > Clebert, I will add this new fields in your PR to the new console as
> > well.
> > >
> > > Andy
> > >
> > > On Fri, 15 Mar 2024 at 19:03, Clebert Suconic  > >
> > > wrote:
> > >
> > > > I think we have a consensus on a separate repo.
> > > >
> > > >
> > > > @Andy:  me an Anton, we wre adding a field for internal queues in the
> > admin
> > > > console. If you could make sure we keep that on the new one please ?
> > Or
> > > > let us know how to adjust it?
> > > >
> > > >
> > > > https://github.com/apache/activemq-artemis/pull/4856
> > > >
> > > >
> > > > On Thu, Mar 14, 2024 at 10:29 AM Justin Bertram 
> > > > wrote:
> > > >
> > > > > +1 for a separate repo
> > > > >
> > > > >
> > > > > Justin
> > > > >
> > > > > On Thu, Mar 14, 2024 at 3:56 AM Andy Taylor 
> > > > > wrote:
> > > > >
> > > > > > Clebert, I think it will be weeks rather than days so I would just
> > > > > release
> > > > > > when you are ready.
> > > > > >
> > > > > > Robbie, I think for now a separate repo is my preferred solution,
> > the
> > > > > > console can actually be run outside of embedded artemis so
> > development
> > > > is
> > > > > > easy. Can someone create a new repo?
> > > > > >
> > > > > > On Wed, 13 Mar 2024 at 17:45, Clebert Suconic <
> > > > clebert.suco...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > If it was a matter of 1 day to include it I would prefer to wait
> > for
> > > > > it.
> > > > > > > Other than that then I’m releasing on Monday.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 1:40 PM Robbie Gemmell <
> > > > > robbie.gemm...@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I'd say the answer to 'Wait for  to do a release?' is
> > usually
> > > > no
> > > > > > > > unless its about a blocking bug/regression or there's really
> > > > nothing
> > > > > > > > else important ready to go. This definitely isnt that and also
> > isnt
> > > > > > > > ready yet while other stuff is, so seems a clear no to me.
> > > > > > > >
> > > > > > > > On Wed, 13 Mar 2024 at 16:58, Clebert Suconic <
> > > > > > clebert.suco...@gmail.com
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Should I wait for the 2.33 release ?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > See my other thread about the heads up.
> > > > > > > > >
> > > > > > > > 

Re: Upgrading the Artemis Console

[Robbie Gemmell]

We should discuss the name then someone can create it via
https://selfserve.apache.org

It would be something of the form activemq-artemis- for
consistency. Regarding , what is actually going in it, a console
'plugin' ?

So perhaps activemq-artemis-console-plugin ?

On Mon, 18 Mar 2024 at 07:46, Andy Taylor  wrote:
>
> Lets go with a separate repo then, @clebert or anyone, can you create me a
> new repo or talk me thru how to do it. What shall we call this new
> component/repo, considering we will still have an artemis-console module in
> the artemis repo?
>
> Clebert, I will add this new fields in your PR to the new console as well.
>
> Andy
>
> On Fri, 15 Mar 2024 at 19:03, Clebert Suconic 
> wrote:
>
> > I think we have a consensus on a separate repo.
> >
> >
> > @Andy:  me an Anton, we wre adding a field for internal queues in the admin
> > console. If you could make sure we keep that on the new one please ?  Or
> > let us know how to adjust it?
> >
> >
> > https://github.com/apache/activemq-artemis/pull/4856
> >
> >
> > On Thu, Mar 14, 2024 at 10:29 AM Justin Bertram 
> > wrote:
> >
> > > +1 for a separate repo
> > >
> > >
> > > Justin
> > >
> > > On Thu, Mar 14, 2024 at 3:56 AM Andy Taylor 
> > > wrote:
> > >
> > > > Clebert, I think it will be weeks rather than days so I would just
> > > release
> > > > when you are ready.
> > > >
> > > > Robbie, I think for now a separate repo is my preferred solution, the
> > > > console can actually be run outside of embedded artemis so development
> > is
> > > > easy. Can someone create a new repo?
> > > >
> > > > On Wed, 13 Mar 2024 at 17:45, Clebert Suconic <
> > clebert.suco...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > If it was a matter of 1 day to include it I would prefer to wait for
> > > it.
> > > > > Other than that then I’m releasing on Monday.
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2024 at 1:40 PM Robbie Gemmell <
> > > robbie.gemm...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > I'd say the answer to 'Wait for  to do a release?' is usually
> > no
> > > > > > unless its about a blocking bug/regression or there's really
> > nothing
> > > > > > else important ready to go. This definitely isnt that and also isnt
> > > > > > ready yet while other stuff is, so seems a clear no to me.
> > > > > >
> > > > > > On Wed, 13 Mar 2024 at 16:58, Clebert Suconic <
> > > > clebert.suco...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Should I wait for the 2.33 release ?
> > > > > > >
> > > > > > >
> > > > > > > See my other thread about the heads up.
> > > > > > >
> > > > > > >
> > > > > > > Or you think this may take a lot longer ?
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024 at 7:27 AM Andy Taylor <
> > > andy.tayl...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > The current Artemis console is based on HawtIO 1 which itself
> > is
> > > > > > written
> > > > > > > > using Bootstrap. Bootstrap is old and no longer maintained so
> > > > HawtIO
> > > > > > (v3/4)
> > > > > > > > has moved to use React and Patternfly and is also written in
> > > > > > Typescript.
> > > > > > > >
> > > > > > > > I have been working in the background over the last several
> > > months
> > > > to
> > > > > > > > upgrade the console to hawtIO 4, this work can be found here
> > > > > > > > <
> > > > > >
> > > https://github.com/andytaylor/activemq-artemis/tree/artemis-console-ng
> > > > >.
> > > > > > > > This is still a WIP but is close to completion, I basically
> > have
> > > to
> > > > > > finish
> > > > > > > > off some branding, fix the console tests and implement an
> > upgrade
> &g

Re: Upgrading the Artemis Console

[Robbie Gemmell]

That it can actually be run standalone would be another reason I'd
also choose to go with a separate repo.

Lets allow other folks time to chip in their opinions, if a separate
repo appears to be the consensus we can then look to create one.

On Thu, 14 Mar 2024 at 08:51, Andy Taylor  wrote:
>
> Clebert, I think it will be weeks rather than days so I would just release
> when you are ready.
>
> Robbie, I think for now a separate repo is my preferred solution, the
> console can actually be run outside of embedded artemis so development is
> easy. Can someone create a new repo?
>
> On Wed, 13 Mar 2024 at 17:45, Clebert Suconic 
> wrote:
>
> > If it was a matter of 1 day to include it I would prefer to wait for it.
> > Other than that then I’m releasing on Monday.
> >
> >
> > On Wed, Mar 13, 2024 at 1:40 PM Robbie Gemmell 
> > wrote:
> >
> > > I'd say the answer to 'Wait for  to do a release?' is usually no
> > > unless its about a blocking bug/regression or there's really nothing
> > > else important ready to go. This definitely isnt that and also isnt
> > > ready yet while other stuff is, so seems a clear no to me.
> > >
> > > On Wed, 13 Mar 2024 at 16:58, Clebert Suconic  > >
> > > wrote:
> > > >
> > > > Should I wait for the 2.33 release ?
> > > >
> > > >
> > > > See my other thread about the heads up.
> > > >
> > > >
> > > > Or you think this may take a lot longer ?
> > > >
> > > > On Wed, Mar 13, 2024 at 7:27 AM Andy Taylor 
> > > wrote:
> > > >
> > > > > The current Artemis console is based on HawtIO 1 which itself is
> > > written
> > > > > using Bootstrap. Bootstrap is old and no longer maintained so HawtIO
> > > (v3/4)
> > > > > has moved to use React and Patternfly and is also written in
> > > Typescript.
> > > > >
> > > > > I have been working in the background over the last several months to
> > > > > upgrade the console to hawtIO 4, this work can be found here
> > > > > <
> > > https://github.com/andytaylor/activemq-artemis/tree/artemis-console-ng>.
> > > > > This is still a WIP but is close to completion, I basically have to
> > > finish
> > > > > off some branding, fix the console tests and implement an upgrade
> > > feature.
> > > > > A couple of things to note:
> > > > >
> > > > >
> > > > >- I have separated out the JMX tree and its tabs from the tabs
> > that
> > > are
> > > > >not related to the tree selection. I always found this a bit
> > > strange so
> > > > > now
> > > > >there are 2 tabs Artemis and Artemis JMX, the latter uses the JMX
> > > tree
> > > > > as
> > > > >before. It is possible however to do anything in the Artemis tab
> > > that
> > > > > you
> > > > >can do in the JMX tab, view attributes and operations for
> > instance.
> > > > > There
> > > > >is an issue currently where if there are thousands of address or
> > > queues
> > > > >then performance becomes an issue. this is because the whole JMX
> > > tree is
> > > > >loaded into memory and this can cause even the broker to fall
> > over.
> > > My
> > > > > plan
> > > > >at some point is to allow disabling the JMX view and to lazy load
> > in
> > > > > MBeans
> > > > >as and when needed, this is a task for further down the road tho.
> > > > >- The console is built using yarn and is incredibly slow to build,
> > > in
> > > > >fact it takes longer than it takes to build the rest of Artemis.
> > It
> > > may
> > > > > be
> > > > >better to have the new console in its own repository, release it
> > > > >independently and just consume it in Artemis. This means some
> > extra
> > > work
> > > > >for a release but once the console becomes stable it shouldn't be
> > > too
> > > > > much
> > > > >work. I will however let the community decide what is the best
> > > approach.
> > > > >
> > > > >
> > > > > There are still a few issues I know of, the Attributes tab seems to
> > > delay
> > > > > loading and the broker topology diagram is incomplete but feel free
> > to
> > > > > suggest any improvements or buglets you come across on this thread.
> > > > > Hopefully I can tie up the loose ends soon and raise a PR in the not
> > > too
> > > > > distant future.
> > > > >
> > > > > Andy
> > > > >
> > >
> >

Re: Upgrading the Artemis Console

[Robbie Gemmell]

I'd say the answer to 'Wait for  to do a release?' is usually no
unless its about a blocking bug/regression or there's really nothing
else important ready to go. This definitely isnt that and also isnt
ready yet while other stuff is, so seems a clear no to me.

On Wed, 13 Mar 2024 at 16:58, Clebert Suconic  wrote:
>
> Should I wait for the 2.33 release ?
>
>
> See my other thread about the heads up.
>
>
> Or you think this may take a lot longer ?
>
> On Wed, Mar 13, 2024 at 7:27 AM Andy Taylor  wrote:
>
> > The current Artemis console is based on HawtIO 1 which itself is written
> > using Bootstrap. Bootstrap is old and no longer maintained so HawtIO (v3/4)
> > has moved to use React and Patternfly and is also written in Typescript.
> >
> > I have been working in the background over the last several months to
> > upgrade the console to hawtIO 4, this work can be found here
> > .
> > This is still a WIP but is close to completion, I basically have to finish
> > off some branding, fix the console tests and implement an upgrade feature.
> > A couple of things to note:
> >
> >
> >- I have separated out the JMX tree and its tabs from the tabs that are
> >not related to the tree selection. I always found this a bit strange so
> > now
> >there are 2 tabs Artemis and Artemis JMX, the latter uses the JMX tree
> > as
> >before. It is possible however to do anything in the Artemis tab that
> > you
> >can do in the JMX tab, view attributes and operations for instance.
> > There
> >is an issue currently where if there are thousands of address or queues
> >then performance becomes an issue. this is because the whole JMX tree is
> >loaded into memory and this can cause even the broker to fall over. My
> > plan
> >at some point is to allow disabling the JMX view and to lazy load in
> > MBeans
> >as and when needed, this is a task for further down the road tho.
> >- The console is built using yarn and is incredibly slow to build, in
> >fact it takes longer than it takes to build the rest of Artemis. It may
> > be
> >better to have the new console in its own repository, release it
> >independently and just consume it in Artemis. This means some extra work
> >for a release but once the console becomes stable it shouldn't be too
> > much
> >work. I will however let the community decide what is the best approach.
> >
> >
> > There are still a few issues I know of, the Attributes tab seems to delay
> > loading and the broker topology diagram is incomplete but feel free to
> > suggest any improvements or buglets you come across on this thread.
> > Hopefully I can tie up the loose ends soon and raise a PR in the not too
> > distant future.
> >
> > Andy
> >

Re: Upgrading the Artemis Console

[Robbie Gemmell]

Having spent a while making the build much faster than it historically
was, if it was to go in the artemis repo directly I'd at least want a
way to disable building the console to allow keeping things more like
their current state, for all those times doing stuff not actually
involving the console (for me, thats actually most of the time).

Having it in its own repo does seem like it may be simpler and nicer
though, even if it comes with the 'do a console release first'
overhead when actually updating it. We dont do a huge number of
releases, and the console doesnt change for many of them, so I dont
think that should be too big an issue after some initial churn.

We can always change it if we dont like it, whichever route is chosen initially.

On Wed, 13 Mar 2024 at 11:26, Andy Taylor  wrote:
>
> The current Artemis console is based on HawtIO 1 which itself is written
> using Bootstrap. Bootstrap is old and no longer maintained so HawtIO (v3/4)
> has moved to use React and Patternfly and is also written in Typescript.
>
> I have been working in the background over the last several months to
> upgrade the console to hawtIO 4, this work can be found here
> .
> This is still a WIP but is close to completion, I basically have to finish
> off some branding, fix the console tests and implement an upgrade feature.
> A couple of things to note:
>
>
>- I have separated out the JMX tree and its tabs from the tabs that are
>not related to the tree selection. I always found this a bit strange so now
>there are 2 tabs Artemis and Artemis JMX, the latter uses the JMX tree as
>before. It is possible however to do anything in the Artemis tab that you
>can do in the JMX tab, view attributes and operations for instance. There
>is an issue currently where if there are thousands of address or queues
>then performance becomes an issue. this is because the whole JMX tree is
>loaded into memory and this can cause even the broker to fall over. My plan
>at some point is to allow disabling the JMX view and to lazy load in MBeans
>as and when needed, this is a task for further down the road tho.
>- The console is built using yarn and is incredibly slow to build, in
>fact it takes longer than it takes to build the rest of Artemis. It may be
>better to have the new console in its own repository, release it
>independently and just consume it in Artemis. This means some extra work
>for a release but once the console becomes stable it shouldn't be too much
>work. I will however let the community decide what is the best approach.
>
>
> There are still a few issues I know of, the Attributes tab seems to delay
> loading and the broker topology diagram is incomplete but feel free to
> suggest any improvements or buglets you come across on this thread.
> Hopefully I can tie up the loose ends soon and raise a PR in the not too
> distant future.
>
> Andy

Re: [VOTE] Apache ActiveMQ 6.1.0 release

[Robbie Gemmell]

I was going to vote positively, but after seeing the earlier mails and
trying things out further I see the same issue as Matt has reported.

The quotes added on this line:
https://github.com/apache/activemq/blob/6bae734088d70b8e1a72ab6f3a763199d38af306/assembly/src/release/bin/activemq#L174
in https://github.com/apache/activemq/pull/1162 breaks loading of the
setenv config (and presumably the earlier config paths if they were
present).

With the quotes in place, I edited the setenv file to also set a
custom system property, and observed that it wasnt applied due to the
setenv file not being used and the "INFO: Using default configuration"
message Matt referenced below being printed.

Removing the quotes on that line, the setenv config was actually found
and used (and my custom property in it was then set on the JVM):
INFO: Loading '/path/to/6.1.0-rc1/apache-activemq-6.1.0//bin/setenv'

(I wasnt using a dir with spaces)

Robbie

On Thu, 7 Mar 2024 at 21:48, Matt Pavlovich  wrote:
>
> Heads up— while working on another fix, I may have stubbled on a regression 
> caused by the change below and may need to revert my +1 to a -1
>
> Support space in filename:
> https://github.com/apache/activemq/pull/1162
>
> INFO: Using default configuration
>   Configurations are loaded in the following order: /etc/default/activemq 
> /Users/activemq/.activemqrc 
> "/Users/activemq/apache-activemq-6.1.0/"/bin/setenv
>
> This appears to cause the setenv to not be sourced and configs (such as JAAS 
> login.config and JMX settings are not picked up at boot)
>
> I’m doing some additional testing and will report back, but I believe we need 
> to hold the release until this is verified.
>
> Thanks,
> Matt
>
> > On Mar 7, 2024, at 2:05 PM, Matt Pavlovich  wrote:
> >
> > +1 (binding)
> >
> > - Downloaded dist tar.gz archive and confirmed various configurations using 
> > JDK 21
> > - Tested web console demo examples
> > - Tested web console functions
> > - Reviewed JIRA and release notes
> >
> > Thanks,
> > Matt Pavlovich
> >
> >> On Mar 5, 2024, at 11:38 AM, Jean-Baptiste Onofré  
> >> wrote:
> >>
> >> Hi guys,
> >>
> >> I submit Apache ActiveMQ "Classic" 6.1.0 release to your vote.
> >>
> >> This release includes:
> >> - New JMS2/3 operations support
> >> - Mapping javax / jakarta exception in openwire protocol
> >> - Add destination field on the job scheduler
> >> - Add org.apache.activemq.broker.BouncyCastleNotAdded property to
> >> control the bouncycastle addition in BrokerService classloader
> >> - Dependency upgrades (Spring 6.1.4, log4j 2.23.0, Jetty 11.0.20, ...)
> >> - and a lot more !
> >>
> >> You can take a look on Release Notes for details:
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353745
> >>
> >> Maven Staging Repository:
> >> https://repository.apache.org/content/repositories/orgapacheactivemq-1387/
> >>
> >> Dist Staging Repository:
> >> https://dist.apache.org/repos/dist/dev/activemq/activemq/6.1.0/
> >>
> >> Git tag: activemq-6.1.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 Artemis 2.32.0

[Robbie Gemmell]

On Wed, 24 Jan 2024 at 21:30, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.32.0 release.
>
>
> I would like to highlight the following for this release:
>
>
> * Mirrored Core Messages can now be sent in their native format
> without conversions
> * Mirror has been extensively tested and improved in stability
> * ActiveMQ Artemis has now adopted more inclusive language definitions.
> * The examples are now part of its own repository:
> https://github.com/apache/activemq-artemis-examples/
>
>
> And bug fixes and other improvements as usually. for the full JIRA
> report refer to:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12353769
>
>
>
> Ths git commit report is here:
> https://activemq.apache.org/components/artemis/download/commit-report-2.32.0
>
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.32.0
>
> The Maven staging repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1384
>
>
>
> If you would like to validate the release:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases
>
>
>
>
> It is tagged in the git repo as 2.32.0
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)

+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked for LICENCE and NOTICE files in the archives.
- Checked licence headers in the source archive by running:
  "mvn apache-rat:check"
- Ran the Qpid JMS 2.5.0 HelloWorld against a broker from the binary
archive on JDK 11.
- Ran the source build and the AMQP integration tests on JDK 11 with:
  "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
-Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
test"
- Ran the examples repo CI jobs with modification to use the staged
2.32.0 maven bits.

Robbie

Re: Question about AMQP protocol implementation in Artemis

[Robbie Gemmell]

Please use the users list for such questions going forward.

The mailing lists strip almost every attachment/insertion, so your images
have not made it.

Artemis treats 'mutlicast' addresses+queues as being like topic
subscriptions, and in these cases when it creates the
subscription-backing-queue it adds the filter between the address and the
queue to stop any non-matching messages accumulating. In JMS for example,
changing the filter on such an existing named topic subscription is
explicitly required to be treated the same as destroying the prior
subscription and creating a new one with the new filter, which in this case
occurs server-side and is presumably what you are seeing in action, and
perhaps referenced in the image I cant see.

The AMQP 1.0 protocol does not cover the behaviour of changing a selector
filter on such a 'topic subscription backing-queue' because it doesnt
really cover 'topic' subscription handling either to begin with, instead
more P2P message delivery between 'nodes' with largely out-of-band
behaviour. The selector filter itself isnt defined by the protocol spec
either.

I'm dont know if the filter can be administratively changed on an existing
sub-backing like queue or not...perhaps more likely for queues that are
explicitly config-defined, but again not sure for that case either.

If you want a given existing queue to facilitate different filters either
at the same time or over time, and still retain prior messages that may not
match, and update the filter from the client alone, you might need to use
an 'anycast' queue where the filtering always only happens on the consumer
itself (and not between the address and the queue), and different consumers
can then have different filters either at the same time or over time.

If you are using auto-creation then the broker defaults to 'multicast' if
not told otherwise somehow, but you can govern the behaviour either via the
address settings config in broker.xml etc, or you can request particular
treatment via clients, e.g in this case by adding a "queue" (anycast) or
"topic" (multicast) source capability when establishing the consumer link
(or similarly as target capability for a producer link). E.g see
https://github.com/amqphub/equipage/blob/main/amqpnetlite/AutoCreate/QueueReceive/QueueReceive.cs#L55-L58
for that

You might additionally or alternatively find some use for the FQQN syntax
where you can specify both the address and queue names together in a
formatted way, and which can be used to override certain routing behaviour
treatment in some cases (though I think in that case it could also just
refuse a new/updated consumers attempts on a FQQN multicast queue due to a
filter mismatch..I forget now, theres a lot of different behaviours
involved here and they have changed over time):
https://activemq.apache.org/components/artemis/documentation/latest/address-model.html#fully-qualified-queue-names

On Wed, 10 Jan 2024 at 13:24, rusu ionut 
wrote:

> Hello everyone,
>
> I am using ActiveMQ Artemis 2.31.2 and Amqpnetlite library in .NET.
> I want to simulate a publish-subscribe scenario where I have an address as
> a topic, and then multiple queues connected to that address. Each queue
> will have a filter that checks the message's subject (JMSType). This way I
> can have the same behaviour as RabbitMQ (topic edge/publish-subscribe).
> Everything works as expected when I create addresses and queues using the
> Amqpnetlite library, the only thing that I need and it doesn't work, is to
> change the filter for a queue after it was created. I tried to send a
> Source with an addres of an existing queue and the value of the filter
> modified, but this resulted in the queue to be deleted and recreated with
> the new filter. This means that all the messages will be lost and will only
> work if the queue has no consumer.
>
> The Artemis implementation:
>
> [image: Imagine în linie]
>
> The AMQP protocol states that the properties of a terminus should be
> updated if they don't match the one sent by the client:
>
> [image: Imagine în linie]
> Is this a bug or it was intended to have this behavior and not follow the
> AMQP protocol? Can it be changed in a way that the filter is updated
> without deleting the queue?
>
> Best regards
>
>

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

[Robbie Gemmell]

I created the new examples repo earlier today:
https://github.com/apache/activemq-artemis-examples

I also raised a PR for the main artemis repo to remove the examples
there and update things to reflect using the new repo:
https://github.com/apache/activemq-artemis/pull/4711

On Tue, 12 Dec 2023 at 17:59, Robbie Gemmell  wrote:
>
> I've been doing some playing on this over time since raising the idea
> for discussion, trying out some stuff out on my github repos/fork and
> seeing how things could work. I think things are now in a state where
> further work could instead continue in such a new
> activemq-artemis-examples repo. I'll look to create that soon.
>
> https://github.com/gemmellr/activemq-artemis-examples has some initial
> work on a standalone examples build, with CI job for handling release
> + dev artemis versions on respective branches, and inputs to trigger
> manual CI runs on the development branch with any specified artemis
> repo+branch (e.g for testing your changes from your respective
> examples + artemis repo forks). The main branch is set up for the
> current 2.31.2 release, with the development branch set up for
> 2.32.0-SNAPSHOT and already incorporating the couple of actual
> examples changes made in the artemis repo since 2.31.2 was released.
>
> https://github.com/gemmellr/activemq-artemis/tree/examples-independent
> is a branch on my fork that has some changes on removing the examples
> from the main artemis repo, and updating the existing CI job checks to
> use the new examples repo instead (well, my examples repo playground
> above, currently), or again any specified examples repo+branch on a
> manual triggered run for pre-testing with changes in your respective
> forks.
>
> Robbie
>
> On Thu, 26 Oct 2023 at 15:42, Robbie Gemmell  wrote:
> >
> > The default branch would align to the current release. We could have a
> > separate branch aimed towards the next release for adding new ones as
> > we go, it would be used for CI checks. We could tag older versions if
> > we desired...looking at others, some dont, some do.
> >
> > On Thu, 26 Oct 2023 at 15:25, Justin Bertram  wrote:
> > >
> > > +1
> > >
> > > We'll need to think about how we want to communicate the compatibility of
> > > each example since new examples may be added corresponding to new features
> > > in the broker.
> > >
> > >
> > > Justin
> > >
> > > On Thu, Oct 26, 2023 at 5:21 AM 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
> > > >
> > > >

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

[Robbie Gemmell]

I've been doing some playing on this over time since raising the idea
for discussion, trying out some stuff out on my github repos/fork and
seeing how things could work. I think things are now in a state where
further work could instead continue in such a new
activemq-artemis-examples repo. I'll look to create that soon.

https://github.com/gemmellr/activemq-artemis-examples has some initial
work on a standalone examples build, with CI job for handling release
+ dev artemis versions on respective branches, and inputs to trigger
manual CI runs on the development branch with any specified artemis
repo+branch (e.g for testing your changes from your respective
examples + artemis repo forks). The main branch is set up for the
current 2.31.2 release, with the development branch set up for
2.32.0-SNAPSHOT and already incorporating the couple of actual
examples changes made in the artemis repo since 2.31.2 was released.

https://github.com/gemmellr/activemq-artemis/tree/examples-independent
is a branch on my fork that has some changes on removing the examples
from the main artemis repo, and updating the existing CI job checks to
use the new examples repo instead (well, my examples repo playground
above, currently), or again any specified examples repo+branch on a
manual triggered run for pre-testing with changes in your respective
forks.

Robbie

On Thu, 26 Oct 2023 at 15:42, Robbie Gemmell  wrote:
>
> The default branch would align to the current release. We could have a
> separate branch aimed towards the next release for adding new ones as
> we go, it would be used for CI checks. We could tag older versions if
> we desired...looking at others, some dont, some do.
>
> On Thu, 26 Oct 2023 at 15:25, Justin Bertram  wrote:
> >
> > +1
> >
> > We'll need to think about how we want to communicate the compatibility of
> > each example since new examples may be added corresponding to new features
> > in the broker.
> >
> >
> > Justin
> >
> > On Thu, Oct 26, 2023 at 5:21 AM 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
> > >
> > >

[ANNOUNCE] ActiveMQ Artemis 2.31.2 released

[Robbie Gemmell]

I am pleased to announce the release of ActiveMQ Artemis 2.31.2

Downloads are now available at:
https://activemq.apache.org/components/artemis/download/

For a complete list of updates:
https://activemq.apache.org/components/artemis/download/release-notes-2.31.2

This is a bug fix release.

Thanks to all who helped on this release.

Robbie

Re: [RESULT][VOTE] Release Apache ActiveMQ Artemis 2.31.2

[Robbie Gemmell]

Make that 7 binding +1 votes inc a +1 from Jean-Baptiste Onofré

On Fri, 27 Oct 2023 at 15:07, Robbie Gemmell  wrote:
>
> The vote passed with 6 binding +1 votes.
>
> The following votes were received:
>
> Binding:
> +1 Domenico Francesco Bruscino
> +1 Clebert Suconic
> +1 Robbie Gemmell
> +1 Gary Tully
> +1 Justin Bertram
> +1 Timothy Bish
>
> Thank you to everyone who contributed and took the time to review the
> release candidate and vote.
>
> I will add the files to the dist release repo and release the maven
> staging repo, updating the website once it has had time to sync to the
> CDN and Maven Central.
>
> Robbie

[RESULT][VOTE] Release Apache ActiveMQ Artemis 2.31.2

[Robbie Gemmell]

The vote passed with 6 binding +1 votes.

The following votes were received:

Binding:
+1 Domenico Francesco Bruscino
+1 Clebert Suconic
+1 Robbie Gemmell
+1 Gary Tully
+1 Justin Bertram
+1 Timothy Bish

Thank you to everyone who contributed and took the time to review the
release candidate and vote.

I will add the files to the dist release repo and release the maven
staging repo, updating the website once it has had time to sync to the
CDN and Maven Central.

Robbie

Re: [VOTE] Release Apache ActiveMQ Artemis 2.31.2

[Robbie Gemmell]

On Fri, 27 Oct 2023 at 12:16, Robbie Gemmell  wrote:
>
> Hi folks,
>
> I would like to propose an Apache ActiveMQ Artemis 2.31.2 release.
>
> This addresses a defect introduced in the recent 2.31.1 release.
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12353776
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.31.2/
>
> The Maven staging repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1379
>
> If you would like to validate the release:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases
>
> It is tagged in the git repo as 2.31.2.
>
> Robbie

+1

I checked things over as follows:
- Verified the signature + checksum files.
- Checked for LICENCE + NOTICE files in the archives.
- Checked licence headers in the source archive by running:
  "mvn apache-rat:check"
- Ran the Qpid JMS 2.5.0 (RC1) HelloWorld against a broker from the
binary archive on JDK 11.
- Ran the source build and the AMQP integration tests on JDK 11 with:
  "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
-Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
test"
- Used some of the staged maven broker artifacts in some external
integration tests.

Robbie

[VOTE] Release Apache ActiveMQ Artemis 2.31.2

[Robbie Gemmell]

Hi folks,

I would like to propose an Apache ActiveMQ Artemis 2.31.2 release.

This addresses a defect introduced in the recent 2.31.1 release.

The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12353776

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.31.2/

The Maven staging repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1379

If you would like to validate the release:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases

It is tagged in the git repo as 2.31.2.

Robbie

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

[Robbie Gemmell]

The default branch would align to the current release. We could have a
separate branch aimed towards the next release for adding new ones as
we go, it would be used for CI checks. We could tag older versions if
we desired...looking at others, some dont, some do.

On Thu, 26 Oct 2023 at 15:25, Justin Bertram  wrote:
>
> +1
>
> We'll need to think about how we want to communicate the compatibility of
> each example since new examples may be added corresponding to new features
> in the broker.
>
>
> Justin
>
> On Thu, Oct 26, 2023 at 5:21 AM 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
> >
> >

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

[Robbie Gemmell]

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

Re: [DISCUSS] Removing ant call from Artemis/DTO

[Robbie Gemmell]

No idea who they are, maybe a close relative, but I also spotted it hehe.

Hadnt sent it yet as I didnt have a chance to dig into it and so wasnt
actually sure it was applicable yet...but it came up when I was
looking for jxc maven stuff (as opposed to the jxc ant stuff we are
using).

On Wed, 25 Oct 2023 at 17:17, Clebert Suconic  wrote:
>
> Just to record what Robbie Gemmel sent me :
> https://github.com/mojohaus/jaxb2-maven-plugin
>
>
> i'm not sure it works yet... just putting it here as a future note.
>
> On Tue, Oct 24, 2023 at 6:03 PM Clebert Suconic
>  wrote:
> >
> > In artemis/DTO, there's an ant call:
> >
> > https://github.com/apache/activemq-artemis/blob/9b56d296a31e1d1274f248b1fae1d50056090725/artemis-dto/pom.xml#L97-L132
> >
> >
> >
> > This ant call is creating some leak with javac somehow.. after I
> > investigated it a bit with maven guys:
> > https://github.com/apache/maven-mvnd/issues/897
> >
> >
> >
> >
> > I would appreciate any help on getting rid of this call.. does anyone
> > know a better way to do this?
> >
> >
> > Thanks
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic

Re: [VOTE] Apache ActiveMQ 5.16.7 release

[Robbie Gemmell]

On Wed, 25 Oct 2023 at 15:35, 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

+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked for LICENCE + NOTICE files present in the archives.
- Checked headers in the source archive with: mvn apache-rat:check
- Ran the source build and the AMQP tests on JDK 8.
- Ran the Qpid JMS 2.4.0 HelloWorld against a broker started from the
tar.gz binary on JDK 8.

Robbie

Re: [VOTE] Apache ActiveMQ 5.17.6 release

[Robbie Gemmell]

On Wed, 25 Oct 2023 at 09:02, 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

+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked for LICENCE + NOTICE files present in the archives.
- Checked headers in the source archive with: mvn apache-rat:check
- Ran the source build and the AMQP tests on JDK 11.
- Ran the Qpid JMS 2.4.0 HelloWorld against a broker started from the
tar.gz binary on JDK 11.

Robbie

Re: [VOTE] Apache ActiveMQ 5.18.3 release

[Robbie Gemmell]

+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked for LICENCE + NOTICE files present in the archives.
- Checked headers in the source archive with: mvn apache-rat:check
- Ran the source build and the AMQP tests on JDK 11.
- Ran the Qpid JMS 2.4.0 HelloWorld against a broker started from the
tar.gz binary on JDK 11.

Robbie

On Wed, 25 Oct 2023 at 06:37, 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: Time to assemble a board report by Tues, Oct 10

[Robbie Gemmell]

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/ 

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

[Robbie Gemmell]

+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked for LICENCE and NOTICE files in the archives.
- Checked licence headers in the source archive by running:
  "mvn apache-rat:check"
- Gave the new CLI shell bits a play with.
- Ran the Qpid JMS 2.4.0 HelloWorld against a broker from the binary
archive on JDK17.
- Ran the source build and the AMQP integration tests on JDK17 with:
  "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
-Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
test"

Robbie

On Fri, 15 Sept 2023 at 20:42, 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: [VOTE] Apache ActiveMQ Artemis 2.31.0

[Robbie Gemmell]

On Fri, 15 Sept 2023 at 01:50, Clebert Suconic
 wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.31.0 release:
>
> 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
>
> * 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
>
>
> --
> Clebert Suconic

+1

I checked things over as follows:
- Verified the signature and checksum files.
- Checked for LICENCE and NOTICE files in the archives.
- Checked licence headers in the source archive by running:
  "mvn apache-rat:check"
- Gave the new cli shell bits a play with.
- Ran the Qpid JMS 2.4.0 HelloWorld against a broker from the binary
archive on JDK17.
- Ran the source build and the AMQP integration tests on JDK17 with:
  "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
-Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
test"

Robbie

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell]

Yep, I dont think anyone ever seriously considered classifiers for
this for reasons like that, only the converted (inc deps) separate
modules like ActiveMQ 5.18.x and Artemis have, or different versions.

On Thu, 14 Sept 2023 at 19:10, David Blevins  wrote:
>
> Agree.  I'll also note that projects that support both namespaces and use a 
> classifier like "-jakarta" are very hard to use if you want the "-jakarta" 
> version.
>
> We did that in TomEE, Johnzon, OpenWebBeans, etc. and the problem is the 
> maven pom is basically unusable to jakarta users.  Those user's had to 
> tediously exclude all the javax dependencies and meticulously add all the 
> right "jakarta" dependencies.
>
> It's not the greatest user experience.  Eventually we started just switching 
> over in source and focused the poms on jakarta dependencies.
>
> -David
>
> > On Sep 14, 2023, at 8:57 AM, 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 diff

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell]

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

[Robbie Gemmell]

yep, no need for a vote (or even really lazy consensus I'd say) given
the discussion thus far

On Thu, 14 Sept 2023 at 15:09, Christopher Shannon
 wrote:
>
> Yeah I think lazy consensus is fine here if no major objections come up and
> we can make the change.
>
> On Thu, Sep 14, 2023 at 8:21 AM Jean-Baptiste Onofré 
> wrote:
>
> > 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 <
> > david.blev...@gmail.com>
> > > > > 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
> > > > > > >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell]

We already have 4 component spaces on the site which has operated like
that for years. I dont think http://activemq.apache.org/activemq is
particularly an improvement or more obvious than whats there now,
personally. The site did used to use /artemis but changed away from
that to the current components arrangement a while ago.

Overall I'd rather spend less time repeating this same URL naming
discussion, so more was spent improving the actual content sitting in
(or still outside) the spaces that have existed for years.

On Tue, 12 Sept 2023 at 14:27, 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é 
> > > >>>  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.
> > > >>>>>>
> > > >>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell]

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

[Robbie Gemmell]

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

[Robbie Gemmell]

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.
> > >

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell]

I think the main thing anyone disagreed with was your proposed Leto
name being an improvement on things as they already were/are. There
was already a dedicated area on the website even then, it just still
doesnt contain much except the download page and a 'table of contents'
documentation page that just links back out to the various 'mess' as
you put it. I dont recall anyone opposing improving things there even
without the proposed name change.

On Tue, 12 Sept 2023 at 10:03, Jean-Baptiste Onofré  wrote:
>
> 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: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell]

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: [DISCUSS] ActiveMQ 6.0.0 revisited

[Robbie Gemmell]

Seems sensible to me.

On Mon, 11 Sept 2023 at 22:15, 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

[Robbie Gemmell]

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  
> > 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.
> >>>
> >>> T

Re: snapshots repo cleanup

[Robbie Gemmell]

This has now been actioned, the snapshots repo was just cleared.

Also, in discussion a useful bit of info to know about the
repository.apache.org Nexus UI came up:
The Snapshots 'group' repository (the first one, in bold, in the
repository list) navigation tree offers the ability to delete
individual artifacts once you have fully expanded them. But..

The distinct Snapshots 'hosted' repository (the second one, further
down the repository list) navigation tree, actually offers the ability
to right click on directories in the tree and delete them rather than
having to expand individual artifact entries within them.

On Fri, 4 Aug 2023 at 10:56, Robbie Gemmell  wrote:
>
> With no objections being raised, I will ask Infra to proceed.
>
> On Mon, 31 Jul 2023 at 17:56, Robbie Gemmell  wrote:
> >
> > Infra have said they would be happier with PMC consensus first for a
> > bulk clear (which I suggested as picking out individual stuff to clear
> > or keep would be a nightmare), so lets go with a lazy consensus poll:
> >
> > Does anyone object to bulk-clearing of the stale contents of the
> > snapshot repo, and having the CI jobs repopulating only fresh stuff?
> >
> > Lets say lazy consensus will be assumed on Friday failing discussion 
> > otherwise.
> >
> > Robbie
> >
> > On Mon, 31 Jul 2023 at 12:05, Robbie Gemmell  
> > wrote:
> > >
> > > Hi folks, just a note that I have raised a JIRA to ask Infra to clear
> > > out the snapshots repo, as I came to realise it is full of a
> > > considerable amount of stale junk, including things that either add
> > > clutter or just actively mislead people. Once cleared the nightly jobs
> > > can then deploy just the stuff currently being worked on.
> > >
> > > https://issues.apache.org/jira/browse/INFRA-24848

Re: snapshots repo cleanup

[Robbie Gemmell]

With no objections being raised, I will ask Infra to proceed.

On Mon, 31 Jul 2023 at 17:56, Robbie Gemmell  wrote:
>
> Infra have said they would be happier with PMC consensus first for a
> bulk clear (which I suggested as picking out individual stuff to clear
> or keep would be a nightmare), so lets go with a lazy consensus poll:
>
> Does anyone object to bulk-clearing of the stale contents of the
> snapshot repo, and having the CI jobs repopulating only fresh stuff?
>
> Lets say lazy consensus will be assumed on Friday failing discussion 
> otherwise.
>
> Robbie
>
> On Mon, 31 Jul 2023 at 12:05, Robbie Gemmell  wrote:
> >
> > Hi folks, just a note that I have raised a JIRA to ask Infra to clear
> > out the snapshots repo, as I came to realise it is full of a
> > considerable amount of stale junk, including things that either add
> > clutter or just actively mislead people. Once cleared the nightly jobs
> > can then deploy just the stuff currently being worked on.
> >
> > https://issues.apache.org/jira/browse/INFRA-24848

Re: Please help -- board report due next week

[Robbie Gemmell]

Noone had added anything yet, it was still just the final report draft
I committed for the April meeting and so only mentioned stuff known up
to then.

I have just written an initial draft for the August (/July) report now
and committed it.
https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt

(changes: 
https://github.com/apache/activemq-website/commit/4795660c1c16346dd37291ed199566f3967bedd3
)

On Fri, 4 Aug 2023 at 05:26, Jean-Baptiste Onofré  wrote:
>
> 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: snapshots repo cleanup

[Robbie Gemmell]

Essentially just that there isnt disagreement about wiping it all
(since it means some ancient stuff will go, and current stuff will be
'missing' for a small time until created again).

Not unreasonable...besides, it's been a mess for several years, a
couple days for gauging consensus doesn't really hurt hehe.

It seems perhaps someone has been cleaning a little already though,
perhaps tweaking the version-was-released cleanup, as some of the
effectively-nothing-there junk within the wider clutter actually seems
to have disappeared already.

On Wed, 2 Aug 2023 at 15:48, Clebert Suconic  wrote:
>
> I’m just saying it should be a no brainer.   Old stuff on snapshot can go.
>
> I’m not sure what consensus infra is asking on the JIRA.
>
> On Tue, Aug 1, 2023 at 10:12 AM Robbie Gemmell 
> wrote:
>
> > Yep, committers can also manually do a deploy.
> >
> > Old snapshots are removed when the 'matching non-snapshot version' is
> > released. Though it does still leave behind some metadata, so the
> > related folders typically still all remain, making it a little harder
> > to see what really is there. There are lots of these in the tree.
> >
> > Things that never actually get released for a variety of reasons
> > currently stick around forever (e.g as the component was never
> > actually released again, or a specific module went away before
> > release, or the version number was changed between initial development
> > and the eventual release, etc etc). There are also a variety of these
> > in the tree as well.
> >
> > On Tue, 1 Aug 2023 at 14:40, Clebert Suconic 
> > wrote:
> > >
> > > +1000
> > >
> > > the snapshot can also be deployed by anyone's laptop from a PMC member.
> > >
> > >
> > >
> > > I thought there was an automatic rule to remove snapshots from ages
> > > ago already. IMO This should be a no brainer on removing anything that
> > > was deployed more than 3 months ago.
> > >
> > >
> > > if we need to wipe it clean and redeploy all current snapshots that
> > > may be a good way to clean it up...
> > >
> > > the best way would be to have a rule removing any component (or
> > > version) that didn't have an upload in more than 3 months.
> > >
> > > On Mon, Jul 31, 2023 at 1:41 PM Robbie Gemmell 
> > wrote:
> > > >
> > > > The jobs set up on Jenkins do it, either as part of an overall build
> > > > job or specifically just for snapshots.
> > > >
> > > > The various branch specific 5.x jobs do it as part of their overall
> > > > process, they are under:
> > > > https://ci-builds.apache.org/job/ActiveMQ/job/ActiveMQ/
> > > >
> > > > For Artemis there is just a specific snapshot deploy job for main at:
> > > >
> > https://ci-builds.apache.org/job/ActiveMQ/job/ActiveMQ-Artemis-SNAPSHOT-Deploy/
> > > >
> > > > On Mon, 31 Jul 2023 at 18:07, Justin Bertram 
> > wrote:
> > > > >
> > > > > I have no objections, but I do have a question. What is pushing those
> > > > > snapshots?
> > > > >
> > > > >
> > > > > Justin
> > > > >
> > > > > On Mon, Jul 31, 2023 at 12:02 PM Robbie Gemmell <
> > robbie.gemm...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Infra have said they would be happier with PMC consensus first for
> > a
> > > > > > bulk clear (which I suggested as picking out individual stuff to
> > clear
> > > > > > or keep would be a nightmare), so lets go with a lazy consensus
> > poll:
> > > > > >
> > > > > > Does anyone object to bulk-clearing of the stale contents of the
> > > > > > snapshot repo, and having the CI jobs repopulating only fresh
> > stuff?
> > > > > >
> > > > > > Lets say lazy consensus will be assumed on Friday failing
> > discussion
> > > > > > otherwise.
> > > > > >
> > > > > > Robbie
> > > > > >
> > > > > > On Mon, 31 Jul 2023 at 12:05, Robbie Gemmell <
> > robbie.gemm...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi folks, just a note that I have raised a JIRA to ask Infra to
> > clear
> > > > > > > out the snapshots repo, as I came to realise it is full of a
> > > > > > > considerable amount of stale junk, including things that either
> > add
> > > > > > > clutter or just actively mislead people. Once cleared the
> > nightly jobs
> > > > > > > can then deploy just the stuff currently being worked on.
> > > > > > >
> > > > > > > https://issues.apache.org/jira/browse/INFRA-24848
> > > > > >
> > > > > >
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> >
> --
> Clebert Suconic

Re: snapshots repo cleanup

[Robbie Gemmell]

Yep, committers can also manually do a deploy.

Old snapshots are removed when the 'matching non-snapshot version' is
released. Though it does still leave behind some metadata, so the
related folders typically still all remain, making it a little harder
to see what really is there. There are lots of these in the tree.

Things that never actually get released for a variety of reasons
currently stick around forever (e.g as the component was never
actually released again, or a specific module went away before
release, or the version number was changed between initial development
and the eventual release, etc etc). There are also a variety of these
in the tree as well.

On Tue, 1 Aug 2023 at 14:40, Clebert Suconic  wrote:
>
> +1000
>
> the snapshot can also be deployed by anyone's laptop from a PMC member.
>
>
>
> I thought there was an automatic rule to remove snapshots from ages
> ago already. IMO This should be a no brainer on removing anything that
> was deployed more than 3 months ago.
>
>
> if we need to wipe it clean and redeploy all current snapshots that
> may be a good way to clean it up...
>
> the best way would be to have a rule removing any component (or
> version) that didn't have an upload in more than 3 months.
>
> On Mon, Jul 31, 2023 at 1:41 PM Robbie Gemmell  
> wrote:
> >
> > The jobs set up on Jenkins do it, either as part of an overall build
> > job or specifically just for snapshots.
> >
> > The various branch specific 5.x jobs do it as part of their overall
> > process, they are under:
> > https://ci-builds.apache.org/job/ActiveMQ/job/ActiveMQ/
> >
> > For Artemis there is just a specific snapshot deploy job for main at:
> > https://ci-builds.apache.org/job/ActiveMQ/job/ActiveMQ-Artemis-SNAPSHOT-Deploy/
> >
> > On Mon, 31 Jul 2023 at 18:07, Justin Bertram  wrote:
> > >
> > > I have no objections, but I do have a question. What is pushing those
> > > snapshots?
> > >
> > >
> > > Justin
> > >
> > > On Mon, Jul 31, 2023 at 12:02 PM Robbie Gemmell 
> > > wrote:
> > >
> > > > Infra have said they would be happier with PMC consensus first for a
> > > > bulk clear (which I suggested as picking out individual stuff to clear
> > > > or keep would be a nightmare), so lets go with a lazy consensus poll:
> > > >
> > > > Does anyone object to bulk-clearing of the stale contents of the
> > > > snapshot repo, and having the CI jobs repopulating only fresh stuff?
> > > >
> > > > Lets say lazy consensus will be assumed on Friday failing discussion
> > > > otherwise.
> > > >
> > > > Robbie
> > > >
> > > > On Mon, 31 Jul 2023 at 12:05, Robbie Gemmell 
> > > > wrote:
> > > > >
> > > > > Hi folks, just a note that I have raised a JIRA to ask Infra to clear
> > > > > out the snapshots repo, as I came to realise it is full of a
> > > > > considerable amount of stale junk, including things that either add
> > > > > clutter or just actively mislead people. Once cleared the nightly jobs
> > > > > can then deploy just the stuff currently being worked on.
> > > > >
> > > > > https://issues.apache.org/jira/browse/INFRA-24848
> > > >
> > > >
>
>
>
> --
> Clebert Suconic

Re: snapshots repo cleanup

[Robbie Gemmell]

The jobs set up on Jenkins do it, either as part of an overall build
job or specifically just for snapshots.

The various branch specific 5.x jobs do it as part of their overall
process, they are under:
https://ci-builds.apache.org/job/ActiveMQ/job/ActiveMQ/

For Artemis there is just a specific snapshot deploy job for main at:
https://ci-builds.apache.org/job/ActiveMQ/job/ActiveMQ-Artemis-SNAPSHOT-Deploy/

On Mon, 31 Jul 2023 at 18:07, Justin Bertram  wrote:
>
> I have no objections, but I do have a question. What is pushing those
> snapshots?
>
>
> Justin
>
> On Mon, Jul 31, 2023 at 12:02 PM Robbie Gemmell 
> wrote:
>
> > Infra have said they would be happier with PMC consensus first for a
> > bulk clear (which I suggested as picking out individual stuff to clear
> > or keep would be a nightmare), so lets go with a lazy consensus poll:
> >
> > Does anyone object to bulk-clearing of the stale contents of the
> > snapshot repo, and having the CI jobs repopulating only fresh stuff?
> >
> > Lets say lazy consensus will be assumed on Friday failing discussion
> > otherwise.
> >
> > Robbie
> >
> > On Mon, 31 Jul 2023 at 12:05, Robbie Gemmell 
> > wrote:
> > >
> > > Hi folks, just a note that I have raised a JIRA to ask Infra to clear
> > > out the snapshots repo, as I came to realise it is full of a
> > > considerable amount of stale junk, including things that either add
> > > clutter or just actively mislead people. Once cleared the nightly jobs
> > > can then deploy just the stuff currently being worked on.
> > >
> > > https://issues.apache.org/jira/browse/INFRA-24848
> >
> >

Re: snapshots repo cleanup

[Robbie Gemmell]

Infra have said they would be happier with PMC consensus first for a
bulk clear (which I suggested as picking out individual stuff to clear
or keep would be a nightmare), so lets go with a lazy consensus poll:

Does anyone object to bulk-clearing of the stale contents of the
snapshot repo, and having the CI jobs repopulating only fresh stuff?

Lets say lazy consensus will be assumed on Friday failing discussion otherwise.

Robbie

On Mon, 31 Jul 2023 at 12:05, Robbie Gemmell  wrote:
>
> Hi folks, just a note that I have raised a JIRA to ask Infra to clear
> out the snapshots repo, as I came to realise it is full of a
> considerable amount of stale junk, including things that either add
> clutter or just actively mislead people. Once cleared the nightly jobs
> can then deploy just the stuff currently being worked on.
>
> https://issues.apache.org/jira/browse/INFRA-24848

snapshots repo cleanup

[Robbie Gemmell]

Hi folks, just a note that I have raised a JIRA to ask Infra to clear
out the snapshots repo, as I came to realise it is full of a
considerable amount of stale junk, including things that either add
clutter or just actively mislead people. Once cleared the nightly jobs
can then deploy just the stuff currently being worked on.

https://issues.apache.org/jira/browse/INFRA-24848

Re: [VOTE] Apache ActiveMQ Artemis 2.30.0

[Robbie Gemmell]

On Fri, 21 Jul 2023 at 14:55, 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

+1

I checked things over as follows:
- Verified the signature + checksum files.
- Checked for LICENCE + NOTICE files in the archives.
- Checked licence headers in the source archive by running:
  "mvn apache-rat:check"
- Ran the Qpid JMS 2.4.0 HelloWorld against a broker from the binary archive.
- Ran the source build and the AMQP integration tests on JDK 11 with:
  "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
-Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
test"

Robbie

Re: Jakarta Messaging TCK setup

[Robbie Gemmell]

I dont have access to the old area either.

I also think that given the likely age of it, I wouldn't really be
bothered about whatever might be in there. Starting with the more
recent Jakarta Messaging TCK public download should not be hard. The
Jakarta Messaging TCK is linked from
https://jakarta.ee/specifications/messaging/3.1/ (or earlier
versions).

I'd guess there is still an amount of work to do before 5.x could pass
the Jakarta Messaging TCK though given it doesnt do various JMS 2.0
additions yet like shared subs, async send, delivery delay, receive
body...though perhaps addressing that is why Matt is looking to set it
up now.

On Wed, 12 Jul 2023 at 17:24, Justin Bertram  wrote:
>
> Would the contents of that repository (assuming a TCK is set up there) not
> be out of date at this point? It seems like we could just grab the relevant
> TCK [1] from Eclipse and create a new repo with it. What's the benefit of
> inspecting or using the old repo?
>
>
> Justin
>
> [1] https://download.eclipse.org/ee4j/jakartaee-tck/
>
> On Wed, Jul 12, 2023 at 8:47 AM David Blevins 
> wrote:
>
> > Hey All,
> >
> > Matt and I were talking on the Jakarta lists about getting the Jakarta
> > Messaging TCK setup for ActiveMQ Classic.
> >
> > I know there was a TCK setup at some point as I’ve sat next to Hiram while
> > he ran it way back in the day.  I don’t recall if he was running the
> > Geronimo TCK setup, however, or if he had managed to get a setup with just
> > plain ActiveMQ.
> >
> > If there was a TCK setup, it would probably be here:
> >
> >  - svn list https://svn.apache.org/repos/tck/activemq-tck
> >
> > Even if you are a committer, you would not have access unless you were
> > around in the 2004-2010 timeframe and agreed to be confidential with the
> > TCK materials and results.
> >
> > If there are any folks around from back then, can you quickly check to see
> > if something is there?
> >
> > If so, we will now be able to safely make that repo public and convert it
> > to git.
> >
> >
> > -David
> >
> >

Re: NMS micro-site

[Robbie Gemmell]

There is an NMS component area already,
https://activemq.apache.org/components/nms/, the discussion is more
about the lacking contents of docs area in it and how to [re]populate
it.

On Thu, 11 May 2023 at 17:58, Jean-Baptiste Onofré  wrote:
>
> 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: NMS micro-site

[Robbie Gemmell]

To be clearer, the displayed Artemis docs are published on the
ActiveMQ site along with all the other content on the site, with HTML
output generated from source in the artemis repo upon updating the
site for a given release. The various docs simply get shown in an
iframe to maintain the overall site look with the nav etc when
viewing, since e.g the main 'user manual' docs for each version is
generated from a honkit/gitbook 'book' and the HTML emitted thus lacks
the overall site nav etc. Much the same as e.g javadoc content also
does generally, which is similarly iframed (all the artemis docs are,
since the iframe is at
https://activemq.apache.org/components/artemis/documentation/). They
could just simply skip the iframe and blend in less with the overall
site nav, as e.g the 5.x javadocs just do. Personally I dislike the
iframe itself, though not enough to have ever suggested dropping it,
or doing anything else about it like seeing if the honkit/gitbook
generation could be updated to actually spit out pages with the nav
etc already in place.

It sounds like you are proposing something a little different in this
case, actually hosting the NMS docs separately, re: note of using
GitHub Pages? If so that doesn't actually seem that great to me in
terms of not keeping the published site content together in one place
and thus not being able to see changes to it as a whole, or folks
generally being able to update the site or get the complete build as
easily. Though I think it's probably allowed so long as it is e.g.
GitHub Pages being used, and that the source is all still in an ASF
git/svn repo (I believe that much is policy). Though I dont
immediately see how that would work for only a subset of the site
without also e.g a subdomain or something.

On Thu, 11 May 2023 at 11:05, 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: ASF board report due in two days!

[Robbie Gemmell]

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

[Robbie Gemmell]

I dont really understand what your table of combinations entries say,
and so why Option 1 would be to support "3 (or more)" LTS branches but
the other only 2, so its hard to reply specifically around that.

Adding -javax modules on a new branch thats primary-jakarta just
doesnt really make sense to me if still supporting an older version
that is actually primary-javax. There may be something obvious I'm
missing, but it seems more likely the people who are not updating APIs
also wont typically want to change all their dependencies in order to
not-update their usage. Theyll just use the older still-supported
primary-javax version. Same way they often use absolutely ancient
versions now already.

Adding -javax modules to a primary-jakarta version might make sense to
me as a final fallback when otherwise dropping support for all
primary-javax versions, when at that point either the user would have
to either update the API they use or have to rework their dependencies
in order to not update the API. Personally I think it would be simpler
just supporting an existing primary-javax version (or even make a
newer one), or to decide you have actually finally dropped javax
support.

It would seem easy enough to continue targeting JDK 11 on a new branch
with the client at least, even if needing 17 for the broker, if
wanting to support Jakarta client-only users on JDK11 but taking the
rest up to 17 to bring in Spring 6 ?

On Wed, 5 Apr 2023 at 15:57, Matt Pavlovich  wrote:
>
> I agree w/ Chris. I don’t think there is harm in keeping a -jakarta client 
> module in 5.18.x. It provides runway for users that lag on JDK adoption and 
> are not using Spring 6.
>
> A couple of technical notes to keep in mind about JDK-Spring-Jakarta coupling 
> *specific* to ActiveMQ 5:
>
> 1. Spring 6 support is needed to address user demand for Spring Boot Starter
> 2. The *-web modules _require_ JDK 17 due to spring-web dependency
> 3. *-web modules drag a JDK 17 runtime requirement for the Apache runtime 
> distribution
> 4. All the other modules can be compiled JDK 11 for users with custom 
> assemblies
>
>
> Based on my previous repackaging and the inflight Jakarta PR work, I think 
> back porting patches b/w Jakarta and non-Jakarta isn’t going to require too 
> much heavy lifting.
>
> a.  javax vs jakarta change is isolated to import lines, which should rarely 
> be in the patch diffs
> b.  *-web modules don’t change frequently
> c.  jetty-continuation (discontinued) to jakarta.servlet async is the biggest 
> _coding_ change required, and we could do that in a javax-based LTS tree as 
> well
>
>
> Based on the above:
>
> i. I don’t see a huge win with for Jakarta broker without Spring 6 (since we 
> require spring-web) we’d have jakarta for some modules and javax for Servlet
> Ii. Providing *-javax 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 
> >  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 

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

[Robbie Gemmell]

I had assumed you would use Spring 6 on the Jakarta branch, though
still targeting 11 with the client etc, but requiring 17 for build and
using those modules with spring 6 requirement (im not clear which bits
those are...but sounds like its more widespread than I thought it
was).

On Wed, 5 Apr 2023 at 15:21, 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
> > > >
> > > > Agree, it was basically my proposal in a previous email: I would not
> > > > use different artifacts, just change to the major version (5.19.x). If
> > > > people still want to use javax.jms, then he can use 5.18.x (that we
> > > > can "flag" as LTS).
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On Mon, Apr 3, 2023 at 10:20 PM Christopher Shannon
> > > >  wrote:
> > > > >
> > > > > Based on what Robbie is saying we wouldn't have any new modules at
> > all. I
> > > > > would just be different versions, one version is javax and one is
> > jakarta
> > > > > which is what Qpid JMS did. (Jakarta is 2.x and javax is 1.x)
> > > > >
> > > > > On Mon, Apr 3, 2023 at 1:32 PM Matt Pavlovich 
> > > &g

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

[Robbie Gemmell]

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
> >
> > Agree, it was basically my proposal in a previous email: I would not
> > use different artifacts, just change to the major version (5.19.x). If
> > people still want to use javax.jms, then he can use 5.18.x (that we
> > can "flag" as LTS).
> >
> > Regards
> > JB
> >
> > On Mon, Apr 3, 2023 at 10:20 PM Christopher Shannon
> >  wrote:
> > >
> > > Based on what Robbie is saying we wouldn't have any new modules at all. I
> > > would just be different versions, one version is javax and one is jakarta
> > > which is what Qpid JMS did. (Jakarta is 2.x and javax is 1.x)
> > >
> > > On Mon, Apr 3, 2023 at 1:32 PM Matt Pavlovich 
> > wrote:
> > >
> > > > Yeah, I agree w/ Robbie. I think this makes the most sense considering
> > > > Jakarta namespace will be default going forward for all new apps.
> > > >
> > > > When migrating existing apps, it’ll most likely be all javax deps to
> > > > jakarta, so that makes for a nice clean version-number-only change.
> > > >
> > > > For example, 'spring-web’ v6 w/ Jakarta artifactId is still just
> > > > ’spring-web’.
> > > >
> > > > Thanks,
> > > > Matt Pavlovich
> > > >
> > > > > On Apr 3, 2023, at 11:53 AM, Robbie Gemmell <
> > robbie.gemm...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Though that was over 2 years ago, and at the time having the separate
> > > > > -jakarta modules was probably the most obvious way to go given very
> > > > > few were likely going to actually use those new modules at the time,
> > > > > with the prior/existing stuff clearly still being the focus for
> > almost
> > > > > everyone, and thus making it harder to justify alternatives like e.g
> > > > > maintaining separate branches for both spec impls back then. Now,
> > > > > usage will probably be a fair bit more bifurcated from newer
> > framework
> > > > > versions having updated to the new specs and various users either
> > > > > updating to use them or else just using them for any new dev stuff,
> > > > > but still many users that dont update their stuff.
> > > > >
> > > > > More recently, I'd say most projects I see making similar transitions
> > > > > are using their existing modules for the new specs just with a new
> > > > > version, and if they want to support the old specs then doing so by
> > > > > maintaining a previous version stream, having each stream be targeted
> > > > > to one spec and 'fully tested'. That is what I chose to do for
> > > > > qpid-jms last year, and what I would currently choose if deciding
> > > &

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

[Robbie Gemmell]

Though that was over 2 years ago, and at the time having the separate
-jakarta modules was probably the most obvious way to go given very
few were likely going to actually use those new modules at the time,
with the prior/existing stuff clearly still being the focus for almost
everyone, and thus making it harder to justify alternatives like e.g
maintaining separate branches for both spec impls back then. Now,
usage will probably be a fair bit more bifurcated from newer framework
versions having updated to the new specs and various users either
updating to use them or else just using them for any new dev stuff,
but still many users that dont update their stuff.

More recently, I'd say most projects I see making similar transitions
are using their existing modules for the new specs just with a new
version, and if they want to support the old specs then doing so by
maintaining a previous version stream, having each stream be targeted
to one spec and 'fully tested'. That is what I chose to do for
qpid-jms last year, and what I would currently choose if deciding
again just now.

On Mon, 3 Apr 2023 at 15:04, Justin Bertram  wrote:
>
> For what it's worth Artemis created new coordinates for the Jakarta modules
> and left the existing ones the same. Folks who are migrating are actually
> touching their applications in most (if not all) circumstances. It makes
> sense to require them to change the GAV.
>
> In my opinion folks who just want to upgrade their existing (i.e. javax)
> systems shouldn't have to change anything but the version number.
>
>
> Justin
>
> On Mon, Apr 3, 2023 at 6:20 AM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > Matt,
> >
> > My main concern with that is with new -javax modules everyone has to change
> > to new GAV and then they have to change GAV again if we drop the javax.
> >
> > But this might just be the way it is and users will have to make changes to
> > their build that is more than just a version change.
> >
> > On Fri, Mar 31, 2023 at 2:17 PM Matt Pavlovich  wrote:
> >
> > > Hi Christopher-
> > >
> > > After taking yesterday to get most of the way through the jakarta
> > > conversion, I think we can go without the version gap.
> > >
> > > I think option #1 gives us the best approach. After a period of time we
> > > can just ‘drop’ the javax modules and not have to cause users to change
> > > anything else back to have clean GAV coordinates.
> > >
> > > Thanks,
> > > Matt Pavlovich
> > >
> > > > On Mar 30, 2023, at 3:49 PM, Christopher Shannon <
> > > christopher.l.shan...@gmail.com> wrote:
> > > >
> > > > 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
> 

Re: [VOTE] Apache ActiveMQ 5.17.4 release

[Robbie Gemmell]

+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked for LICENCE + NOTICE files present in the archives.
- Checked headers in the source archive with: mvn apache-rat:check
- Ran the source build and the AMQP tests on JDK 11.
- Ran the Qpid JMS 2.2.0 HelloWorld, against a broker started from the
tar.gz binary on JDK 11.

Robbie

On Wed, 22 Feb 2023 at 08:07, 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

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

[Robbie Gemmell]

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

Re: [VOTE] Apache ActiveMQ 5.16.6 release

[Robbie Gemmell]

I'll start by saying I dont think this vote should have been opened,
especially not without prior discussion as was done, given that 5.16.5
was already announced as the final intended 5.16.x over 9 months ago,
noted as such on the website this entire time, and has been left in
that state since even despite various security related dep updates
being made to 5.17.x in the period. Doing this now after that time
rather muddies the waters on that previous notice and also future such
notices.

I would also expect a 5.17.4 to be coming, with recent stuff included
in this already-announced-done 5.16.x stream release that has weirdly
not actually been released in the newer more active 5.17.x stream yet.
That shouldnt happen and itself only further muddies the waters of
direction to upgrade given long ago.

As I expect someone else would come along and +1 this eventually, I
did check it over myself and having done so will add the needed push
myself, this time...though typing this reply and realising the above
did make me really consider voting against it instead of my original
intent.


+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked for LICENCE + NOTICE files present in the archives.
 -- The notice date is stale as already noted by Chris, and fixed on
main+5.17.x.
- Checked headers in the source archive with: mvn apache-rat:check
- Ran the source build and the AMQP tests on JDK 8.
- Ran the Qpid JMS 2.2.0 HelloWorld, against a broker started from the
tar.gz binary on JDK 8.

Robbie

On Wed, 15 Feb 2023 at 05:37, Jean-Baptiste Onofré  wrote:
>
> Gentle reminder: we would need an additional binding vote to get 5.16.6 pass.
>
> Thanks
> 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

Re: [VOTE] Apache ActiveMQ Artemis 2.28.0

[Robbie Gemmell]

On Tue, 31 Jan 2023 at 15:19, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.28.0 release.
>
> I would like to highlight the following changes in this release:
>
> - Page counting improved. We no longer store counters in the journal
> simply relying on paging itself for that
> - We implemented a way to sync mirror from AMQP Broker Connections
>
> For a complete release notes:
> https://activemq.apache.org/components/artemis/download/release-notes-2.28.0
>
> The git commit 
> report:https://activemq.apache.org/components/artemis/download/commit-report-2.28.0
>
>
> Source and binary staged distributions:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.28.0
>
> The maven repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1268
>
> 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 current release candidate is tagged on the git repository as 2.28.0
>
> I will update the website after the vote has passed
>
> [ ] +1 approve this release
> [ ] -1 disapprove (and why)
> [ ] +0 no opinion (I would appreciate a reason why if this is your
> choice as well)

+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked for LICENCE and NOTICE files in the archives.
- Checked licence headers in the source archive by running:
  "mvn apache-rat:check"
- Ran the Qpid JMS 2.2.0 HelloWorld against a broker from the binary archive.
- Ran the source build and the AMQP integration tests on JDK 11 with:
  "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
-Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
test"

Robbie

Re: ASF Board Report

[Robbie Gemmell]

Yep, that is exactly what the file was added for and used to prepare
the previous board report draft, following previous discussions about
doing so. Its the one I was enquiring whether to delete or not earlier
in the thread.

On Tue, 24 Jan 2023 at 18:26, Bruce Snyder  wrote:
>
> There is a file at the following URL named DRAFT-ActiveMQ-board-report.txt,
> can we use this for gathering contributions to the board report?
>
> https://github.com/apache/activemq-website/tree/main/src/team/reports
>
> If not this file, please provide a suggestion.
>
> Bruce
>
> On Wed, Jan 18, 2023 at 12:57 PM Justin Bertram  wrote:
>
> > There's an ASF tool where you can add the release information [1] and that
> > information is then available to Bruce and he just copies and pastes it
> > into the report before he submits it. So the release process should include
> > using this tool.
> >
> >
> > Justin
> >
> > [1] https://reporter.apache.org/addrelease.html?activemq
> >
> > On Wed, Jan 18, 2023 at 11:15 AM Clebert Suconic <
> > clebert.suco...@gmail.com>
> > wrote:
> >
> > > fine... we could start filling the draft as releases are done, as part
> > > of the release procedure?
> > >
> > > On Wed, Jan 18, 2023 at 10:39 AM Bruce Snyder 
> > > wrote:
> > > >
> > > > I would rather employ the prepare-draft-in-site-git-repo approach
> > because
> > > > it will result in a report format already prepared that can be
> > > copy/pasted
> > > > directly to Whimsy. I did not take steps to implement this approach as
> > > > there were some strong opinions about it previously. If we'd like to
> > > > utilize this approach, I'm all for it.
> > > >
> > > > Releases are already noted somewhere so they appear in the Whimsy stats
> > > > already.
> > > >
> > > > Bruce
> > > >
> > > > On Wed, Jan 18, 2023 at 9:21 AM Clebert Suconic <
> > > clebert.suco...@gmail.com>
> > > > wrote:
> > > >
> > > > > Perhaps we should include a step in our release procedure to update
> > > some
> > > > > document on every release we make?   Like quarter releases on our
> > > website
> > > > > so it’s always ready. (Which is most of what we do for the report )
> > > > >
> > > > > On Wed, Jan 18, 2023 at 4:58 AM Robbie Gemmell <
> > > robbie.gemm...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Are we dropping the prepare-draft-in-site-git-repo approach
> > > previously
> > > > > > discussed and put in place then used for the last report, and
> > > > > > switching entirely to email?
> > > > > >
> > > > > > I dont really mind which approach is used, as I said personally I
> > > just
> > > > > > use email elsewhere, but asking to know whether to delete the stale
> > > > > > file.
> > > > > >
> > > > > > Robbie
> > > > > >
> > > > > > On Wed, 18 Jan 2023 at 05:11, Bruce Snyder  > >
> > > > > wrote:
> > > > > > >
> > > > > > > Please consider this message a call for contribution to the next
> > > board
> > > > > > > report!
> > > > > > >
> > > > > > > Kindly reply to this conversation with your contributions.
> > > > > > >
> > > > > > > Bruce
> > > > > > >
> > > > > > > On Tue, Jan 17, 2023 at 10:37 PM Jean-Baptiste Onofré <
> > > j...@nanthrax.net
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Bruce,
> > > > > > > >
> > > > > > > > I think replying to a "call for report" email is OK.
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > JB
> > > > > > > >
> > > > > > > > On Tue, Jan 17, 2023 at 5:27 PM Bruce Snyder <
> > > bruce.sny...@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > I just realized that we were notified about our board report
> > > too
> > > > > > late to
> > > > > > > > > even submit the report as the meeting is scheduled to take
> > > place
> > > > > > > > tomorrow.
> > > > > > > > > So, let's plan on submitting it for next month's ASF board
> > > meeting.
> > > > > > > > >
> > > > > > > > > How do we want to go about gathering the board report
> > > contributions
> > > > > > for
> > > > > > > > > this and future reports? GitHub? Responses to this message?
> > > > > > > > >
> > > > > > > > > Bruce
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > perl -e 'print
> > > > > > > > >
> > > > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > > > > > );'
> > > > > > > > > http://bsnyder.org/ <http://bruceblog.org/>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > perl -e 'print
> > > > > > >
> > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > > > > );'
> > > > > > > http://bsnyder.org/ <http://bruceblog.org/>
> > > > > >
> > > > > --
> > > > > Clebert Suconic
> > > > >
> > > >
> > > >
> > > > --
> > > > perl -e 'print
> > > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > );'
> > > > http://bsnyder.org/ <http://bruceblog.org/>
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> > >
> > >
> >
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E http://bsnyder.org/ <http://bruceblog.org/>

Re: ASF Board Report

[Robbie Gemmell]

Are we dropping the prepare-draft-in-site-git-repo approach previously
discussed and put in place then used for the last report, and
switching entirely to email?

I dont really mind which approach is used, as I said personally I just
use email elsewhere, but asking to know whether to delete the stale
file.

Robbie

On Wed, 18 Jan 2023 at 05:11, Bruce Snyder  wrote:
>
> Please consider this message a call for contribution to the next board
> report!
>
> Kindly reply to this conversation with your contributions.
>
> Bruce
>
> On Tue, Jan 17, 2023 at 10:37 PM Jean-Baptiste Onofré 
> wrote:
>
> > Hi Bruce,
> >
> > I think replying to a "call for report" email is OK.
> >
> > Regards
> > JB
> >
> > On Tue, Jan 17, 2023 at 5:27 PM Bruce Snyder 
> > wrote:
> > >
> > > I just realized that we were notified about our board report too late to
> > > even submit the report as the meeting is scheduled to take place
> > tomorrow.
> > > So, let's plan on submitting it for next month's ASF board meeting.
> > >
> > > How do we want to go about gathering the board report contributions for
> > > this and future reports? GitHub? Responses to this message?
> > >
> > > 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: Starting ActiveMQ 5.18.x preparation/update

[Robbie Gemmell]

I should add that one other approach I've seen which is somewhat
combining the approaches is at Quarkus, where they are currently (not
sure if this is intended going forward, after the 3.0 stuff actually
gets released, but is how its being developed for now) using rewrite
tooling thats part of the main (2.x) branch that is used to have
rewrite the build into the jakarta variant intended to become 3.x...so
the build updates everything to the jakarta version, and that output
can then pushed to another branch for release etc.

On Tue, 10 Jan 2023 at 13:17, Robbie Gemmell  wrote:
>
> Artemis currently does the dual-modules thing, with the 'main'
> artifacts are the same JMS 2 based ones that were always there from
> the start, but with additional modules added that take the existing
> source and create new 'jakarta variants', e.g artemis-jakarta-client.
>
> I think that was a sensible approach when Artemis added Jakarta
> Messaging support going on a couple of years ago, but at this point
> I'd probably go with the full switch and have 2 separate branches.
> Thats what I have done elsewhere, and what other projects switching
> now seem to be doing. Less build complexity, better/simpler for
> testing, uses the same old module names, etc...
>
> ...however, also means doing more releases (seems like it would happen
> anyway in this case), and needs backporting if wanting to support
> both, which seems inevitable for quite some time in this particular
> case. That said, for 5.x it also seems pretty much every change
> released is already backported from main to a branch today, so that
> other 'downside' also isnt actually much different than exactly what
> is already being done now (besides maybe the occasional import fixup).
>
> Robbie
>
> On Tue, 10 Jan 2023 at 12:54, Christopher Shannon
>  wrote:
> >
> > If we do have a breaking change and drop JMS jar entirely in 5.19.x then I
> > think we will need to support 5.18.x for a while. Even though old JMS
> > clients would work with 5.19.x (just not in the same JVM) it would be good
> > to support JMS jar still for a while longer.
> >
> > The other option is we do the breaking change in the broker but also have a
> > separate module we still release that supports the old JMS 2.0 spec jar,
> > like Artemis does. This would require more work but might be an option for
> > someone who's code hasn't been upgraded to the new API but wants the latest
> > version.
> >
> > On Tue, Jan 10, 2023 at 7:44 AM Jean-Baptiste Onofré 
> > wrote:
> >
> > > Hi,
> > >
> > > Those are valid points:
> > > 1. For Jakarta, I plan to change the dep and rename on dedicated
> > > branch (5.19.x). The intention is to introduce breaking change here
> > > (as spring or camel did).
> > > 2. Spring 6: you are right for JDK 17 (I forgot this part). Jakarta
> > > namespace depends of the spring module in use.
> > > spring-beans/spring-core doesn't change here. spring-jms, etc yes they
> > > changed. I did the change on the broker first (as it uses
> > > spring-aop/spring-beans/spring-core). But that's correct, better to
> > > postpone to 5.19.x.
> > > 3. I'm doing a full pass on the tests, also reevaluating the profiles.
> > > I will share some details.
> > >
> > > I will update Jira with the releases plan.
> > >
> > > Thanks,
> > > Regards
> > > JB
> > >
> > > On Tue, Jan 10, 2023 at 12:40 PM Christopher Shannon
> > >  wrote:
> > > >
> > > > JB,
> > > >
> > > > I was writing up a response when I saw Robbies and I have the same
> > > > questions.
> > > >
> > > > What is your plan for handling the Jakarta namespace? Are you just using
> > > > Maven to generate another module that's a copy of activemq-client?
> > > >
> > > > Also, you said Spring 6 is not very difficult and could be in 5.18.x but
> > > > doesn't Spring 6 require Jakarta and JDK 17 (as Robbie pointed out)? So
> > > if
> > > > you wanted to include support for that for 5.18.x wouldn't that also
> > > imply
> > > > we have to have the Jakarta changes too? Also, I haven't tested with JDK
> > > 17
> > > > but I assume the broker should be compatible with it at runtime (also
> > > > required for Spring 6). We could also easily add a Jenkins job for JDK 
> > > > 17
> > > > if we haven't already.
> > > >
> > > > Speaking o

Re: Starting ActiveMQ 5.18.x preparation/update

[Robbie Gemmell]

Artemis currently does the dual-modules thing, with the 'main'
artifacts are the same JMS 2 based ones that were always there from
the start, but with additional modules added that take the existing
source and create new 'jakarta variants', e.g artemis-jakarta-client.

I think that was a sensible approach when Artemis added Jakarta
Messaging support going on a couple of years ago, but at this point
I'd probably go with the full switch and have 2 separate branches.
Thats what I have done elsewhere, and what other projects switching
now seem to be doing. Less build complexity, better/simpler for
testing, uses the same old module names, etc...

...however, also means doing more releases (seems like it would happen
anyway in this case), and needs backporting if wanting to support
both, which seems inevitable for quite some time in this particular
case. That said, for 5.x it also seems pretty much every change
released is already backported from main to a branch today, so that
other 'downside' also isnt actually much different than exactly what
is already being done now (besides maybe the occasional import fixup).

Robbie

On Tue, 10 Jan 2023 at 12:54, Christopher Shannon
 wrote:
>
> If we do have a breaking change and drop JMS jar entirely in 5.19.x then I
> think we will need to support 5.18.x for a while. Even though old JMS
> clients would work with 5.19.x (just not in the same JVM) it would be good
> to support JMS jar still for a while longer.
>
> The other option is we do the breaking change in the broker but also have a
> separate module we still release that supports the old JMS 2.0 spec jar,
> like Artemis does. This would require more work but might be an option for
> someone who's code hasn't been upgraded to the new API but wants the latest
> version.
>
> On Tue, Jan 10, 2023 at 7:44 AM Jean-Baptiste Onofré 
> wrote:
>
> > Hi,
> >
> > Those are valid points:
> > 1. For Jakarta, I plan to change the dep and rename on dedicated
> > branch (5.19.x). The intention is to introduce breaking change here
> > (as spring or camel did).
> > 2. Spring 6: you are right for JDK 17 (I forgot this part). Jakarta
> > namespace depends of the spring module in use.
> > spring-beans/spring-core doesn't change here. spring-jms, etc yes they
> > changed. I did the change on the broker first (as it uses
> > spring-aop/spring-beans/spring-core). But that's correct, better to
> > postpone to 5.19.x.
> > 3. I'm doing a full pass on the tests, also reevaluating the profiles.
> > I will share some details.
> >
> > I will update Jira with the releases plan.
> >
> > Thanks,
> > Regards
> > JB
> >
> > On Tue, Jan 10, 2023 at 12:40 PM Christopher Shannon
> >  wrote:
> > >
> > > JB,
> > >
> > > I was writing up a response when I saw Robbies and I have the same
> > > questions.
> > >
> > > What is your plan for handling the Jakarta namespace? Are you just using
> > > Maven to generate another module that's a copy of activemq-client?
> > >
> > > Also, you said Spring 6 is not very difficult and could be in 5.18.x but
> > > doesn't Spring 6 require Jakarta and JDK 17 (as Robbie pointed out)? So
> > if
> > > you wanted to include support for that for 5.18.x wouldn't that also
> > imply
> > > we have to have the Jakarta changes too? Also, I haven't tested with JDK
> > 17
> > > but I assume the broker should be compatible with it at runtime (also
> > > required for Spring 6). We could also easily add a Jenkins job for JDK 17
> > > if we haven't already.
> > >
> > > Speaking of which, it looks like the Jenkins build has had a lot of
> > > failures and has been unhappy with the Advisory tests since back in
> > > November which is odd as it's complaining about JMX (instance already
> > > exists). I just re-kicked off a 5.17.x build so will see if it happens
> > > again but may need to fix something. Running the tests by itself locally
> > > work fine.
> > >
> > > On Tue, Jan 10, 2023 at 6:28 AM Robbie Gemmell  > >
> > > wrote:
> > >
> > > > Would the plan be to have these first 5.18 releases marked as e.g.
> > > > alphas to set people's expectations appropriately around it not yet
> > > > implementing most of JMS 2's new functionality, only some of the new
> > > > 'simplified' API? Or are the PRs going to pick up on completing [more
> > > > of] the impl first?
> > > >
> > > > Doesnt Spring 6 req

Re: Starting ActiveMQ 5.18.x preparation/update

[Robbie Gemmell]

Would the plan be to have these first 5.18 releases marked as e.g.
alphas to set people's expectations appropriately around it not yet
implementing most of JMS 2's new functionality, only some of the new
'simplified' API? Or are the PRs going to pick up on completing [more
of] the impl first?

Doesnt Spring 6 require Java 17, and so anything using it would
similarly? Is the thinking to change the minimum globally, or e.g just
for specific bits using it and then e.g have divergent requirements
for build (17+) and runtime (11+ or 17+ depending on what bits you
use)?

Matt's reply was around having separate release branches/streams for
java.jms and jakarta.jms namespace support. I think that might be
simplest (and potentially also allowing for different JVM handling
between them) at this stage, I'm doing that elsewhere, though there
are certainly also tradeoffs to it vs alternatives. You were proposing
something different here, can you flesh out your original idea for
comparison? Had you implemented something?

On Sun, 8 Jan 2023 at 07:19, Jean-Baptiste Onofré  wrote:
>
> Hi guys,
>
> I started to work on ActiveMQ 5.18.x major release preparation.
>
> Basically, I propose to include (as major changes, in addition of all
> others more "minor" changes :)):
> - JMS 2.x support (mostly client and first part broker)
> - Spring 6 update
> - Jakarta namespace support
>
> I should have the first PRs ready for review very soon.
>
> I would like to propose a first 5.18.0 in Feb.
>
> Thoughts ?
> Regards
> JB

Re: [VOTE] Apache ActiveMQ Artemis 2.27.1 release

[Robbie Gemmell]

On Mon, 28 Nov 2022 at 21:54, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.27.1 release
>
>
> This is a bug fix release,
>
> I would like to highlight these 3 bug fixes:
>
> - AMQP Large Message over Bridges were broken
> - Rollback of massive transactions would take a long time to process
> - Improvements to auto-create and auto-delete queues.
>
> For a full release notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352610&projectId=12315920
>
>
> Ths git commit report is here:
> https://activemq.apache.org/components/artemis/download/commit-report-2.27.1
>
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.27.1/
>
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1266
>
> 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://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.27.1
>
>
> 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)
>
>
>
> --
> Clebert Suconic

+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked for LICENCE and NOTICE files in the archives.
- Checked licence headers in the source archive by running:
  "mvn apache-rat:check"
- Ran the new "artemis upgrade " from the 2.27.1 binary against a
  standard broker instance created using the 2.26.0 binary archive, upgrading
  it to be a 2.27.1 instance instead, started it and ran the Qpid JMS 2.1.0
  HelloWorld example against it.
- Ran the Qpid JMS 2.1.0 HelloWorld against a 2.27.1 broker instance that
  was created using the 2.27.1 binary archive originally.
- Ran the source build and the AMQP integration tests on JDK 11 with:
  "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
-Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
test"

Robbie

Re: JsonUtil.truncate() unexpected behavior

[Robbie Gemmell]

I guess its expected in so far as it was done deliberately:
https://github.com/apache/activemq-artemis/pull/3948


On Wed, 23 Nov 2022 at 13:01, Jan Šmucr  wrote:
>
> Hello.
>
> I’ve been using the Message.toPropertyMap() function and recently I’ve 
> discovered that it does not preserve null values, as they get replaced by an 
> empty string in JsonUtil.truncate(). I understand that it’s not possible to 
> put null values into maps, but on the other hand, they are supported in JSON 
> and there’s quite a difference between null and "". And the toPropertyMap 
> function doc states clearly: “…useful when encoding to JSON”.
>
> Is this an expected behavior? I can work around that, but should I?
>
> Jan
>