maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Nicoll <stephane.nic...@gmail.com>
Subject Re: Surefire maintenance release
Date Thu, 11 Apr 2019 06:07:06 GMT
Awesome work, thank you very much Enrico!

On Wed, Apr 10, 2019 at 3:29 PM Enrico Olivelli <eolivelli@gmail.com> wrote:

> Sorry for the delay
>
> The work branch seems in good shape.
> Now it is only a matter or cutting the release
>
>
> Enrico
>
> Il lun 1 apr 2019, 16:09 Enrico Olivelli <eolivelli@gmail.com> ha scritto:
>
> >
> >
> > Il sab 30 mar 2019, 14:16 Enrico Olivelli <eolivelli@gmail.com> ha
> > scritto:
> >
> >> I have created a PR for your work Stephane
> >> https://github.com/apache/maven-surefire/pull/225
> >>
> >> I will do my best
> >> I am still new to the release procedure, never cut a release for
> surefire
> >> and we usually are only cutting releases from master.
> >>
> >
> > We are experiencing integration tests failures I am checking with Chris.
> > Any help is appreciated
> >
> > Enrico
> >
> >
> >
> >>
> >> Enrico
> >>
> >>
> >>
> >> Il gio 28 mar 2019, 00:34 Olivier Lamy <olamy@apache.org> ha scritto:
> >>
> >>> On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli <eolivelli@gmail.com>
> >>> wrote:
> >>>
> >>> > Il mer 27 mar 2019, 18:10 Tibor Digana <tibordigana@apache.org>
ha
> >>> > scritto:
> >>> >
> >>> > > Enrico, what i maintenance release for you, 2.22.2-M1?
> >>> > >
> >>> >
> >>> > 2.22.2 without suffix
> >>> >
> >>>
> >>> +1
> >>> @Tibor if you are too busy maybe Enrico can cut the release if he has
> >>> time.
> >>>
> >>>
> >>> >
> >>> >
> >>> > Enrico
> >>> >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > > On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli <
> eolivelli@gmail.com
> >>> >
> >>> > > wrote:
> >>> > >
> >>> > > > Stephane
> >>> > > > thank you so much.
> >>> > > > I think we will be able to cut a maintenaince release soon
with
> >>> your
> >>> > > > branch.
> >>> > > >
> >>> > > > Maybe you can join us in chat with
> >>> https://s.apache.org/slack-invite
> >>> > > > #maven <https://s.apache.org/slack-invite#maven> channel
> >>> > > >
> >>> > > >
> >>> > > > Enrico
> >>> > > >
> >>> > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
> >>> > > > <tibordigana@apache.org> ha scritto:
> >>> > > > >
> >>> > > > > Stephane, What exists in our agreement are two issues
> >>> (SUREFIRE-1546
> >>> > > and
> >>> > > > > SUREFIRE-1614), you will have them but no multiple releases
> (not
> >>> > > > effective
> >>> > > > > in the perspectives of out spare time).
> >>> > > > > We need people like you who will support us in 3.0.0-M4.
This
> is
> >>> the
> >>> > > main
> >>> > > > > goal.
> >>> > > > > The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered
to
> >>> you,
> >>> > > but
> >>> > > > no
> >>> > > > > more and not less.
> >>> > > > > The thing is how you will participate by your hands
in Java
> >>> code. The
> >>> > > > > result depends on you.
> >>> > > > > But again, this what we solve here is not important
for ASF. It
> >>> is
> >>> > > > > important for you and your agenda.
> >>> > > > > For the project is important the deal we made several
years
> ago,
> >>> when
> >>> > > we
> >>> > > > > planned to provide Extensions API for the Users. To
get there
> we
> >>> need
> >>> > > to
> >>> > > > > unfortunately rework internal code in Surefire project
which
> >>> takes
> >>> > > > really a
> >>> > > > > lots of time and spends private energy, and thus 2.22.2
is less
> >>> > > important
> >>> > > > > from this perspective. We have to support long standing
vision
> >>> but
> >>> > the
> >>> > > > > version 2.22.2 is something short lasting which you
and some
> >>> Spring
> >>> > > guys
> >>> > > > > wanted due to they have a problem* with their own internal
> >>> rules* and
> >>> > > > > technically Spring project can solve this problem with
> 3.0.0-M3.
> >>> > > > Therefore
> >>> > > > > we are wasting the time if we write the code for you.
Therefore
> >>> you
> >>> > > > should
> >>> > > > > provide pull request by yourself as this is OSS and
we can
> make a
> >>> > code
> >>> > > > > review. But our effort would be really only short time
relevant
> >>> if we
> >>> > > > > dedicate too much time in 2.22.2 with these two Jira
issues. We
> >>> have
> >>> > > few
> >>> > > > > active Java developers and "stealing" them for your
activity
> >>> means
> >>> > that
> >>> > > > we
> >>> > > > > are not effective and slow. Therefore, Stephane pls
prepare the
> >>> > commits
> >>> > > > on
> >>> > > > > your responsibility on GitHub in your pull request and
we can
> >>> invest
> >>> > > the
> >>> > > > > time to check it including the build check and cutting
the
> >>> release
> >>> > > > version.
> >>> > > > >
> >>> > > > > T
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > > On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll <
> >>> > > > stephane.nicoll@gmail.com>
> >>> > > > > wrote:
> >>> > > > >
> >>> > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
> >>> > > tibordigana@apache.org>
> >>> > > > > > wrote:
> >>> > > > > >
> >>> > > > > > > Stephane,
> >>> > > > > > >
> >>> > > > > > > >> I wanted to make sure that the JUnit5
story was
> functional
> >>> > > > > > >
> >>> > > > > > > I really don't like politics.
> >>> > > > > >
> >>> > > > > >
> >>> > > > > > What's that supposed to mean? If you want to quote
something,
> >>> > please
> >>> > > > quote
> >>> > > > > > the full sentence. The full sentence is *"I wanted
to make
> sure
> >>> > that
> >>> > > > the
> >>> > > > > > JUnit5 story was functional with the vintage engine
and the
> >>> current
> >>> > > GA
> >>> > > > of
> >>> > > > > > surefire." *which I believe is an accurate description
of the
> >>> > current
> >>> > > > > > situation.
> >>> > > > > >
> >>> > > > > >
> >>> > > > > > > Did you see SUREFIRE-1614?
> >>> > > > > >
> >>> > > > > >
> >>> > > > > > I did, that's the issue I backported. What are
you talking
> >>> about?
> >>> > > > > >
> >>> > > > > >
> >>> > > > > >
> >>> > > > > > > It really does not
> >>> > > > > > > break functionality (only affects logger)
and SUREFIRE-1614
> >>> is
> >>> > not
> >>> > > > worth
> >>> > > > > > of
> >>> > > > > > > making release with single improvement. If
you want to be
> >>> > > > consistent, you
> >>> > > > > > > should stand on your original list of issues
in your first
> >>> email
> >>> > > and
> >>> > > > this
> >>> > > > > > > is: SUREFIRE-1546 and SUREFIRE-1614.
> >>> > > > > > >
> >>> > > > > >
> >>> > > > > > I wanted to but someone from the JUnit team said
that
> >>> backporting
> >>> > > that
> >>> > > > > > second issue "makes no sense". What am I supposed
to do with
> >>> that
> >>> > > > > > information exactly?
> >>> > > > > >
> >>> > > > > > At the end of the day, you decide what the outcome
of this
> >>> request
> >>> > > has
> >>> > > > to
> >>> > > > > > be. Spring Boot can't upgrade its base usage to
JUnit 5
> >>> because it
> >>> > > > does not
> >>> > > > > > work properly when combined with the vintage engine.
That's
> >>> all I
> >>> > am
> >>> > > > trying
> >>> > > > > > to fix.
> >>> > > > > >
> >>> > > > > > I also think that It doesn't matter how many issues
you have
> >>> fixed
> >>> > > in a
> >>> > > > > > maintenance release as long as that helps the community.
> Others
> >>> > > members
> >>> > > > > > here have expressed a +1 to that proposal.
> >>> > > > > >
> >>> > > > > > Thanks,
> >>> > > > > > S.
> >>> > > > > >
> >>> > > > > >
> >>> > > > > >
> >>> > > > > > > We in Slack discuss technical details what
we do in
> milestone
> >>> > > > versions.
> >>> > > > > > > Enrico and Christian are active developers
but we need to
> >>> have
> >>> > more
> >>> > > > > > > developers like you Stephane and I would appreciate
to have
> >>> > > > additionally
> >>> > > > > > > the previous developers on the board as well
and grow the
> >>> team,
> >>> > > i.e.
> >>> > > > > > > Andreas and Kristian.
> >>> > > > > > >
> >>> > > > > > > Cheers
> >>> > > > > > > Tibor
> >>> > > > > > >
> >>> > > > > > >
> >>> > > > > > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll
<
> >>> > > > > > stephane.nicoll@gmail.com
> >>> > > > > > > >
> >>> > > > > > > wrote:
> >>> > > > > > >
> >>> > > > > > > > Thanks for having a look Tibor!
> >>> > > > > > > >
> >>> > > > > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor
Digana <
> >>> > > > tibordigana@apache.org>
> >>> > > > > > > > wrote:
> >>> > > > > > > >
> >>> > > > > > > > > The diff looks good.
> >>> > > > > > > > >
> >>> > > > > > > > > Stephane, I guess this only 50%
work you wanted to
> have.
> >>> > > > > > > > >
> >>> > > > > > > >
> >>> > > > > > > > I wanted to make sure that the JUnit5
story was
> functional
> >>> with
> >>> > > the
> >>> > > > > > > vintage
> >>> > > > > > > > engine and the current GA of surefire.
It looks like this
> >>> > change
> >>> > > > does
> >>> > > > > > the
> >>> > > > > > > > job for us.
> >>> > > > > > > >
> >>> > > > > > > > As for the other change, I read Christan's
reply, quoting
> >>> > below:
> >>> > > > > > > >
> >>> > > > > > > >
> >>> > > > > > > >
> >>> > > > > > > >
> >>> > > > > > > > *supporting "@DisplayName" and therefore
also
> >>> > > > > > > > backportinghttps://
> >>> issues.apache.org/jira/browse/SUREFIRE-1546
> >>> > > > > > > > <https://issues.apache.org/jira/browse/SUREFIRE-1546>
to
> >>> the
> >>> > 2.x
> >>> > > > > > branch
> >>> > > > > > > > makesalmost *no* sense to me. *
> >>> > > > > > > >
> >>> > > > > > > > As you've explained, backporting this
change would be
> more
> >>> > > > challenging
> >>> > > > > > > and
> >>> > > > > > > > it looks like it isn't a blocker in its
current form
> >>> anyway so
> >>> > I
> >>> > > > have
> >>> > > > > > no
> >>> > > > > > > > opinion as how we should proceed. If
the team feels that
> >>> > > > backporting it
> >>> > > > > > > is
> >>> > > > > > > > important, I can give it another go.
> >>> > > > > > > >
> >>> > > > > > > > Cheers,
> >>> > > > > > > > S.
> >>> > > > > > > >
> >>> > > > > > > >
> >>> > > > > > > >
> >>> > > > > > > >
> >>> > > > > > > > >
> >>> > > > > > > > > Let's not make too many versions
because this would be
> a
> >>> > > > precedent.
> >>> > > > > > > > >
> >>> > > > > > > > > Question about JUnit5 display name.
Currently our
> >>> solution
> >>> > > turns
> >>> > > > XML
> >>> > > > > > > file
> >>> > > > > > > > > name and XML content to the textual
display name and
> not
> >>> > fully
> >>> > > > > > > qualified
> >>> > > > > > > > > class name. This means that the
class name would not
> >>> appear
> >>> > in
> >>> > > > the
> >>> > > > > > file
> >>> > > > > > > > > name of XML report. We want to give
the user chance to
> >>> > > configure
> >>> > > > this
> >>> > > > > > > in
> >>> > > > > > > > > 3.0.0-M4 and alter this behavior.
So it's good to make
> a
> >>> > > > consensus
> >>> > > > > > here
> >>> > > > > > > > and
> >>> > > > > > > > > agree on it. I prefer more complex
configuration with
> >>> MOJO
> >>> > > > parameter
> >>> > > > > > as
> >>> > > > > > > > > Object and not boolean. Since currently
we have
> >>> > > > > > > > > *StatelessXmlReporter.java*,
> >>> > > > > > > > > I prefer opening the internal impl
with this parameter
> in
> >>> > > plugin
> >>> > > > > > > > > configuration and alter the behavior
in POM or in
> user's
> >>> Java
> >>> > > > code:
> >>> > > > > > > > >
> >>> > > > > > > > > <stateless-reporter
> >>> > > > > > > > >
> >>> > > >
> impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
> >>> > > > > > > <!--
> >>> > > > > > > > by
> >>> > > > > > > > > default -->
> >>> > > > > > > > >     <useFileName>human readable</useFileName>
<!--
> >>> default:
> >>> > > fully
> >>> > > > > > > > qualified
> >>> > > > > > > > > class name -->
> >>> > > > > > > > >     <useTestCaseClass>human
readable</
> useTestCaseClass>
> >>> > > > > > > > >     <useTestCaseMethod>human
readable</
> >>> useTestCaseMethod>
> >>> > > > > > > > > </ stateless-reporter>
> >>> > > > > > > > >
> >>> > > > > > > > > If somebody prefers streaming the
report on the fly to
> >>> YAML,
> >>> > we
> >>> > > > can
> >>> > > > > > > > provide
> >>> > > > > > > > > same for Stateful reporter interface.
> >>> > > > > > > > > Unfortunately all three attributes
of the object must
> >>> have
> >>> > same
> >>> > > > > > > settings
> >>> > > > > > > > in
> >>> > > > > > > > > 2.x. The reason is that it is not
possible to have it
> so
> >>> > sooth
> >>> > > > > > behaving
> >>> > > > > > > > in
> >>> > > > > > > > > 2.x. We in 3.0 rework internal implementation,
a lot of
> >>> > > classes,
> >>> > > > to
> >>> > > > > > > > support
> >>> > > > > > > > > many new features/fixes (support
this in JUnit5
> Provider
> >>> and
> >>> > > > > > > additionally
> >>> > > > > > > > > to resolve critical bugs, ...).
> >>> > > > > > > > > But the benefit in this concept
is that we define it
> >>> once and
> >>> > > we
> >>> > > > > > won't
> >>> > > > > > > > have
> >>> > > > > > > > > any reason to change this concept
again in another
> >>> version.
> >>> > > > > > > > > Makes sense?
> >>> > > > > > > > >
> >>> > > > > > > > > Cheers
> >>> > > > > > > > > Tibor
> >>> > > > > > > > >
> >>> > > > > > > > > On Mon, Mar 25, 2019 at 3:38 PM
Stephane Nicoll <
> >>> > > > > > > > stephane.nicoll@gmail.com
> >>> > > > > > > > > >
> >>> > > > > > > > > wrote:
> >>> > > > > > > > >
> >>> > > > > > > > > > Hey,
> >>> > > > > > > > > >
> >>> > > > > > > > > > Can someone working on surefire
confirm the interest
> of
> >>> > > > creating
> >>> > > > > > that
> >>> > > > > > > > > > branch in the main repo and
kick-off a release if a
> >>> review
> >>> > is
> >>> > > > > > > > > satisfactory?
> >>> > > > > > > > > >
> >>> > > > > > > > > > Thanks!
> >>> > > > > > > > > > S.
> >>> > > > > > > > > >
> >>> > > > > > > > > >
> >>> > > > > > > > > > On Wed, Mar 13, 2019 at 4:09
PM Stephane Nicoll <
> >>> > > > > > > > > stephane.nicoll@gmail.com
> >>> > > > > > > > > > >
> >>> > > > > > > > > > wrote:
> >>> > > > > > > > > >
> >>> > > > > > > > > > > Hey,
> >>> > > > > > > > > > >
> >>> > > > > > > > > > > I've created a `2.22.x`
branch based on the 2.22.1
> >>> tag
> >>> > and
> >>> > > > I've
> >>> > > > > > > > > > > cherry-picked the issue
we need to get proper
> >>> support for
> >>> > > the
> >>> > > > > > > vintage
> >>> > > > > > > > > > > engine[1]
> >>> > > > > > > > > > >
> >>> > > > > > > > > > > This 2.22.2-SNAPSHOT works
for our purpose so I was
> >>> > > > wondering if
> >>> > > > > > > more
> >>> > > > > > > > > > > fixes could be backported
and/or if someone would
> >>> like to
> >>> > > > review
> >>> > > > > > > > those
> >>> > > > > > > > > > > changes.
> >>> > > > > > > > > > >
> >>> > > > > > > > > > > Thanks,
> >>> > > > > > > > > > > S.
> >>> > > > > > > > > > >
> >>> > > > > > > > > > >
> >>> > > > > > > > > > > [1]
> >>> > https://github.com/snicoll/maven-surefire/tree/2.22.x
> >>> > > > > > > > > > >
> >>> > > > > > > > > > > On Wed, Feb 27, 2019 at
1:46 PM Tibor Digana <
> >>> > > > > > > tibordigana@apache.org
> >>> > > > > > > > >
> >>> > > > > > > > > > > wrote:
> >>> > > > > > > > > > >
> >>> > > > > > > > > > >> Hi  Stephane,
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >> We are talking only
about these two commits [1]?
> >>> > > > > > > > > > >> Notice that 001e807
modifies file names to the
> >>> verbose
> >>> > one
> >>> > > > which
> >>> > > > > > > > > breaks
> >>> > > > > > > > > > >> backwards compatibility
and this should not
> >>> forcibly (by
> >>> > > > > > default)
> >>> > > > > > > > > happen
> >>> > > > > > > > > > >> in
> >>> > > > > > > > > > >> your version/branch.
> >>> > > > > > > > > > >> Try to fork the project,
make a local branch and
> >>> then
> >>> > > reset
> >>> > > > HEAD
> >>> > > > > > > to
> >>> > > > > > > > > [2],
> >>> > > > > > > > > > >> i.e. git reset --hard
> >>> > > > 19006aa70f36705f399b8c105a16f636904f00f3
> >>> > > > > > > > > > >> And then cherrypick
both commits [1].
> >>> > > > > > > > > > >> Make sure the order
is correct but it won't be so
> >>> > > > > > straightforward.
> >>> > > > > > > > The
> >>> > > > > > > > > > >> tests have to pass
(mvn install -P run-its).
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >> [1]:
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >>
> >>> > > > > > > > > >
> >>> > > > > > > > >
> >>> > > > > > > >
> >>> > > > > > >
> >>> > > > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >>
> >>> > > > > > > > > >
> >>> > > > > > > > >
> >>> > > > > > > >
> >>> > > > > > >
> >>> > > > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >> [2]:
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >>
> >>> > > > > > > > > >
> >>> > > > > > > > >
> >>> > > > > > > >
> >>> > > > > > >
> >>> > > > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >> Cheers
> >>> > > > > > > > > > >> Tibor
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >> On Mon, Feb 25, 2019
at 8:54 AM Stephane Nicoll <
> >>> > > > > > > > > > >> stephane.nicoll@gmail.com>
> >>> > > > > > > > > > >> wrote:
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >> > Hi everyone,
> >>> > > > > > > > > > >> >
> >>> > > > > > > > > > >> > It's great to
see the progress on Surefire 3.0
> >>> and I
> >>> > > > wanted to
> >>> > > > > > > > reach
> >>> > > > > > > > > > >> out to
> >>> > > > > > > > > > >> > discuss a practicable
problem with the 2.x line.
> >>> There
> >>> > > > are a
> >>> > > > > > > > number
> >>> > > > > > > > > of
> >>> > > > > > > > > > >> > fixes for JUnit
5 that are only available in the
> >>> 3.x
> >>> > > line
> >>> > > > that
> >>> > > > > > > > isn't
> >>> > > > > > > > > > GA
> >>> > > > > > > > > > >> > yet. [1][2]
> >>> > > > > > > > > > >> >
> >>> > > > > > > > > > >> > Putting my Spring
Boot hat for a min, this
> >>> actually
> >>> > > > prevents
> >>> > > > > > us
> >>> > > > > > > > from
> >>> > > > > > > > > > >> > upgrading our
test support to JUnit 5: our plan
> >>> is to
> >>> > > > offer
> >>> > > > > > > > maximum
> >>> > > > > > > > > > >> > flexibility by
providing the vintage engine (so
> >>> that
> >>> > > > users can
> >>> > > > > > > > keep
> >>> > > > > > > > > > >> their
> >>> > > > > > > > > > >> > tests and migrate
at their own pace).
> >>> > > > > > > > > > >> >
> >>> > > > > > > > > > >> > We can't upgrade
to a milestone as our upgrade
> >>> policy
> >>> > > > prevents
> >>> > > > > > > > that
> >>> > > > > > > > > > >> > (regardless of
how stable this is and especially
> >>> since
> >>> > > > > > backward
> >>> > > > > > > > > > >> > incompatible
changes have been pushed to the
> >>> latest
> >>> > > > > > milestone).
> >>> > > > > > > So
> >>> > > > > > > > > > we're
> >>> > > > > > > > > > >> > kind of stuck.
> >>> > > > > > > > > > >> >
> >>> > > > > > > > > > >> > Would there be
an appetite to backport those
> >>> fixes and
> >>> > > > > > release a
> >>> > > > > > > > > > 2.22.2?
> >>> > > > > > > > > > >> >
> >>> > > > > > > > > > >> > Thanks,
> >>> > > > > > > > > > >> > S.
> >>> > > > > > > > > > >> >
> >>> > > > > > > > > > >> > [1]
> >>> > https://issues.apache.org/jira/browse/SUREFIRE-1614
> >>> > > > > > > > > > >> > [2]
> >>> > > > > > > > > > >>
> >>> > > > > > > >
> >>> > > >
> >>> https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> >>> > > > > > > > > > >> >
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >
> >>> > > > > > > > > >
> >>> > > > > > > > >
> >>> > > > > > > >
> >>> > > > > > >
> >>> > > > > >
> >>> > > >
> >>> > > >
> >>> ---------------------------------------------------------------------
> >>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >>> > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>>
> >>> --
> >>> Olivier Lamy
> >>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message