FWIW it seems like it should be a simple enough revert once the branch
is made. Looks like 3 files (as below) have been changed since the
commit in a way that would need a decision upon revert. I guess those
are likely to be keeping the changes from main. Assuming so, seems
like "git revert 67256c61b -Xours" would work.
Though, perhaps worth looking closer at
activemq-karaf/src/main/resources/features-core.xml to see if the
change there (and related property restored in the module pom file) is
needed, it doesnt immediately seem that related to the api change.
both modified: activemq-client/pom.xml
both modified:
activemq-karaf-itest/src/test/java/org/apache/activemq/karaf/itest/ActiveMQBrokerNdCamelFeatureTest.java
both modified: activemq-karaf/src/main/resources/features-core.xml
On Wed, 23 Feb 2022 at 16:01, Matt Pavlovich <mattr...@gmail.com> wrote:
>
> ok, lets go
>
> > On Feb 23, 2022, at 9:27 AM, Christopher Shannon
> > <christopher.l.shan...@gmail.com> wrote:
> >
> > Matt, the reason to roll back is for what Robbie just said.
> >
> > I know the discussion originally was that the first step of this would be
> > to include the jar with no impl and just UOE. But I've been convinced
> > after all the discussion the past couple weeks on this that there's no real
> > point to doing so now because A) you already get the same behavior with
> > including the jar yourself and B) there will be real client impl changes
> > coming shortly with 5.18.0 it just makes a lot more sense to me to wait and
> > include everything in 5.18.0.
> >
> > On Wed, Feb 23, 2022 at 9:57 AM Robbie Gemmell <robbie.gemm...@gmail.com>
> > wrote:
> >
> >> It really doesnt make sense to include changing the API in 5.17.0
> >> without any impl, it would be very odd to retain to me, and also quite
> >> misleading. It may also unnecessarily inconvenience people that have
> >> previously adapted their builds to other bits including a
> >> likely-different 2.0 API artifact if they needed it and excluding the
> >> 1.1 api, into updating their excludes despite no impl change. It just
> >> makes sense to unwind it.
> >>
> >> On Wed, 23 Feb 2022 at 14:30, Matt Pavlovich <mattr...@gmail.com> wrote:
> >>>
> >>> Hey Chris-
> >>>
> >>> I believe the JMS 2.0 impl is in good shape (fighting one test that
> >> works-locally-fails-on-Apache-CI fun!). Given the desire to get 5.17.0 out
> >> soon, I can get behind allowing more time for others to review and roll
> >> with it in 5.18.0.
> >>>
> >>> How about keeping AMQ-7309 in 5.17.0 and go forward with your suggestion
> >> of moving on to 5.18.0 with JMS 2.0, Jakarta updates, etc? AMQ-7309 is well
> >> reviewed and been merged for 4 months.
> >>>
> >>> Thanks,
> >>> Matt
> >>>
> >>>> On Feb 22, 2022, at 2:10 PM, Christopher Shannon <
> >> christopher.l.shan...@gmail.com> wrote:
> >>>>
> >>>> In terms of maintenance if we get out 2.18, 2.19, etc then 2.17 can
> >> just
> >>>> get important fixes or be made EOL and we can move on. Long lived
> >> branches
> >>>> and support are not necessary if we keep up with more frequent
> >> releases.
> >>>>
> >>>> 2.17.0 is at a logical cut off point where it's at now and I'm
> >> definitely
> >>>> not in favor of adding something brand new (Jakarta changes) last
> >> minute
> >>>> and I doubt others are either.
> >>>>
> >>>> So again..it's time to move on. As everyone else already seems to be in
> >>>> agreement with (JB, Tim, Robbie) let's just do the release this week
> >> with
> >>>> the current changes and then move on to 2.18.0 with JMS 2.0, Jakarta
> >>>> updates, etc.
> >>>>
> >>>>
> >>>> On Tue, Feb 22, 2022 at 2:49 PM Matt Pavlovich <mattr...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Hey All-
> >>>>>
> >>>>> I get the idea that getting a JDK 11-based released is a good thing,
> >> but I
> >>>>> also think we should consider the jakarta alignment as part of what
> >> active
> >>>>> branches are supported. This is the path other projects have taken and
> >>>>> helps users align things when they are assembling pieces for their
> >>>>> environment
> >>>>>
> >>>>> If we go with the proposed plan in this thread-- we add JDK 11, but
> >> do not
> >>>>> move the ball forward on anything jakarta related — we add another
> >> active
> >>>>> branch to maintain. As log4j showed us, having a bunch of active
> >> branches
> >>>>> out there is a lot of work when it is time to crank out security
> >> fixes.
> >>>>> Additionally, keeping up with Jetty and other dependencies is going to
> >>>>> become more difficult if we do not start taking steps to align JDK +
> >>>>> jakarta in supported branches.
> >>>>>
> >>>>> I also feel that the current status of the JMS 2.0 phased
> >> implementation
> >>>>> is closer to done than the amount of work to revert AMQ-7309. PR-729
> >> has
> >>>>> 200+ test cases and has addressed all feedback as of this morning.
> >>>>>
> >>>>> JMS 2.0 tested and validated:
> >>>>> - All destinations (queue, topic, temp-topic, temp-queue) and all
> >> message
> >>>>> types (bytes, map, object, stream, and text)
> >>>>> - All message property types (bytes, string, int, float, double,
> >> short,
> >>>>> etc.) including min+max data ranges
> >>>>> - Foreign message support
> >>>>> - Range checking on priority and deliveryMode
> >>>>> - Topic Durable Subscriber (JMS v1.x alignment)
> >>>>>
> >>>>> Thank you,
> >>>>> Matt Pavlovich
> >>>>>
> >>>>>> On Feb 22, 2022, at 8:16 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
> >>>>> wrote:
> >>>>>>
> >>>>>> I agree.
> >>>>>>
> >>>>>> @Matt @Robbie @Tim is it ok for you to have 5.17.0 with Spring5,
> >>>>>> log4j2, JDK11 and include JMS2 in 5.18.0 that can happen quickly ?
> >>>>>>
> >>>>>> Regards
> >>>>>> JB
> >>>>>>
> >>>>>> On Tue, Feb 22, 2022 at 3:09 PM Christopher Shannon
> >>>>>> <christopher.l.shan...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> I'm +1 on moving forward without JMS 2.0 until 5.18.0. The reality
> >> is
> >>>>> there is no consensus to keep it in 5.17.0. There are multiple people
> >> who
> >>>>> do not want to include it in 5.17.0 so it's time to move on without.
> >> We
> >>>>> also need to revert the commits from
> >>>>> https://issues.apache.org/jira/browse/AMQ-7309 as there is no reason
> >> to
> >>>>> include that now.
> >>>>>>>
> >>>>>>> So I say go ahead with the release and vote (after wrapping things
> >> up
> >>>>> including reverting that AMQ-7309 JMS 2 stuff).
> >>>>>>>
> >>>>>>> I'm pretty tired of the back and forth and fighting over version
> >>>>> numbers to be honest and just want to move on. It's not productive to
> >> keep
> >>>>> arguing anymore over a version...5.18.0 can literally go out whenever
> >> we
> >>>>> want.
> >>>>>>>
> >>>>>>> On Tue, Feb 22, 2022 at 8:50 AM Jean-Baptiste Onofré <
> >> j...@nanthrax.net>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi guys,
> >>>>>>>>
> >>>>>>>> Quick update about 5.17.0 release:
> >>>>>>>>
> >>>>>>>> - I fixed/squash log4j2 update PR
> >>>>>>>> (https://github.com/apache/activemq/pull/662). I think it's OK
> >> (I'm
> >>>>>>>> waiting for the end of Jenkins).
> >>>>>>>> - I'm creating Apache POM 25 update PR
> >>>>>>>> - I'm creating Spring 5.3.16 update PR
> >>>>>>>>
> >>>>>>>> So, ActiveMQ 5.17.0 is almost ready from this standpoint.
> >>>>>>>>
> >>>>>>>> As I would like to start the vote asap, It would be great to act
> >> about
> >>>>>>>> JMS2. Do you want me to start with different options ?
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>> JB
> >>>>>>>>
> >>>>>>>> On Mon, Feb 21, 2022 at 5:55 AM 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
> >>>>>
> >>>>>
> >>>
> >>
>
