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 Wed, 10 Apr 2019 12:23:04 GMT
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