On 2/21/22 08:12, Christopher Shannon wrote:
+1 to go with 5.17.0 without JMS 2.0
I think we should just wait for all the JMS 2.0 stuff for 5.18.0. We
shouldn't even include the new dependency as it would be kind of confusing
as it wouldn't implement anything. We can easily document that if someone
wants to use the JMS 2.0 jar it's no problem to use it with excluding the
1.1. and using the new jar (I've been doing this for years) and just not
call the new methods.
+1
5.18.0 doesn't have to take years longer, it can go out whenever we want (1
month, 3 months, etc). So I think just reverting all the JMS 2.0 and
rolling with the other updates makes sense.
On Mon, Feb 21, 2022 at 7:58 AM Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:
Hi guys,
I agree about the change, and it was not what we agreed on the mailing
list.
The initial plan for 5.17.0 about JMS 2.0 is "just" to update the
client side to support JMS 2.0 and throw UnsupportedOperationException
for JMS 2.0 specific method.
I think it's good enough for 5.17.0 to support the first JMS 2.0 round.
More than that (client/broker side) should go in 5.18.0 IMHO.
Regards
JB
On Mon, Feb 21, 2022 at 1:35 PM Robbie Gemmell <robbie.gemm...@gmail.com>
wrote:
Finally doing a 5.17.0 release sounds good.
That said, I dont personally think
https://github.com/apache/activemq/pull/729 is ready for inclusion in
a release though, even with an '-rc1' adorned version number
previously suggested but apparently no longer planned, since even as a
'first phase' it is surprisingly incomplete, adding some of the JMS 2
'simplified API' but not even doing much of the basic JMS 1.1 level
functionality within it, like setting a MessageListener on a
JMSConsumer, or creating a durable subscriber (non-shared), or
JMSContext's acknowledge() method for doing client-ack (presumably the
message method works though), etc.
It also just seems very odd to even think about just *starting* to
including stuff like that on main within a couple days of intending to
do a release thats nearing being *years* in the making, and getting
describe to users as '2-3 weeks' for way over a year now, including
multiple times in the last few months.
For me, the most obvious idea at this point would actually be for
5.17.x to be branched and proceed without this. Theres a load of stuff
in it already that is long overdue like the JDK11 build etc. I would
go so far as to say the prior API jar change from early November
(https://github.com/apache/activemq/pull/682) should also be
effectively reverted, it makes no sense to me on its own. Then all of
this stuff then worked on towards a 5.18.x release that actually
implements and tests things to a reasonable level thats less likely to
see even trivial use cases fail to work.
Robbie
On Mon, 21 Feb 2022 at 04:55, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:
Hi guys,
I worked on the log4j2 update PR this weekend, fixing almost all unit
tests using a custom appender. I just have to fix the
activemq-web-demo test and squash, and the PR will be good to be
merged. I will do that today.
Then, later today and tomorrow I will work on using jetty modules
instead of jetty-all and update to Jetty 9.4.45.
I will do a pass on Jira and PRs, especially the ones from Matt. @Matt
can you please ping me on slack to check together the status of the
PRs ?
Regarding this, I would like to submit 5.17.0 to vote this Thursday if
there are no objections.
Regards
JB
--
Tim Bish
