Maven Surefire pull request #528

[Scott Babcock]

I’m requesting additional reviews and feedback on this Maven Surefire pull 
request, which resolves 
SUREFIRE-2075.

One of the reviewer expressed concern about the default value (5) which TestNG 
provides for the [threadCount] setting. I posted replies to this concern:


  *   I cited the fact that TestNG only utilizes this default value in parallel 
configurations in which no user-supplied value was specified.
  *   I pointed to the TestNG implementation that sets the thread count to 1 
for sequential configurations.
  *   I pointed out that the current behavior of TestNGMapConfigurator 
(injecting a thread count of 1) conflicts with the standalone behavior of 
TestNG.
  *   I pointed out that this override results in sequential test execution for 
parallel configurations that don’t explicitly specify a thread count value.
  *   I made reference to the Maven Surefire documentation, which unequivocally 
states that the default value for [threadCount] is 5 if this setting is omitted.
  *   I pointed out that the existing implementation will throw a naked 
NumberFormatException for invalid [threadCount] values, whereas my revised 
implementation will return an actionable error.

If there are additional questions or concerns, I’m happy to respond.

Thanks!
= Scott Babcock =
https://github.com/sbabcoc

Sent from Mail for Windows

Re: A Maven extension for dependency tracking

[Grzegorz Grzybek]

Hello!

Thanks for your comments and PR - I needed to switch to different tasks,
but soon (next week?) I'm going to spend more time on it. I yet have to get
a feeling of the graph/stack that could be passed around.
And check these DF/BF dependency collectors (as I didn't see them in
resolver 1.6.3). I'll keep the
https://issues.apache.org/jira/browse/MRESOLVER-248 tab open till I check
it ;)

kind regards
Grzegorz Grzybek


śr., 11 maj 2022 o 18:40 Tamás Cservenák  napisał(a):

> Howdy,
>
> https://github.com/apache/maven-resolver/pull/176
>
> So here is some implementation "demo" (that could be made into extension
> point), as explained in Draft PR description.
> BUT, also as written in PR, am getting a feeling that doing this is
> "dangerous", and a simple callback with whole collected graph would be
> better
>
>
> WDYT?
>
> Tamas
>
> On Mon, May 2, 2022 at 4:18 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > just a few short answers:
> > - 1st: Personally, from a Resolver perspective, I'd just provide an API
> > (basically the author extending resolver should implement) and make it
> > simple to "click in" (Sisu component discovery).
> > - 2nd: resolver IMHO should not provide any out of the box component
> > implementation at all
> >
> > So 1st would provide a "stable" extension point for users who would like
> > to "integrate" with resolver at this point (like you did), but it could
> > become possible using simply this new API, instead the hoops and loops
> your
> > code was forced to do (as resolver is quite "closed" in this respect).
> >
> > As for 2nd point, while I do like your idea of "decorating" local
> > repository, I'd try a bit different route: I'd integrate this
> > https://github.com/lambdazen/bitsy that makes possible to use Apache
> > Tinkerpop's Gremlin queries to ask about the built graph for example...
> >
> > And one big remark: the collector is the "hottest point" in resolver
> (heap
> > and cpu wise), so ANY "new API" implementation should be aware, that each
> > "lost" millisecond directly affects resolver collection speed, but I
> think
> > for "research kind" of stuff, of just "recording the process result"
> should
> > fit in just fine. I don't see this as a "standard" feature of Maven, but
> > who knows? :)
> >
> > Just my 5 cents...
> >
> > HTH
> > Tamas
> >
> > On Mon, May 2, 2022 at 4:09 PM Grzegorz Grzybek 
> > wrote:
> >
> >> Thank you Tamás for checking my experiment
> >>
> >> I'm just finishing my work before tomorrow's national holiday, but will
> >> read your information more carefully soon.
> >>
> >> Whether it's DFS or BFS, as long as there's tracking from initial to
> >> ultimate dependency, it's enough. DFS sounds more "natural" here
> though. I
> >> didn't check the CollectResult class yet - is it created per dependency
> or
> >> for the entire project?
> >>
> >> And yes - I didn't check multithreading, as in normal scenario (just
> `mvn
> >> clean install`) I didn't observe concurrency issues accessing the stack.
> >> Mind that I know a bit about maven "components", but there are
> definitely
> >> few missing things in my understanding.
> >>
> >> Checking your output, I see there are two aspects of this potential
> >> enhancement to the resolver:
> >>  - 1st - how to effectively collect the "reverse dependency tree" in
> >> context of DFS/BFS/multithreading
> >>  - 2nd - how to write the information
> >>
> >> 2nd aspect could include:
> >>  - whether there should be ".tracking" for each GAV directory in local
> >> repo
> >> (tracking for the purpose of entire local repository)
> >>  - maybe there should be configurable output location for single report
> of
> >> a build? (tracking for the purpose of single project)
> >>  - which format to use (human consumable or machine readable?)
> >>
> >> For now I've used resolver 1.6.3 from Maven 3.8.5, but I'll look at
> `main`
> >> branch too.
> >>
> >> kind regards
> >> Grzegorz Grzybek
> >>
> >>
> >> pon., 2 maj 2022 o 15:57 Tamás Cservenák 
> >> napisał(a):
> >>
> >> > What I missed to mention: in my case the trees in the gist are about
> >> > "resolving maven-core 3.5.8", but I guess you figured it out from the
> >> > tree
> >> >
> >> > T
> >> >
> >> > On Mon, May 2, 2022 at 3:55 PM Tamás Cservenák 
> >> > wrote:
> >> >
> >> > > Howdy,
> >> > >
> >> > > I did some experiment, that (partially re-using your code to dump
> the
> >> rev
> >> > > tree) produces this output:
> >> > > https://gist.github.com/cstamas/598a3266f943984442c00df30520294f
> >> > >
> >> > > (note: 1.8.0 resolver has two collector implementations: original
> >> > > Depth-First and new Breadth-First called DF and BF respectively)
> >> > >
> >> > > The code is not pushed yet anywhere, but I plan to make an API for
> >> this,
> >> > > and as you can see, it works
> >> > > for both implementations of collectors. Also, I hook ONLY into
> >> collector,
> >> > > as that's the place where the graph
> >> > > is being built, but this is logically 

