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 -
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
vich
> > 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.
> > > >
> > >
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.
&
>
> > 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
> &g
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
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
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"
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
!!
> >>>>
> >>>> [1]
> >>>>
> >>>>
> >> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
> >>>>
> >>>> On Fri
gt;
> >
> > 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:
> > >
s.
> > >
> > >
> > > 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
>
> 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
> > > wrot
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
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
t; 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
> >
.
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 discus
> > > 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 d
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 Gemme
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,
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
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
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
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
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 i
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 coul
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.
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
>
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
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://is
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=12353776
Source and binary distributions
, 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
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,
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
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:
>
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
> -
+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
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,
+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
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
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 dependen
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
ng back many years so I don't think getting rid of "Classic"
> > is
> > > > an
> > > > > > issue
> > > > > > >> or would lead to any confusion since as I said, no one uses it
> > > > > anyways.
> > > > > > >>
> > &g
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
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 Activ
e:
>
> 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 thou
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
t; 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?
&
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
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
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
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
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 ni
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.
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.
> >
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
n, 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 p
, 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,
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
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:
>
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
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
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
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
ould 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 exis
t; 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.
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
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
+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
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.ap
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
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
; >
> > > > 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
> > > >
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
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:
>
> A
s 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
>
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?
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
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
the
serve_subset.sh version to exclude all the javadoc entirely to speed
it up further too. This gets the subset rebuilds down to about 1
second which will make it a lot nicer to work on general site changes.
On Wed, 5 Oct 2022 at 18:45, Robbie Gemmell wrote:
>
> JB, are your thoughts on this more genera
On Wed, 9 Nov 2022 at 02:33, Justin Bertram wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.27.0 release.
>
> New and noteworthy items in 2.27.0:
>
> - Fix for CVE-2022-42889 (Apache Commons Text vulnerability)
> - Logging implementation moved to Apache Log4j 2 (internally using
You can release stuff to Maven Central via Sonatype OSSRH,
https://central.sonatype.org/publish/publish-guide/
For example by using your GitHub Pages details for the groupid
coordinates i.e. io.github.your-id, among other options:
https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
is a common way of filtering resources with maven, and perhaps the
simplest fit in the case as I understand it.
The website module's documentation build also has an example of
substituting stuff in the docs using the
Justin suggested the website repository for hosting a draft file just
since it already exists. We both thought just continuing to link to
the published approved minutes from Whimsy, as the site has for some
time, made more sense than actually publishing them to the ActiveMQ
website again (though
JB, are your thoughts on this more general, i.e also applying to the
5.x 'latest' (typically stale) javadocs on the website as well, rather
than just the per-release Artemis javadocs this thread started about?
If so it would seem to me that all the people who regularly update the
website bits for
That would also be nicer than having them all, though still the same
amount of work on updates. Its what the 5.x docs at least aim to do
(typically out of date).
Another middle ground might be just automating the release details
linking to the zips on maven-central, meaning its still/actually
On Wed, 28 Sept 2022 at 19:12, Étienne Hossack wrote:
>
> -1
>
> Reasons to keep:
> * It's useful to be able to link a specific line/method in the javadoc when
> explaining something to someone through the use of a URL
> * It's nice to be able to navigate the source code in your browser, if say
Personally I read most javadocs in the IDE these days whilst using the
thing in question, with IDEs grabbing it (/the source) from Maven
Central as you say. For more specific things about the actual client
or broker however I tend to link into their source on github these
days. I dont really ever
On Wed, 21 Sept 2022 at 21:24, Clebert Suconic
wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.26.0 release.
>
>
> We removed ActiveMQ Artemis Rest, (which was already non functional)
> as part of this release.
> And other improvements and bug fixes.
>
>
> The release notes can be
On the logging bit, I would note there are numerous cases of 2.x
releases adjusting stuff in ways that similarly needed specific
handling 'during a normal upgrade procedure' per
https://activemq.apache.org/components/artemis/documentation/latest/versions.html.
Even the existing logging bits have
Yep if you want to you could certainly release a 2.26.0 from main
instead of a 2.x branch in the current (essentially identical) state
and create a branch later if/when actually needed.
On Fri, 16 Sept 2022 at 14:35, Clebert Suconic
wrote:
>
> hmmm... this is actually pointless.. (the 2.x branch
It has been several weeks without objection (or reply) to this from
multiple raisings, I'll be looking to do it next week if discussion
doesnt lead otherwise.
On Thu, 8 Sept 2022 at 15:35, Robbie Gemmell wrote:
>
> I'd like to raise again the middle-ground of removing these
> partial
ch in rest from JMS due to the session
> and stateful nature.
>
>
> But if we were to provide REST for our users, I would rather bring the
> servlet from AMQ5. it would be a major task anyway... and this
> module has to go for sure.
>
> On Thu, Sep 8, 2022 at 10:20 AM R
]
https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.html
On Mon, 8 Aug 2022 at 12:00, Robbie Gemmell wrote:
>
> Not shading them makes the likelihood of clashing-dependencies worse,
> i.e that another component being used with it might use (or itself
&g
It has looked to be rotting for a long time, and requires various user
hoop jumping I dont expect many/any folks are interested in doingI
think removing it makes sense.
On Thu, 8 Sept 2022 at 14:54, Clebert Suconic wrote:
>
> I'm not sure if there's much to discuss here. Rest in Artemis has
ment IMHO.
>
> Regards
> JB
>
> On Mon, Sep 5, 2022 at 10:22 AM Robbie Gemmell
> wrote:
> >
> > Reminder that we discussed pointing announcements to the download page
> > rather than the release page.
> >
> > On Sat, 3 Sept 2022 at 07:10, Jean-B
Reminder that we discussed pointing announcements to the download page
rather than the release page.
On Sat, 3 Sept 2022 at 07:10, Jean-Baptiste Onofré wrote:
>
> The ActiveMQ team is pleased to announce Apache ActiveMQ 5.17.2 release:
>
> https://activemq.apache.org/activemq-5017002-release
>
>
I checked in with Infra and they looked into and resolved this. I pushed a
trivial change to prod a new build, and the site has now refreshed.
On Thu, 1 Sept 2022 at 15:46, Robbie Gemmell
wrote:
> Didnt get a reply as yet so I raised
> https://issues.apache.org/jira/browse/INFRA
Didnt get a reply as yet so I raised
https://issues.apache.org/jira/browse/INFRA-23654
On Thu, 1 Sept 2022 at 09:49, Robbie Gemmell
wrote:
> The build failed: https://ci2.apache.org/#/builders/7/builds/1048
>
> As did one for another project around the same time in the same way. Loo
Yes, JB voting twice doesnt actually count double :D
Since changes are in process of being made to resolve and prevent the JDK17
build regression for future releases, and it does still run on 17 which is
enough for many users...even though I would have fixed it first, I'll
change mine to +1 just
1 - 100 of 678 matches
Mail list logo
