If it doesnt actually implement _any_ of it, then personally I dont think that makes sense, as I've said before. It's of no consequence to the people who have already been using a 2.0 api jar with the 1.1 impl for anything up to 9 years now if that suited them, something which is trivial to do, and it also doesnt really give any advantage to the other users who aren't doing that. It would seem largely just misleading (to me anyway) to add it now all on its own. It has waited this long, it seems better it could wait just a little longer until it is actually implemented in a following 5.18.x series, which neednt be far very away at all once it is actually ready.
On Mon, 21 Feb 2022 at 12:58, 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