Re: A Maven extension for dependency tracking

[Tamás Cservenák]

Howdy,

https://github.com/apache/maven-resolver/pull/176

So here is some implementation "demo" (that could be made into extension
point), as explained in Draft PR description.
BUT, also as written in PR, am getting a feeling that doing this is
"dangerous", and a simple callback with whole collected graph would be
better


WDYT?

Tamas

On Mon, May 2, 2022 at 4:18 PM Tamás Cservenák  wrote:

> Howdy,
>
> just a few short answers:
> - 1st: Personally, from a Resolver perspective, I'd just provide an API
> (basically the author extending resolver should implement) and make it
> simple to "click in" (Sisu component discovery).
> - 2nd: resolver IMHO should not provide any out of the box component
> implementation at all
>
> So 1st would provide a "stable" extension point for users who would like
> to "integrate" with resolver at this point (like you did), but it could
> become possible using simply this new API, instead the hoops and loops your
> code was forced to do (as resolver is quite "closed" in this respect).
>
> As for 2nd point, while I do like your idea of "decorating" local
> repository, I'd try a bit different route: I'd integrate this
> https://github.com/lambdazen/bitsy that makes possible to use Apache
> Tinkerpop's Gremlin queries to ask about the built graph for example...
>
> And one big remark: the collector is the "hottest point" in resolver (heap
> and cpu wise), so ANY "new API" implementation should be aware, that each
> "lost" millisecond directly affects resolver collection speed, but I think
> for "research kind" of stuff, of just "recording the process result" should
> fit in just fine. I don't see this as a "standard" feature of Maven, but
> who knows? :)
>
> Just my 5 cents...
>
> HTH
> Tamas
>
> On Mon, May 2, 2022 at 4:09 PM Grzegorz Grzybek 
> wrote:
>
>> Thank you Tamás for checking my experiment
>>
>> I'm just finishing my work before tomorrow's national holiday, but will
>> read your information more carefully soon.
>>
>> Whether it's DFS or BFS, as long as there's tracking from initial to
>> ultimate dependency, it's enough. DFS sounds more "natural" here though. I
>> didn't check the CollectResult class yet - is it created per dependency or
>> for the entire project?
>>
>> And yes - I didn't check multithreading, as in normal scenario (just `mvn
>> clean install`) I didn't observe concurrency issues accessing the stack.
>> Mind that I know a bit about maven "components", but there are definitely
>> few missing things in my understanding.
>>
>> Checking your output, I see there are two aspects of this potential
>> enhancement to the resolver:
>>  - 1st - how to effectively collect the "reverse dependency tree" in
>> context of DFS/BFS/multithreading
>>  - 2nd - how to write the information
>>
>> 2nd aspect could include:
>>  - whether there should be ".tracking" for each GAV directory in local
>> repo
>> (tracking for the purpose of entire local repository)
>>  - maybe there should be configurable output location for single report of
>> a build? (tracking for the purpose of single project)
>>  - which format to use (human consumable or machine readable?)
>>
>> For now I've used resolver 1.6.3 from Maven 3.8.5, but I'll look at `main`
>> branch too.
>>
>> kind regards
>> Grzegorz Grzybek
>>
>>
>> pon., 2 maj 2022 o 15:57 Tamás Cservenák 
>> napisał(a):
>>
>> > What I missed to mention: in my case the trees in the gist are about
>> > "resolving maven-core 3.5.8", but I guess you figured it out from the
>> > tree
>> >
>> > T
>> >
>> > On Mon, May 2, 2022 at 3:55 PM Tamás Cservenák 
>> > wrote:
>> >
>> > > Howdy,
>> > >
>> > > I did some experiment, that (partially re-using your code to dump the
>> rev
>> > > tree) produces this output:
>> > > https://gist.github.com/cstamas/598a3266f943984442c00df30520294f
>> > >
>> > > (note: 1.8.0 resolver has two collector implementations: original
>> > > Depth-First and new Breadth-First called DF and BF respectively)
>> > >
>> > > The code is not pushed yet anywhere, but I plan to make an API for
>> this,
>> > > and as you can see, it works
>> > > for both implementations of collectors. Also, I hook ONLY into
>> collector,
>> > > as that's the place where the graph
>> > > is being built, but this is logically equivalent to your "More
>> > interesting
>> > > ... 2nd case".
>> > >
>> > > Will ping once again when I have the changes
>> > >
>> > > Thanks
>> > > Tamas
>> > >
>> > > On Thu, Apr 28, 2022 at 9:01 PM Tamás Cservenák 
>> > > wrote:
>> > >
>> > >> Howdy,
>> > >>
>> > >> This is very cool, I was actually tinkering on very similar issues in
>> > >> resolver coming from totally different angles.
>> > >>
>> > >> And yes, the resolver collector is not quite "extension" friendly,
>> but
>> > we
>> > >> will make it right.
>> > >> Just FYI, that in the latest resolver (1.8.0) there are actually two
>> > >> implementations: depth-first (original) and depth-first.
>> > >>
>> > >> By looking at your code: collection is most 

Re: [DISCUSS] Change reply-to for mailing lists

[Guillaume Nodet]

That's really weird.

Btw, I've checked the headers on the first email of this thread and I don't
have any reply-to:

MIME-Version: 1.0
Date: Wed, 11 May 2022 09:31:31 +0200
Message-ID: <
caa66tpok+1xijg80c2av8_df8tco3ebhqedesa7ayyf4kg0...@mail.gmail.com>
Subject: [DISCUSS] Change reply-to for mailing lists
From: Guillaume Nodet 
To: Maven Developers List 
Content-Type: multipart/alternative; boundary="1f7a7605deb76e35"

I think gmail displays the message I sent, and hides
identical message received from the mailing list, that may be the reason
why the reply-to does not work.  I wonder if this could be caused by the
fact that I did set up my gmail account to impersonate gno...@apache.org
when sending emails...
I also found that I could configure gmail to default to "reply to all"
which will help a lot in those cases.

Thx !


Le mer. 11 mai 2022 à 15:16, Nick Stolwijk  a
écrit :

> I send this mail by replying to my own mail, but it still selects the Maven
> Dev list.
>
> With regards,
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Wed, May 11, 2022 at 1:30 PM Nick Stolwijk 
> wrote:
>
> > I pressed reply to send this mail and didn't experience this problem.
> I've
> > taken a look at the headers from your mail:
> >
> > > Mailing-List: contact dev-h...@maven.apache.org; run by ezmlm
> > > Reply-To: Maven Developers List 
> > > Delivered-To: mailing list 
> > > From: Guillaume Nodet 
> > > To: Maven Developers List 
> >
> > They look good to me.
> >
> > (Tested using GMail)
> >
> > With regards,
> >
> > Nick Stolwijk
> >
> > ~~~ Try to leave this world a little better than you found it and, when
> > your turn comes to die, you can die happy in feeling that at any rate you
> > have not wasted your time but have done your best ~~~
> >
> > Lord Baden-Powell
> >
> >
> > On Wed, May 11, 2022 at 9:31 AM Guillaume Nodet 
> wrote:
> >
> >> I've been hit several times by the fact that the maven mailing lists are
> >> configured in a weird (to me...) way.  I'm used to have the ASF mailing
> >> lists configured in a way that hitting the "reply" button will reply to
> >> the
> >> mailing list and not to the sender. In the context of the ASF at least,
> I
> >> think this totally makes sense to not start private conversations.
> >>
> >> Does anyone actually care about this configuration or should I ask infra
> >> to
> >> modify the default "reply-to" header on the mailing lists ?
> >>
> >> Cheers,
> >> Guillaume Nodet
> >>
> >
>


-- 

Guillaume Nodet

Re: [DISCUSS] Change reply-to for mailing lists

[Nick Stolwijk]

I send this mail by replying to my own mail, but it still selects the Maven
Dev list.

With regards,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


On Wed, May 11, 2022 at 1:30 PM Nick Stolwijk 
wrote:

> I pressed reply to send this mail and didn't experience this problem. I've
> taken a look at the headers from your mail:
>
> > Mailing-List: contact dev-h...@maven.apache.org; run by ezmlm
> > Reply-To: Maven Developers List 
> > Delivered-To: mailing list 
> > From: Guillaume Nodet 
> > To: Maven Developers List 
>
> They look good to me.
>
> (Tested using GMail)
>
> With regards,
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Wed, May 11, 2022 at 9:31 AM Guillaume Nodet  wrote:
>
>> I've been hit several times by the fact that the maven mailing lists are
>> configured in a weird (to me...) way.  I'm used to have the ASF mailing
>> lists configured in a way that hitting the "reply" button will reply to
>> the
>> mailing list and not to the sender. In the context of the ASF at least, I
>> think this totally makes sense to not start private conversations.
>>
>> Does anyone actually care about this configuration or should I ask infra
>> to
>> modify the default "reply-to" header on the mailing lists ?
>>
>> Cheers,
>> Guillaume Nodet
>>
>

Re: [DISCUSS] Change reply-to for mailing lists

[Guillaume Nodet]

I'm using gmail too.  It seems gmail does explicitly not obey the reply-to
header if the sender is yourself.
For example if I hit reply on your email, the "to" field is correctly
filled to dev@maven.apache.org, but if I hit reply on  my own message
(which is my problem because I was replying / closing the mvnd vote), the
"to" field is filled with my own address.
Is that the same behavior for you ?

Guillaume

Le mer. 11 mai 2022 à 13:30, Nick Stolwijk  a
écrit :

> I pressed reply to send this mail and didn't experience this problem. I've
> taken a look at the headers from your mail:
>
> > Mailing-List: contact dev-h...@maven.apache.org; run by ezmlm
> > Reply-To: Maven Developers List 
> > Delivered-To: mailing list 
> > From: Guillaume Nodet 
> > To: Maven Developers List 
>
> They look good to me.
>
> (Tested using GMail)
>
> With regards,
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Wed, May 11, 2022 at 9:31 AM Guillaume Nodet  wrote:
>
> > I've been hit several times by the fact that the maven mailing lists are
> > configured in a weird (to me...) way.  I'm used to have the ASF mailing
> > lists configured in a way that hitting the "reply" button will reply to
> the
> > mailing list and not to the sender. In the context of the ASF at least, I
> > think this totally makes sense to not start private conversations.
> >
> > Does anyone actually care about this configuration or should I ask infra
> to
> > modify the default "reply-to" header on the mailing lists ?
> >
> > Cheers,
> > Guillaume Nodet
> >
>


-- 

Guillaume Nodet

Re: [DISCUSS] Change reply-to for mailing lists

[Nick Stolwijk]

I pressed reply to send this mail and didn't experience this problem. I've
taken a look at the headers from your mail:

> Mailing-List: contact dev-h...@maven.apache.org; run by ezmlm
> Reply-To: Maven Developers List 
> Delivered-To: mailing list 
> From: Guillaume Nodet 
> To: Maven Developers List 

They look good to me.

(Tested using GMail)

With regards,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


On Wed, May 11, 2022 at 9:31 AM Guillaume Nodet  wrote:

> I've been hit several times by the fact that the maven mailing lists are
> configured in a weird (to me...) way.  I'm used to have the ASF mailing
> lists configured in a way that hitting the "reply" button will reply to the
> mailing list and not to the sender. In the context of the ASF at least, I
> think this totally makes sense to not start private conversations.
>
> Does anyone actually care about this configuration or should I ask infra to
> modify the default "reply-to" header on the mailing lists ?
>
> Cheers,
> Guillaume Nodet
>

[ANN] Apache Maven Daemon 0.8.0 released

[Guillaume Nodet]

The Apache Maven team is pleased to announce release of the Apache Maven
Daemon version 0.8.0.

Apache Maven Daemon is a daemon infrastructure for Maven with caching
capabilities and a native client for a better and faster user experience.

This is the 1st release of the Apache Maven Daemon since its donation to
the ASF.  This release embeds Apache Maven 3.8.5.

The release is available for download at:
  https://downloads.apache.org/maven/mvnd/0.8.0/

Regards,
The Apache Maven Team

[DISCUSS] Change reply-to for mailing lists

[Guillaume Nodet]

I've been hit several times by the fact that the maven mailing lists are
configured in a weird (to me...) way.  I'm used to have the ASF mailing
lists configured in a way that hitting the "reply" button will reply to the
mailing list and not to the sender. In the context of the ASF at least, I
think this totally makes sense to not start private conversations.

Does anyone actually care about this configuration or should I ask infra to
modify the default "reply-to" header on the mailing lists ?

Cheers,
Guillaume Nodet

[RESULT] [VOTE] Release Apache Maven Daemon 0.8.0 (2nd try)

[Guillaume Nodet]

Closing this vote with 5 binding +1s and 1 non-binding +1.
I'll publish the release on the final location [1] if possible (or I'll ask
someone if needed) and will then try to update the various packagers
(homebrew, choco, sdkman...) updating the release instructions if necessary.

Cheers,
Guillaume Nodet

[1] https://downloads.apache.org/maven/mvnd/

Le mer. 4 mai 2022 à 14:39, Guillaume Nodet  a écrit :

> I've staged a candidate release at
>   https://dist.apache.org/repos/dist/dev/maven/mvnd/0.8.0/
>
> The changelog is available at
>
> https://github.com/apache/maven-mvnd/blob/master/CHANGELOG.md#080-2022-05-04
>
> I've fixed a bunch of issues regarding the native libraries and
> reproducible builds.
> This is the second attempt at releasing the first version of Mvnd since
> its move into the Maven project, so a thorough look would be welcomed !
>
> Fwiw, the release process is explained at https://github.com/apache/maven-
> mvnd/blob/master/RELEASING.adoc (this is not complete, i'll focus on the
> next phases once the vote passes).
>
>
> Guillaume
>


-- 

Guillaume Nodet