maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: Surefire maintenance release
Date Thu, 11 Apr 2019 05:58:32 GMT
This is the final branch from which I will cut the release.
https://github.com/apache/maven-surefire/tree/release/2.22.2

Re-launched Jenkins to check for the last time:
https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/


Enrico

Il giorno mer 10 apr 2019 alle ore 14:23 Enrico Olivelli
<eolivelli@gmail.com> ha scritto:
>
> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message