+1, i've never liked including jetty-all and might as well keep it up to
date with a major release.

I think we are good to go , I did a review of a 5.17.0 snapshot build last
week and things looked good. I will review the official release of course
but I think we are in good shape.

On Mon, Feb 28, 2022 at 8:45 AM Jean-Baptiste Onofré <
jeanbaptiste.ono...@gmail.com> wrote:

> Hi guys,
>
> FYI, I merged log4j2 support on main for 5.17.0.
>
> For security reasons and being up to date with Jetty, I would like to
> include https://github.com/apache/activemq/pull/784
> Thoughts ?
>
> Regarding the release, I think we are good. If there are no
> objections, I would like to submit 5.17.0 to vote tonight (my time).
>
> Regards
> JB
>
> On Wed, Feb 23, 2022 at 6:51 PM Robbie Gemmell <robbie.gemm...@gmail.com>
> wrote:
> >
> > 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
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>
> > >
>

Reply via email to