Re: [VOTE] Release Apache Maven GPG Plugin version 3.0.0

[Tibor Digana]

Sorry my -1 due to all integration tests have failed with the following errors:

Caused by: java.lang.IllegalArgumentException: Can't parse version of
gpg (GnuPG) 2.0.26 (Gpg4win 2.2.3)
at org.apache.maven.plugins.gpg.GpgVersion.compareTo(GpgVersion.java:60)
at org.apache.maven.plugins.gpg.GpgVersion.isBefore(GpgVersion.java:101)
at 
org.apache.maven.plugins.gpg.GpgSigner.generateSignatureForFile(GpgSigner.java:89)
at 
org.apache.maven.plugins.gpg.AbstractGpgSigner.generateSignatureForArtifact(AbstractGpgSigner.java:203)
at 
org.apache.maven.plugins.gpg.GpgSignAttachedMojo.execute(GpgSignAttachedMojo.java:178)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)

The version on the command line:

$ gpg --version
gpg (GnuPG) 2.0.26 (Gpg4win 2.2.3)
libgcrypt 1.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

On Sun, Apr 12, 2020 at 2:50 PM Hervé BOUTEMY  wrote:
>
> Hi,
>
> We solved 13 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&version=12330781&styleName=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1563/
> https://repository.apache.org/content/repositories/maven-1563/org/apache/maven/plugins/maven-gpg-plugin/3.0.0/maven-gpg-plugin-3.0.0-source-release.zip
>
> Source release checksum(s):
> maven-gpg-plugin-3.0.0-source-release.zip sha512: 
> 773e1ba20d3edd6924bf7c909c0bf68746d79874a0df258da05ccc2b3138415f0183350b54209a3003eb081cc11e22bc316a7d8a7016fe4dab30eb0db5a9b0ac
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Cheers
Tibor

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

Re: [VOTE] Release Apache Maven AntRun Plugin version 3.0.0

[Tibor Digana]

+1, the build passed with JDK8 and JDK15, sha512 ok

On Sun, Apr 12, 2020 at 9:57 AM Hervé BOUTEMY  wrote:
>
> Hi,
>
> We solved 22 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317121&version=12330278&styleName=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1562/
> https://repository.apache.org/content/repositories/maven-1562/org/apache/maven/plugins/maven-antrun-plugin/3.0.0/maven-antrun-plugin-3.0.0-source-release.zip
>
> Source release checksum(s):
> maven-antrun-plugin-3.0.0-source-release.zip sha512: 
> 27976fb318c8481013ba89f90eba118f25bad72704b642185b5bae2d796a3f57af7eddb7f665f1db402b2351d34b7487bb28d32e01e9c0180967f64be4836725
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-antrun-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Cheers
Tibor

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

Re: [VOTE] Release Apache Maven GPG Plugin version 3.0.0

[Tibor Digana]

I am still using the same official version for the Windows since 2013.
Many releases were done so far with this native installation in Maven.
T

On Wed, Apr 15, 2020 at 10:16 PM Hervé BOUTEMY  wrote:
>
> questions to Windows users:
> - what GPG distribution do you use, that does not make the plugin fail?
> - is this issue worth dropping the release?
>
> Regards,
>
> Hervé
>
> Le mercredi 15 avril 2020, 21:25:11 CEST Tibor Digana a écrit :
> > Sorry my -1 due to all integration tests have failed with the following
> > errors:
> >
> > Caused by: java.lang.IllegalArgumentException: Can't parse version of
> > gpg (GnuPG) 2.0.26 (Gpg4win 2.2.3)
> > at org.apache.maven.plugins.gpg.GpgVersion.compareTo(GpgVersion.java:60)
> > at org.apache.maven.plugins.gpg.GpgVersion.isBefore(GpgVersion.java:101) at
> > org.apache.maven.plugins.gpg.GpgSigner.generateSignatureForFile(GpgSigner.j
> > ava:89) at
> > org.apache.maven.plugins.gpg.AbstractGpgSigner.generateSignatureForArtifact
> > (AbstractGpgSigner.java:203) at
> > org.apache.maven.plugins.gpg.GpgSignAttachedMojo.execute(GpgSignAttachedMoj
> > o.java:178) at
> > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildP
> > luginManager.java:134)
> >
> > The version on the command line:
> >
> > $ gpg --version
> > gpg (GnuPG) 2.0.26 (Gpg4win 2.2.3)
> > libgcrypt 1.6.2
> > Copyright (C) 2013 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > <http://gnu.org/licenses/gpl.html> This is free software: you are free to
> > change and redistribute it. There is NO WARRANTY, to the extent permitted
> > by law.
> >
> > On Sun, Apr 12, 2020 at 2:50 PM Hervé BOUTEMY  wrote:
> > > Hi,
> > >
> > > We solved 13 issues:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&;
> > > version=12330781&styleName=Text
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1563/
> > > https://repository.apache.org/content/repositories/maven-1563/org/apache/m
> > > aven/plugins/maven-gpg-plugin/3.0.0/maven-gpg-plugin-3.0.0-source-release.
> > > zip
> > >
> > > Source release checksum(s):
> > > maven-gpg-plugin-3.0.0-source-release.zip sha512:
> > > 773e1ba20d3edd6924bf7c909c0bf68746d79874a0df258da05ccc2b3138415f0183350b5
> > > 4209a3003eb081cc11e22bc316a7d8a7016fe4dab30eb0db5a9b0ac
> > >
> > > Staging site:
> > > https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/
> > >
> > > Guide to testing staged releases:
> > > https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Cheers
Tibor

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

Proposal to deprecate Maven 3.0.x

[Tibor Digana]

Some users still use Maven 3.0.5 and they require a support for
compatibility reasons between nowadays Maven plugins and the Maven
3.0.x.

We have a couple of reasons to deprecate this version (JSR-330,
Components injection, Logger) and we have discussed this issue in
https://github.com/apache/maven-surefire/pull/274

Let's discuss it.

Cheers
Tibor17

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

Re: [VOTE] Release Apache Maven GPG Plugin version 3.0.0

[Tibor Digana]

Why this plugin has been working for many years and with the same gpg
installation?
There has to be a change in the comparator of versions according to
the stacktrace. What other explanation?
I did not change anything on my PC. Still the same set of tools.

On Wed, Apr 15, 2020 at 11:07 PM Robert Scholte  wrote:
>
> gpg --version
>
> gpg (GnuPG) 2.2.15
> libgcrypt 1.8.4
> Copyright (C) 2019 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> I've asked INFRA to install gpg on Jenkins, so for about a year both Ubuntu 
> and Windows are covered.
>
>
> Robert
>
> [1] https://issues.apache.org/jira/browse/INFRA-18014
> On 15-4-2020 22:16:35, Hervé BOUTEMY  wrote:
> questions to Windows users:
> - what GPG distribution do you use, that does not make the plugin fail?
> - is this issue worth dropping the release?
>
> Regards,
>
> Hervé
>
> Le mercredi 15 avril 2020, 21:25:11 CEST Tibor Digana a écrit :
> > Sorry my -1 due to all integration tests have failed with the following
> > errors:
> >
> > Caused by: java.lang.IllegalArgumentException: Can't parse version of
> > gpg (GnuPG) 2.0.26 (Gpg4win 2.2.3)
> > at org.apache.maven.plugins.gpg.GpgVersion.compareTo(GpgVersion.java:60)
> > at org.apache.maven.plugins.gpg.GpgVersion.isBefore(GpgVersion.java:101) at
> > org.apache.maven.plugins.gpg.GpgSigner.generateSignatureForFile(GpgSigner.j
> > ava:89) at
> > org.apache.maven.plugins.gpg.AbstractGpgSigner.generateSignatureForArtifact
> > (AbstractGpgSigner.java:203) at
> > org.apache.maven.plugins.gpg.GpgSignAttachedMojo.execute(GpgSignAttachedMoj
> > o.java:178) at
> > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildP
> > luginManager.java:134)
> >
> > The version on the command line:
> >
> > $ gpg --version
> > gpg (GnuPG) 2.0.26 (Gpg4win 2.2.3)
> > libgcrypt 1.6.2
> > Copyright (C) 2013 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > This is free software: you are free to
> > change and redistribute it. There is NO WARRANTY, to the extent permitted
> > by law.
> >
> > On Sun, Apr 12, 2020 at 2:50 PM Hervé BOUTEMY wrote:
> > > Hi,
> > >
> > > We solved 13 issues:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&;
> > > version=12330781&styleName=Text
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1563/
> > > https://repository.apache.org/content/repositories/maven-1563/org/apache/m
> > > aven/plugins/maven-gpg-plugin/3.0.0/maven-gpg-plugin-3.0.0-source-release.
> > > zip
> > >
> > > Source release checksum(s):
> > > maven-gpg-plugin-3.0.0-source-release.zip sha512:
> > > 773e1ba20d3edd6924bf7c909c0bf68746d79874a0df258da05ccc2b3138415f0183350b5
> > > 4209a3003eb081cc11e22bc316a7d8a7016fe4dab30eb0db5a9b0ac
> > >
> > > Staging site:
> > > https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/
> > >
> > > Guide to testing staged releases:
> > > https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Cheers
Tibor

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

Re: Proposal to deprecate Maven 3.0.x

[Tibor Digana]

The Eclipse Aether looks like a strong argument.
If any user would open an issue to provide a fix on the top of Eclipse
Aether then we say 'no' already today in 3.7.0.
So the user has to switch to 3.5.0+ which would end up for him as the
same as deprecating 3.0.x - 3.3.x.
I know that it is a big extend, i understand that but this is
currently the outcome of my analysis.

I don't know what you think about this view.

On Thu, Apr 16, 2020 at 8:52 AM Hervé BOUTEMY  wrote:
>
> +1 to deprecate 3.0.x
>
> TLDR; no need to deprecate Eclipse Aether, which would mean deprecating also
> 3.1.x, 3.2.x and 3.3.x
>
> details:
> "deprecate everything before the maven-resolver import" would mean deprecating
> up to 3.3.x [1]
>
> Given that maven-resolver has exactly the same API as Eclipse Aether (in
> org.eclipse.aether java package) but just a change in Maven coordinates (that
> are all filtered by Maven core class loading, then not really an issue), I'm
> not convinced this is absolutely necessary to go to that extend
>
> what is really useful is to deprecate anything that is not in
> org.eclipse.aether Java package, because it is a nightmare in terms of Java
> code compatibility: this means deprecating 3.0.x only [2], given the switch to
> Eclipse Aether has been done in 3.1.0 [3]
> And, for the record, the switch to Maven Artifact Resolver has been done in
> 3.5.0 [4]
>
> Regards,
>
> Hervé
>
> [1] https://maven.apache.org/ref/3.3.9/dependency-management.html
>
> [2] https://maven.apache.org/ref/3.0.5/dependency-management.html
>
> [3] https://maven.apache.org/ref/3.1.0/dependency-management.html
>
> [4] https://maven.apache.org/ref/3.5.0-alpha-1/dependency-management.html
>
> Le jeudi 16 avril 2020, 00:22:20 CEST Manfred Moser a écrit :
> > +100
> >
> > I would deprecate everything before the maven-resolver import back to the
> > project while you are at it. Not sure exact version but 3.1x would
> > definitely on that list as well. Maybe also 3.2x
> >
> > Manfred
> >
> > Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00):
> > > Some users still use Maven 3.0.5 and they require a support for
> > > compatibility reasons between nowadays Maven plugins and the Maven
> > > 3.0.x.
> > >
> > > We have a couple of reasons to deprecate this version (JSR-330,
> > > Components injection, Logger) and we have discussed this issue in
> > > https://github.com/apache/maven-surefire/pull/274
> > >
> > > Let's discuss it.
> > >
> > > Cheers
> > > Tibor17
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Cheers
Tibor

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

Re: [CANCELLED] [VOTE] Release Apache Maven GPG Plugin version 3.0.0

[Tibor Digana]

I will open a new PR for issue 78.
Currently the issue is the $ end tag in pattern
https://github.com/apache/maven-gpg-plugin/blob/master/src/main/java/org/apache/maven/plugins/gpg/GpgVersion.java#L50
however the number of versions should be limited to e.g. 3 which is
enough.

On Thu, Apr 16, 2020 at 8:22 AM Hervé BOUTEMY  wrote:
>
> this vote is cancelled because 2 issues found on Windows, with native gpg4win
> install or Git bash pgp port
> corresponding Jira issues created:
> https://issues.apache.org/jira/browse/MGPG-78
> https://issues.apache.org/jira/browse/MGPG-79
>
> please help fixing and testing
>
> Regards,
>
> Hervé
>
> Le dimanche 12 avril 2020, 14:50:08 CEST Hervé BOUTEMY a écrit :
> > Hi,
> >
> > We solved 13 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&ve
> > rsion=12330781&styleName=Text
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1563/
> > https://repository.apache.org/content/repositories/maven-1563/org/apache/mav
> > en/plugins/maven-gpg-plugin/3.0.0/maven-gpg-plugin-3.0.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-gpg-plugin-3.0.0-source-release.zip sha512:
> > 773e1ba20d3edd6924bf7c909c0bf68746d79874a0df258da05ccc2b3138415f0183350b542
> > 09a3003eb081cc11e22bc316a7d8a7016fe4dab30eb0db5a9b0ac
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Cheers
Tibor

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

Re: Proposal to deprecate Maven 3.0.x

[Tibor Digana]

I agree with Herve to start with deprecating 3.0.x.
And what sounds nice to me is producing the plugins with 3.1 as
minimum and clearing the old code and tests for 3.0.x.
This sounds like a plan for the community.

On Thu, Apr 16, 2020 at 12:22 PM Hervé BOUTEMY  wrote:
>
> we're back at defining what our community support on every Maven parts means
>
> to me, support for Maven core releases not only means that we would release
> security bugfix if security issues were found (very low probability), but more
> that we do *extra efforts on plugins to be checked for compatibility*
>
> Maven 3.0.x costs efforts for plugins compatibility, because of the old very
> specific API
> starting with 3.1.x, API is org.eclipse.aether.*: AFAIK, no complexity to have
> plugins compatibility
>
> that's why "deprecating Maven 3.0.x" to me is a reasonable choice (lower
> community efforts with minimal users impact) that will concretely mean 
> "produce
> plugins with Maven 3.1 as minimum", cleaning old code and tests for 3.0.x
> compatibility
>
> Regards,
>
> Hervé
>
> Le jeudi 16 avril 2020, 10:41:23 CEST Tibor Digana a écrit :
> > The Eclipse Aether looks like a strong argument.
> > If any user would open an issue to provide a fix on the top of Eclipse
> > Aether then we say 'no' already today in 3.7.0.
> > So the user has to switch to 3.5.0+ which would end up for him as the
> > same as deprecating 3.0.x - 3.3.x.
> > I know that it is a big extend, i understand that but this is
> > currently the outcome of my analysis.
> >
> > I don't know what you think about this view.
> >
> > On Thu, Apr 16, 2020 at 8:52 AM Hervé BOUTEMY  wrote:
> > > +1 to deprecate 3.0.x
> > >
> > > TLDR; no need to deprecate Eclipse Aether, which would mean deprecating
> > > also 3.1.x, 3.2.x and 3.3.x
> > >
> > > details:
> > > "deprecate everything before the maven-resolver import" would mean
> > > deprecating up to 3.3.x [1]
> > >
> > > Given that maven-resolver has exactly the same API as Eclipse Aether (in
> > > org.eclipse.aether java package) but just a change in Maven coordinates
> > > (that are all filtered by Maven core class loading, then not really an
> > > issue), I'm not convinced this is absolutely necessary to go to that
> > > extend
> > >
> > > what is really useful is to deprecate anything that is not in
> > > org.eclipse.aether Java package, because it is a nightmare in terms of
> > > Java
> > > code compatibility: this means deprecating 3.0.x only [2], given the
> > > switch to Eclipse Aether has been done in 3.1.0 [3]
> > > And, for the record, the switch to Maven Artifact Resolver has been done
> > > in
> > > 3.5.0 [4]
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > [1] https://maven.apache.org/ref/3.3.9/dependency-management.html
> > >
> > > [2] https://maven.apache.org/ref/3.0.5/dependency-management.html
> > >
> > > [3] https://maven.apache.org/ref/3.1.0/dependency-management.html
> > >
> > > [4] https://maven.apache.org/ref/3.5.0-alpha-1/dependency-management.html
> > >
> > > Le jeudi 16 avril 2020, 00:22:20 CEST Manfred Moser a écrit :
> > > > +100
> > > >
> > > > I would deprecate everything before the maven-resolver import back to
> > > > the
> > > > project while you are at it. Not sure exact version but 3.1x would
> > > > definitely on that list as well. Maybe also 3.2x
> > > >
> > > > Manfred
> > > >
> > > > Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00):
> > > > > Some users still use Maven 3.0.5 and they require a support for
> > > > > compatibility reasons between nowadays Maven plugins and the Maven
> > > > > 3.0.x.
> > > > >
> > > > > We have a couple of reasons to deprecate this version (JSR-330,
> > > > > Components injection, Logger) and we have discussed this issue in
> > > > > https://github.com/apache/maven-surefire/pull/274
> > > > >
> > > > > Let's discuss it.
> > > > >
> > > > > Cheers
> > > > > Tibor17
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Cheers
Tibor

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

Re: Proposal to deprecate Maven 3.0.x

[Tibor Digana]

I want to ask a question regarding the maintenance of old minor
versions because i've started missing the right meaning of what
deprecation of Maven (not plugins) means.
Due to now we are at Maven 3.6.3 we support the bugfixing of 3.6.x
family. But AFAIK we won't suppor bugfixing of 3.5 families and
earlier. Would it mean that all versions prior to 3.6 could be
deprecated so? If they are not deprecated then the users may expect
bugfixing.

On Thu, Apr 16, 2020 at 9:06 PM Robert Scholte  wrote:
>
> The answer is 3.1.0. It is way more easier to say "plugins are Maven 3.1 or 
> 3.1.x compatible".
> The APIs are the same, there should be no impact.
> So compile with 3.1.0 dependencies, run on Jenkins with 3.1.1 (as being the 
> last 3.1.x release, like we do with all 3.x.latest)
>
> We had the same discussion when talking about 3.0 or 3.0.5, with the result: 
> plugins should be Maven 3 compatible.
>
> Also be careful with the wording:
> we're not deprecating Maven 3.0.x, but plugins will require Maven 3.1 (or 
> drop Maven 3.0 SUPPORT for plugins)
> A title like this is very misleading.
>
> Robert
> On 16-4-2020 13:01:39, Sylwester Lachiewicz  wrote:
> So next quick question - should be 3.1.0 or 3.1.1 - last and recommend
> version for Java 5?
>
> Sylwester
>
> czw., 16 kwi 2020, 12:53 użytkownik Tibor Digana
> napisał:
>
> > I agree with Herve to start with deprecating 3.0.x.
> > And what sounds nice to me is producing the plugins with 3.1 as
> > minimum and clearing the old code and tests for 3.0.x.
> > This sounds like a plan for the community.
> >
> > On Thu, Apr 16, 2020 at 12:22 PM Hervé BOUTEMY
> > wrote:
> > >
> > > we're back at defining what our community support on every Maven parts
> > means
> > >
> > > to me, support for Maven core releases not only means that we would
> > release
> > > security bugfix if security issues were found (very low probability),
> > but more
> > > that we do *extra efforts on plugins to be checked for compatibility*
> > >
> > > Maven 3.0.x costs efforts for plugins compatibility, because of the old
> > very
> > > specific API
> > > starting with 3.1.x, API is org.eclipse.aether.*: AFAIK, no complexity
> > to have
> > > plugins compatibility
> > >
> > > that's why "deprecating Maven 3.0.x" to me is a reasonable choice (lower
> > > community efforts with minimal users impact) that will concretely mean
> > "produce
> > > plugins with Maven 3.1 as minimum", cleaning old code and tests for 3.0.x
> > > compatibility
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le jeudi 16 avril 2020, 10:41:23 CEST Tibor Digana a écrit :
> > > > The Eclipse Aether looks like a strong argument.
> > > > If any user would open an issue to provide a fix on the top of Eclipse
> > > > Aether then we say 'no' already today in 3.7.0.
> > > > So the user has to switch to 3.5.0+ which would end up for him as the
> > > > same as deprecating 3.0.x - 3.3.x.
> > > > I know that it is a big extend, i understand that but this is
> > > > currently the outcome of my analysis.
> > > >
> > > > I don't know what you think about this view.
> > > >
> > > > On Thu, Apr 16, 2020 at 8:52 AM Hervé BOUTEMY
> > wrote:
> > > > > +1 to deprecate 3.0.x
> > > > >
> > > > > TLDR; no need to deprecate Eclipse Aether, which would mean
> > deprecating
> > > > > also 3.1.x, 3.2.x and 3.3.x
> > > > >
> > > > > details:
> > > > > "deprecate everything before the maven-resolver import" would mean
> > > > > deprecating up to 3.3.x [1]
> > > > >
> > > > > Given that maven-resolver has exactly the same API as Eclipse Aether
> > (in
> > > > > org.eclipse.aether java package) but just a change in Maven
> > coordinates
> > > > > (that are all filtered by Maven core class loading, then not really
> > an
> > > > > issue), I'm not convinced this is absolutely necessary to go to that
> > > > > extend
> > > > >
> > > > > what is really useful is to deprecate anything that is not in
> > > > > org.eclipse.aether Java package, because it is a nightmare in terms
> > of
> > > > > Java
> > > > > code compatibility: this means deprecating 3.0.x only [2], given

Re: [VOTE] Release Apache Maven GPG Plugin version 3.0.0

[Tibor Digana]

Hi Falko,

Can you attach the Thread dump while the GPG plugin hangs?
This would simplify our work.
Thx
T

On Wed, Apr 15, 2020 at 10:45 PM Falko Modler  wrote:
>
> Hi,
>
> I just tried to to sign the output of
> https://github.com/vackosar/gitflow-incremental-builder and I do not see
> this error.
>
> *But* the plugin simply hangs and does not continue if I use 3.0.0 after
> starting Kleopatra (https://docs.kde.org/stable5/en/pim/kleopatra/).
>
> When I first use 1.6 of the plugin after starting Kleopatra, the
> password dialog pops up (as ususal), the files are signed *and after
> this I am able to use 3.0.0 just fine!*
>
> So with 3.0.0 the initial communication with the agent seems to be broken...
>
> $ mvn -version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\_dev\Maven\latest
> Java version: 11.0.6, vendor: AdoptOpenJDK, runtime: C:\_dev\Java\latest
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> $ gpg --version
> gpg (GnuPG) 2.2.19-unknown
> libgcrypt 1.8.5
>
> Git Bash.
>
> Regards,
>
> Falko
>
> Am 15.04.2020 um 22:16 schrieb Hervé BOUTEMY:
> > questions to Windows users:
> > - what GPG distribution do you use, that does not make the plugin fail?
> > - is this issue worth dropping the release?
> >
> > Regards,
> >
> > Hervé
> >
> > Le mercredi 15 avril 2020, 21:25:11 CEST Tibor Digana a écrit :
> >> Sorry my -1 due to all integration tests have failed with the following
> >> errors:
> >>
> >> Caused by: java.lang.IllegalArgumentException: Can't parse version of
> >> gpg (GnuPG) 2.0.26 (Gpg4win 2.2.3)
> >>  at 
> >> org.apache.maven.plugins.gpg.GpgVersion.compareTo(GpgVersion.java:60)
> >> at org.apache.maven.plugins.gpg.GpgVersion.isBefore(GpgVersion.java:101) at
> >> org.apache.maven.plugins.gpg.GpgSigner.generateSignatureForFile(GpgSigner.j
> >> ava:89) at
> >> org.apache.maven.plugins.gpg.AbstractGpgSigner.generateSignatureForArtifact
> >> (AbstractGpgSigner.java:203) at
> >> org.apache.maven.plugins.gpg.GpgSignAttachedMojo.execute(GpgSignAttachedMoj
> >> o.java:178) at
> >> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildP
> >> luginManager.java:134)
> >>
> >> The version on the command line:
> >>
> >> $ gpg --version
> >> gpg (GnuPG) 2.0.26 (Gpg4win 2.2.3)
> >> libgcrypt 1.6.2
> >> Copyright (C) 2013 Free Software Foundation, Inc.
> >> License GPLv3+: GNU GPL version 3 or later
> >> <http://gnu.org/licenses/gpl.html> This is free software: you are free to
> >> change and redistribute it. There is NO WARRANTY, to the extent permitted
> >> by law.
> >>
> >> On Sun, Apr 12, 2020 at 2:50 PM Hervé BOUTEMY  
> >> wrote:
> >>> Hi,
> >>>
> >>> We solved 13 issues:
> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&;
> >>> version=12330781&styleName=Text
> >>>
> >>> Staging repo:
> >>> https://repository.apache.org/content/repositories/maven-1563/
> >>> https://repository.apache.org/content/repositories/maven-1563/org/apache/m
> >>> aven/plugins/maven-gpg-plugin/3.0.0/maven-gpg-plugin-3.0.0-source-release.
> >>> zip
> >>>
> >>> Source release checksum(s):
> >>> maven-gpg-plugin-3.0.0-source-release.zip sha512:
> >>> 773e1ba20d3edd6924bf7c909c0bf68746d79874a0df258da05ccc2b3138415f0183350b5
> >>> 4209a3003eb081cc11e22bc316a7d8a7016fe4dab30eb0db5a9b0ac
> >>>
> >>> Staging site:
> >>> https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/
> >>>
> >>> Guide to testing staged releases:
> >>> https://maven.apache.org/guides/development/guide-testing-releases.html
> >>>
> >>> Vote open for at least 72 hours.
> >>>
> >>> [ ] +1
> >>> [ ] +0
> >>> [ ] -1
> >>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Cheers
Tibor

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

Re: [VOTE] Release Apache Maven Shared Component: Maven Artifact Transfer Version 0.13.0

[Tibor Digana]

+1

On Fri, May 1, 2020 at 8:39 PM Karl Heinz Marbaise  wrote:
>
> Hi,
>
> We have solved 17 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12346567
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1570
>
> https://repository.apache.org/service/local/repositories/maven-1570/content/org/apache/maven/shared/maven-artifact-transfer/0.13.0/maven-artifact-transfer-0.13.0-source-release.zip
>
> Source release checksum(s):
> maven-artifact-transfer-0.13.0-source-release.zip sha512:
> d4a99a889f31c14c9234e744830e55a09535f21eb35125d02677de85180821c516f41f7ee914370bf432edd171f87d485a7464a4a42ccb2c192e1a92fb5d00bdtarget
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-artifact-transfer-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Cheers
Tibor

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

Re: [VOTE] Release Apache Maven Shared Component: Maven Artifact Transfer Version 0.13.0

[Tibor Digana]

I have changed to -1 after Michael's findings with broken Maven ITs.

On Sat, May 2, 2020 at 12:47 AM Michael Osipov  wrote:
>
> Am 2020-05-01 um 20:39 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > We have solved 17 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12346567
> >
> >
> > There are still a couple of issues left in JIRA:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> >
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1570
> >
> > https://repository.apache.org/service/local/repositories/maven-1570/content/org/apache/maven/shared/maven-artifact-transfer/0.13.0/maven-artifact-transfer-0.13.0-source-release.zip
> >
> >
> > Source release checksum(s):
> > maven-artifact-transfer-0.13.0-source-release.zip sha512:
> > d4a99a889f31c14c9234e744830e55a09535f21eb35125d02677de85180821c516f41f7ee914370bf432edd171f87d485a7464a4a42ccb2c192e1a92fb5d00bdtarget
> >
> >
> > Staging site:
> > https://maven.apache.org/shared-archives/maven-artifact-transfer-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
>
> Unfortunately, -1 from me.
>
> 0.13.0 suffers from the same issues as before with MNG-6556. ITs fail as
> soon as ugraded. I now breaks even more ITs:
>
> > [ERROR] Failures:
> > [ERROR] 
> > MavenITmng3843PomInheritanceTest>AbstractMavenIntegrationTestCase.runTest:222->testitMNG3843:100
> >  expected:<[2]> but was:<[1]>
> > [ERROR] Errors:
> > [ERROR] 
> > MavenITmng3372DirectInvocationOfPluginsTest>AbstractMavenIntegrationTestCase.runTest:222->testitMNG3372:65
> >  » Verification
> > [ERROR] 
> > MavenITmng3441MetadataUpdatedFromDeploymentRepositoryTest>AbstractMavenIntegrationTestCase.runTest:222->testitMNG3441:72
> >  ArrayIndexOutOfBounds
> > [ERROR] 
> > MavenITmng4660OutdatedPackagedArtifact>AbstractMavenIntegrationTestCase.runTest:222->testShouldWarnWhenPackagedArtifactIsOutdated:104
> >  » Verification
> > [ERROR] 
> > MavenITmng4660ResumeFromTest>AbstractMavenIntegrationTestCase.runTest:222->testShouldResolveOutputDirectoryFromEarlierBuild:70
> >  » Verification
> > [ERROR] 
> > MavenITmng4660ResumeFromTest>AbstractMavenIntegrationTestCase.runTest:222->testShouldResolvePackagedArtifactFromEarlierBuild:107
> >  » Verification
> > [INFO]
> > [ERROR] Tests run: 829, Failures: 1, Errors: 5, Skipped: 0
>
> How to reproduce:
> * Clone MDEPLOY and MINSTALL
> * Update Artifact Transfer
> * Install locally and into Core ITs repo
> * Clone Maven Core
> * Switch to MNG-6169/MNG-6556
> * Modify
> maven-core/src/main/resources/META-INF/plexus/default-bindings.xml by
> updating the versions of MDEPLOY and MINSTALL to 3.0.0-M2-SNAPSHOT
> * Build Maven with those changes
> * Run ITs with this build
>
> M
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Cheers
Tibor

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

[VOTE] Release Apache Maven Surefire Plugin version 2.22.3

[Tibor Digana]

Hi,

We solved 2 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12345472

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1572/
https://repository.apache.org/content/repositories/maven-1572/org/apache/maven/surefire/surefire/2.22.3/surefire-2.22.3-source-release.zip

Source release checksum(s):

surefire-2.22.3-source-release.zip sha512::
c1533ed45fd3119d028a4914ca7557acfbfea5218b5536bbafeed4b33845486b976f20b39334e2917636e3739240478ca46bd25a0dc011e5fb2aa85033e9e959
surefire-2.22.3-source-release.zip sha1:
2db957105d2929911927482c8d2198bd6ef718a7


Staging site:
N/A - we do not want to override new site with old versions 2.22.x

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

-- 
Cheers
Tibor

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

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.22.3

[Tibor Digana]

done ;-)
now it's the major issue.

On Mon, May 4, 2020 at 12:06 AM Elliotte Rusty Harold
 wrote:
>
> SUREFIRE-1556 is open and classified as a blocker:
>
> https://issues.apache.org/jira/browse/SUREFIRE-1556?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>
> If it's not truly a blocker, we should downgrade this issue.
>
>
> On Sun, May 3, 2020 at 5:44 PM Tibor Digana  wrote:
> >
> > Hi,
> >
> > We solved 2 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12345472
> >
> > There are still a couple of issues left in JIRA:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1572/
> > https://repository.apache.org/content/repositories/maven-1572/org/apache/maven/surefire/surefire/2.22.3/surefire-2.22.3-source-release.zip
> >
> > Source release checksum(s):
> >
> > surefire-2.22.3-source-release.zip sha512::
> > c1533ed45fd3119d028a4914ca7557acfbfea5218b5536bbafeed4b33845486b976f20b39334e2917636e3739240478ca46bd25a0dc011e5fb2aa85033e9e959
> > surefire-2.22.3-source-release.zip sha1:
> > 2db957105d2929911927482c8d2198bd6ef718a7
> >
> >
> > Staging site:
> > N/A - we do not want to override new site with old versions 2.22.x
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > --
> > Cheers
> > Tibor
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Cheers
Tibor

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

Windows Jenskins nodes are getting offline

[Tibor Digana]

Maybe you have noticed that Windows nodes appear offline in the Apache
Jenkins after some time.
It is not intended to switch them off but the reality is that the
power won't be fully available for your builds.
Once it happened to me that I was waiting for my build, the queue was
extremely ful, and there was one node available out of 6 Windows
nodes.
Here we should discuss what the real problem is in real and find the
solution without repeating Jira tickets.
If you see the problem in Jenkins itself, then I would say that we
have Jenkins developers in the Apache who may help.

Thx
Tibor17

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

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.22.3

[Tibor Digana]

I would go to the original question. How important is the issue [1]
for the user?
If it is not important, then we can cut the release with one fix SUREFIRE-1679.

If it is important, which does not seem so yet, then we can backport
smart resolver from the master.
Technically possible!

[1]: https://github.com/junit-team/junit5/issues/1909

On Tue, May 5, 2020 at 8:07 AM Enrico Olivelli  wrote:
>
> I would go with option 'release surefire 3.0.0'
>
>
> Enrico
>
> Il Mar 5 Mag 2020, 07:59 Romain Manni-Bucau  ha
> scritto:
>
> > Hmm, this particular one is quite hard cause (from my window which is not
> > 100% of users indeed) I see more users willing 1.6 (actually I should
> > phrase it "upgrade to last junit5 when upgrading surefire") than other
> > cases.
> > Concretely, older versions will not upgrade surefire generally.
> > I think we are "just" in a case where you encounter a bug with a release
> > policy preventing to go to 3.x and this is why you want this particular
> > case.
> > Anyone has another view of users? (point being: if we downgrade and break
> > all users not using spring boot parent we are exactly at the same point so
> > let's try to avoid that).
> >
> > So question for me is:
> >
> > 1. Do we stick to that strategy and if so which version do we pick for
> > 2.22.x and do we freeze this version?
> > 1.a. junit 5.6
> > 1.b. junit 5.3
> > 1.c junit 5.5 (aka spring-boot current one AFAIK)
> > 2. Do we backport 3.x strategy (or an enhanced flavor we do in 3.x and
> > 2.22.x)?
> > 3. Do we (just) document junit-platform* must be explicitly set in project
> > dependencies for 2.22? (side note there: doc/website of 2.22 seems no more
> > directly accessible online, is it intended since here the config is
> > different?)
> > 4. Do we just do a 3.0.0? (M4 is proven quite stable now so we could
> > mitigate coming changes which are not testing provider related I think)
> >
> > I'd be for 1 (whatever version works) or 3 since it is the least investment
> > very short term and enables to go with 4 as soon as ready.
> >
> > Hope it makes sense.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 4 mai 2020 à 20:42, Stephane Nicoll  a
> > écrit :
> >
> > > OK. With that in mind, I think the surefire plugin shouldn't require a
> > > newer version of JUnit in a maintenance release that way. I understand
> > it's
> > > fixed and can lead to problem anyway but there will be less problems if
> > you
> > > rely on an older version and backward compatiblity if a newer version is
> > > around. I think we need to weigh what that change brings vs. the impact
> > on
> > > existing users upgrading to 2.22.3
> > >
> > > On Mon, May 4, 2020 at 7:36 PM Romain Manni-Bucau  > >
> > > wrote:
> > >
> > > > Yes but with transitive game it is not well positionned in the
> > classpath
> > > > (once again not saying it is "right", just the way it was done
> > > originally)
> > > > and surefire provider dependencies win so it must be redefined to be
> > used
> > > > in 2.x.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le lun. 4 mai 2020 à 18:52, Christian Stein  a
> > > écrit :
> > > >
> > > > > On Mon, May 4, 2020 at 6:45 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Le lun. 4 mai 2020 à 18:30, Stephane Nicoll <
> > > stephane.nic...@gmail.com
> > > > >
> > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > ...
> > > > >
> > > > > > OK. Why is our build failing with that error if we're importing the
> > > > JUnit
> > > > > > > 5.5.2 bom and it does not fail if we're importing the JUnit 5.6.2
> > > > bom?
> > > > > > Our
> > > > > > > test dependencies have "junit-jupiter" in test scope which brings
> > > the
> > > > > > > engine.
> > > > > > >
> > > > > > > That looks like Surefire is using the user version to me. Anyway,
> > > if
> > > > it
> > > > > > > wasn't we wouldn't have the error above, wouldn't we?
> > > > > > >
> > > > > >
> > > > > > AFAIK you don't import junit-platform-launcher in 1.5.2 so it
> > fails.
> > > > > > So surefire uses user version but misses one dep which takes in its
> > > own
> > > > > > pom.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > https://repo.maven.apache.org/maven2/org/junit/

Re: [VOTE] Release Apache Maven Verifier version 1.7.2

[Tibor Digana]

+1, sha512 ok, build ok

On Sun, May 3, 2020 at 4:18 PM Robert Scholte  wrote:
>
> Hi,
>
> My apologies for asking for another vote on this library due to a blocking 
> issue related to Maven Wrapper.
>
> We solved 1 blocking issue:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12347858&styleName=Text
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317922%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-verifier%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1571/
> https://repository.apache.org/content/repositories/maven-1571/org/apache/maven/shared/maven-verifier/1.7.2/maven-verifier-1.7.2-source-release.zip
>
> Source release checksum(s):
> maven-verifier-1.7.2-source-release.zip sha512: 
> ff9e44a1f0d425e4564bffdcd37b04037b359d4a686dae7b5e47d5ef19d38e1b9d3668f30b47e4961e3c255c8d2731d96fa40aa9950d46a336ed93cd34a40636
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-verifier-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1



-- 
Cheers
Tibor

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

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.22.3

[Tibor Digana]

I wanted to copy paste that part of AbstractSurefireMojo which solves
this problem in this release but i was too lazy to do it.
I can do it and we can collaborate on the GitHub in a pullrequest -
the resolver's call will be different, that's the only thing, but
doable.
The code is more simple now, see this PR
https://github.com/apache/maven-surefire/pull/290 and it has more
features than before, so the users would be happy I would say.

On Tue, May 5, 2020 at 9:52 AM Stephane Nicoll
 wrote:
>
> I don't see releasing Surefire 3.0 as fixing this problem. Users having an
> upgrade policy in place would still not be able to upgrade to 3.0 anyway.
> We are talking about a backward incompatible change in a maintenance
> release of the Surefire plugin. As much as I welcome 3.0 to be GA, that
> won't change anything to what we're discussing here IMO.
>
> Cheers,
> S.
>
>
> On Tue, May 5, 2020 at 8:07 AM Enrico Olivelli  wrote:
>
> > I would go with option 'release surefire 3.0.0'
> >
> >
> > Enrico
> >
> > Il Mar 5 Mag 2020, 07:59 Romain Manni-Bucau  ha
> > scritto:
> >
> > > Hmm, this particular one is quite hard cause (from my window which is not
> > > 100% of users indeed) I see more users willing 1.6 (actually I should
> > > phrase it "upgrade to last junit5 when upgrading surefire") than other
> > > cases.
> > > Concretely, older versions will not upgrade surefire generally.
> > > I think we are "just" in a case where you encounter a bug with a release
> > > policy preventing to go to 3.x and this is why you want this particular
> > > case.
> > > Anyone has another view of users? (point being: if we downgrade and break
> > > all users not using spring boot parent we are exactly at the same point
> > so
> > > let's try to avoid that).
> > >
> > > So question for me is:
> > >
> > > 1. Do we stick to that strategy and if so which version do we pick for
> > > 2.22.x and do we freeze this version?
> > > 1.a. junit 5.6
> > > 1.b. junit 5.3
> > > 1.c junit 5.5 (aka spring-boot current one AFAIK)
> > > 2. Do we backport 3.x strategy (or an enhanced flavor we do in 3.x and
> > > 2.22.x)?
> > > 3. Do we (just) document junit-platform* must be explicitly set in
> > project
> > > dependencies for 2.22? (side note there: doc/website of 2.22 seems no
> > more
> > > directly accessible online, is it intended since here the config is
> > > different?)
> > > 4. Do we just do a 3.0.0? (M4 is proven quite stable now so we could
> > > mitigate coming changes which are not testing provider related I think)
> > >
> > > I'd be for 1 (whatever version works) or 3 since it is the least
> > investment
> > > very short term and enables to go with 4 as soon as ready.
> > >
> > > Hope it makes sense.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 4 mai 2020 à 20:42, Stephane Nicoll 
> > a
> > > écrit :
> > >
> > > > OK. With that in mind, I think the surefire plugin shouldn't require a
> > > > newer version of JUnit in a maintenance release that way. I understand
> > > it's
> > > > fixed and can lead to problem anyway but there will be less problems if
> > > you
> > > > rely on an older version and backward compatiblity if a newer version
> > is
> > > > around. I think we need to weigh what that change brings vs. the impact
> > > on
> > > > existing users upgrading to 2.22.3
> > > >
> > > > On Mon, May 4, 2020 at 7:36 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Yes but with transitive game it is not well positionned in the
> > > classpath
> > > > > (once again not saying it is "right", just the way it was done
> > > > originally)
> > > > > and surefire provider dependencies win so it must be redefined to be
> > > used
> > > > > in 2.x.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book
> > > > > <
> > > > >
> > > >
> > >
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > >
> > > > >
> > > > >
> > > > > Le lun. 4 mai 2020 à 18:52, Christian Stein  a
> > > > écrit :
> > > > >
> > > > > > On Mon, May 4, 2020 at 6:45 PM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Le lun. 4 mai 2020 à 18:30, Stephane Nicoll <
> > > > stephane.nic...@gmail.com
> > > > > >
> > > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > ...
> > > > > >
> > > > > > > O

Re: JDK 8 Minimum Requirement for Maven Resolver 2.0

[Tibor Digana]

The code written in j8 looks more compact. The loops and annonymous classes
with one method do not waste the code lines.

You can create a branch for the Maven Resolver 2.0 and the later Maven can
use it.

Do we need to have Maven Resolver 2.0 in the Maven 3.7.0?
The Maven 3.7.0 is @j8 and using Resolver 1.4.2.
What changes you expect in Maven Resolver 2.0? If it is only Java 1.8 *code
*then it should be no problem except the performance of some Streams.

Probably the Maven Resolver 2.0 would be used in 3.7.1 or 3.8.0. But if the
Maven 3.7.0 is @j8 then using Resolver 2.0@j8 should not harm the Maven.
The older versions of Resolver can continue the development in branches.
Everything would have a permanent progress and we don't have to stop
somewhere in the master.


On Sat, May 9, 2020 at 10:13 PM Sylwester Lachiewicz 
wrote:

> Hi to all,
>
> based on the previous vote to require Java 8 for Maven Core - I would like
> to propose setting the same minimum for Maven Resolver 2.0
>
> Maven Resolver is a base component to solve dependencies for Maven. It can
> also be used separately from Maven for other projects.
> Because Java 7 updates are no longer available, the market is also moving
> towards using the newer version of Java 8/11.
> Practically the Core requirement means that Resolver has little chance of
> being used in Java 7 (see tricks to connect to Central).
>
> Benefits - more programmers can practice coding while improving our
> codebase.
>
> What's your opinion on the subject?
>
> https://maven.apache.org/resolver/
>
> Kind regards
> Sylwester
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.22.3

[Tibor Digana]

Thank you for participating. The Vote is cancelled.

On Sun, May 3, 2020 at 11:44 PM Tibor Digana  wrote:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12345472
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1572/
>
> https://repository.apache.org/content/repositories/maven-1572/org/apache/maven/surefire/surefire/2.22.3/surefire-2.22.3-source-release.zip
>
> Source release checksum(s):
>
> surefire-2.22.3-source-release.zip sha512::
>
> c1533ed45fd3119d028a4914ca7557acfbfea5218b5536bbafeed4b33845486b976f20b39334e2917636e3739240478ca46bd25a0dc011e5fb2aa85033e9e959
> surefire-2.22.3-source-release.zip sha1:
> 2db957105d2929911927482c8d2198bd6ef718a7
>
>
> Staging site:
> N/A - we do not want to override new site with old versions 2.22.x
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Cheers
> Tibor
>

[CANCELLED] [VOTE] Release Apache Maven Surefire Plugin version 2.22.3

[Tibor Digana]

Hi,

I am cancelling the vote due to an issue we found.

-- 
Cheers
Tibor

Re: Merging via GitHub

[Tibor Digana]

This probably happens when the committer has pressed "Squash and merge". I
expect it does not rebase.
But when you press "Rebase and merge" then the commits would be rebased on
the HEAD but it does not squash the commits to one.

So you have to check the parent commit. If it is old then the contributor
has to squash all his commits and the committer will push "Rebase and
merge".
This would work.
If the parent is the HEAD commit then it should not be a problem to "Squash
and merge".


On Mon, May 11, 2020 at 10:42 PM Michael Osipov  wrote:

> Folks,
>
> please do NOT merge via merge button in GitHub:
>
> > commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master,
> origin/HEAD)
> > Merge: 34253e3d f7de3a6e
> > Author: Elliotte Rusty Harold 
> > Commit: GitHub 
> >
> > Merge pull request #66 from apache/plex
> >
> > [SCM-930] update plexus-utils
> >
> > commit f7de3a6ea5e182d7fab28e8f0548da2324097ba9
> > Author: Elliotte Rusty Harold 
> > Commit: Elliotte Rusty Harold 
> >
> > update plexus-utils
>
> 1. It produces useless merge commits
> 2. GitHub is NOT a blessed committer
>
> It is OK, wenn a clean rebased merge is performed and not traces of
> GitHub are left.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Merging via GitHub

[Tibor Digana]

I have checked it out with all three enabled in [1] but i still see the
same number of buttons as before. How it should behave?
I would like to have the rebase even in the squash but the comment above
the "rebase: true" says "button" and not a "behavior" in another buttons
e.g, "Squash and merge".

[1]: https://github.com/apache/maven-surefire/pull/295

On Tue, May 12, 2020 at 12:28 PM Hervé BOUTEMY 
wrote:

> it can be configured at ASF with .asf.yaml setting:
>
> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Mergebuttons
>
> Le mardi 12 mai 2020, 00:45:31 CEST David Jencks a écrit :
> > It's possible to configure GitHub to allow rebase and merge, which I
> think
> > is what you want.  It may be possible to configure GitHub to only allow
> > this.  I’m not sure if this is something infra has to do or if a project
> > admin can set it up.  Camel recently made a related change.
> >
> > David Jencks
> >
> > > On May 11, 2020, at 3:23 PM, Benson Margulies 
> > > wrote:
> > >
> > > Could you send me a pointer to refresh my memory on procedures? It's
> been
> > > a
> > > while ...
> > >
> > > On Mon, May 11, 2020 at 1:42 PM Michael Osipov 
> wrote:
> > >> Folks,
> > >>
> > >> please do NOT merge via merge button in GitHub:
> > >>> commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master,
> > >>
> > >> origin/HEAD)
> > >>
> > >>> Merge: 34253e3d f7de3a6e
> > >>> Author: Elliotte Rusty Harold 
> > >>> Commit: GitHub 
> > >>>
> > >>>Merge pull request #66 from apache/plex
> > >>>
> > >>>[SCM-930] update plexus-utils
> > >>>
> > >>> commit f7de3a6ea5e182d7fab28e8f0548da2324097ba9
> > >>> Author: Elliotte Rusty Harold 
> > >>> Commit: Elliotte Rusty Harold 
> > >>>
> > >>>update plexus-utils
> > >>
> > >> 1. It produces useless merge commits
> > >> 2. GitHub is NOT a blessed committer
> > >>
> > >> It is OK, wenn a clean rebased merge is performed and not traces of
> > >> GitHub are left.
> > >>
> > >> Michael
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven EJB Plugin version 3.1.0

[Tibor Digana]

+1


Dňa pi 12. 6. 2020, 10:22 Olivier Lamy  napísal(a):

> +1
>
> On Fri, 12 Jun 2020 at 16:10, Hervé BOUTEMY  wrote:
>
> > Le mercredi 10 juin 2020, 07:35:51 CEST Hervé BOUTEMY a écrit :
> > > I need more votes, please
> > ping?
> >
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le dimanche 7 juin 2020, 18:26:43 CEST Hervé BOUTEMY a écrit :
> > > > Hi,
> > > >
> > > > We solved 7 issues:
> > > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317421&;
> > > > ve rsion=12343161&styleName=Text
> > > >
> > > > Staging repo:
> > > > https://repository.apache.org/content/repositories/maven-1588/
> > > >
> >
> https://repository.apache.org/content/repositories/maven-1588/org/apache/m
> > > > av
> > > >
> > en/plugins/maven-ejb-plugin/3.1.0/maven-ejb-plugin-3.1.0-source-release.z
> > > > ip
> > > >
> > > > Source release checksum(s):
> > > > maven-ejb-plugin-3.1.0-source-release.zip.sha512 sha512:
> > > >
> >
> c6f2de1f10222e50ebf1c4991d91aa468749727d1214024caaef21e3ca4bf42523450ebaa3
> > > > c
> > > > bfe40ec1e948b68c1a1ecea484bb2d5ce979a61cbbae64e074698
> > > >
> > > > Staging site:
> > > > https://maven.apache.org/plugins-archives/maven-ejb-plugin-LATEST/
> > > >
> > > > Guide to testing staged releases:
> > > >
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> > > >
> > > > Vote open for at least 72 hours.
> > > >
> > > > [ ] +1
> > > > [ ] +0
> > > > [ ] -1
> > > >
> > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

[VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M5

[Tibor Digana]

Hi,

We solved 40 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12344612

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1590/
https://repository.apache.org/content/repositories/maven-1590/org/apache/maven/surefire/surefire/3.0.0-M5/surefire-3.0.0-M5-source-release.zip

Source release checksum(s):
surefire-3.0.0-M5-source-release.zip  sha1:
687a89ceb4a1b2e5dd472deec8d3843f2a98b68f
surefire-3.0.0-M5-source-release.zip  sha512:
e88ced058923b349acfe1948d4c4a7ff6f4bef08e5685f2f2ac73cfb26ad35fd6578f05309f091081f01986b19bbca38a2fe6bf0fbd16980cd6f41228c529ee7

Staging site:
http://maven.apache.org/surefire-archives/surefire-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Cheers
Tibor

Re: Suggestion: announce Maven 3.0.x is EOL

[Tibor Digana]

Thx that you have made this.
yes, i also understood a general acceptance of this proposal.
let's push this soon.

On Sat, Jun 13, 2020 at 5:26 PM Elliotte Rusty Harold 
wrote:

> I think we've achieved consensus that Maven 3.0.x should no longer be
> supported by new plugin releases and 3.1.x is our minimum. Assuming
> that's true, this PR updates the history page to account for that:
>
> https://github.com/apache/maven-site/pull/176
>
> If anyone thinks we have not achieved consensus, or should not
> announce that 3.0.x is end of life, please say so.
>
> As always, please also comment on exact language of the PR, markup
> syntax, and other pages that need to be updated. Thanks.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M5

[Tibor Digana]

Yes, thank you Enrico.

After a long time, we found a good reason to fix annoying issues which
requires reworking some parts of the code. And also we were able to let the
users use their implementation without asking us in Apache.
We touched the milestone release where we could introduce the feature and
let the people enable a new functionality.

Maybe you guys know that the Surefire and Failsafe plugins were using
std/in and std/out (pipes) as interprocess communication between Maven
process and forked JVM.
Often the users, especially the OSGi users, claimed that these pipes should
be used by the tests.
Additionally, there was a request, from one of our users at GitHub, that
the Surefire fork VMs should be capable of distributing the load in
horizontal direction (hardware) which would first of all require a new
abstraction and communication facilities.
Today we are able to accomplish this!

We have introduced an abstraction which allows the users to implement their
own communication facilities for their purposes.
Of course, we provided two internal implementations.
One defaults to the traditional pipes, and the second is using TCP/IP
channels with authentication.
The second implementation is especially interesting because you can enable
a new way of communication using the TCP sockets:




The std/out and std/err would be ready for use in your tests.
One may ask, why we did not enable this TCP/IP channel by default.
We want to let the users adapt first and check it out.
Feel free to let us know about your findings.

This approach gave you a certain freedom. For instance you can configure
your extension.
In the future we may introduce "bindAddress" in SurefireForkNodeFactory but
this can be also done by the user:



192.168.10.15


In the references you can find the documentation to the Extension API and
SPI.
This may help you out on implementing your own extensions.

References:
https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/site/apt/examples/process-communication.vm






On Sat, Jun 13, 2020 at 9:15 PM Enrico Olivelli  wrote:

> (I will cast my final vote on Monday)
> Tibor
> It is worth to note that this release includes the new communication
> protocol between Maven and the forked JVM.
> Can you please share a bit of help about how to try it?
>
> This is a great release of surefire, it is a big milestone for Maven and
> Surefire
>
>
> Enrico
>
> Il Sab 13 Giu 2020, 20:50 Michael Osipov  ha scritto:
>
> > Am 2020-06-13 um 15:46 schrieb Tibor Digana:
> > > Hi,
> > >
> > > We solved 40 issues:
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12344612
> > >
> > > There are still a couple of issues left in JIRA:
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1590/
> > >
> >
> https://repository.apache.org/content/repositories/maven-1590/org/apache/maven/surefire/surefire/3.0.0-M5/surefire-3.0.0-M5-source-release.zip
> > >
> > > Source release checksum(s):
> > > surefire-3.0.0-M5-source-release.zip  sha1:
> > > 687a89ceb4a1b2e5dd472deec8d3843f2a98b68f
> > > surefire-3.0.0-M5-source-release.zip  sha512:
> > >
> >
> e88ced058923b349acfe1948d4c4a7ff6f4bef08e5685f2f2ac73cfb26ad35fd6578f05309f091081f01986b19bbca38a2fe6bf0fbd16980cd6f41228c529ee7
> > >
> > > Staging site:
> > > http://maven.apache.org/surefire-archives/surefire-LATEST/
> > >
> > > Guide to testing staged releases:
> > > http://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for 72 hours.
> >
> > Massive and impressive!
> >
> > +1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M5

[Tibor Digana]

A big "Thank You" goes to our user and contributor Jonathan Bell who is
Assistant Professor at the George Mason University, his students, and our
Apache colleague Enrico Olivelli.
Of course a big "Thank You" goes to our Apache Maven team.

Along we speeded up the plugin with short startup and teardown time of
forked JVM. We made faster communication on the TCP level and process pipes
level as well.

Additionally, we improved smart resolver of JUnit5 Engines and fixed some
issues, see
https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm
Regarding the JPMS, now the users can have "module-info.java" in
src/test/java. Here the user should be more careful if the module
descriptor was used in his project due to the behavior is determined by
this descriptor. For more information, see
https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/site/apt/examples/jpms.apt.vm

On Sat, Jun 13, 2020 at 10:02 PM Tibor Digana 
wrote:

> Yes, thank you Enrico.
>
> After a long time, we found a good reason to fix annoying issues which
> requires reworking some parts of the code. And also we were able to let the
> users use their implementation without asking us in Apache.
> We touched the milestone release where we could introduce the feature and
> let the people enable a new functionality.
>
> Maybe you guys know that the Surefire and Failsafe plugins were using
> std/in and std/out (pipes) as interprocess communication between Maven
> process and forked JVM.
> Often the users, especially the OSGi users, claimed that these pipes
> should be used by the tests.
> Additionally, there was a request, from one of our users at GitHub, that
> the Surefire fork VMs should be capable of distributing the load in
> horizontal direction (hardware) which would first of all require a new
> abstraction and communication facilities.
> Today we are able to accomplish this!
>
> We have introduced an abstraction which allows the users to implement
> their own communication facilities for their purposes.
> Of course, we provided two internal implementations.
> One defaults to the traditional pipes, and the second is using TCP/IP
> channels with authentication.
> The second implementation is especially interesting because you can enable
> a new way of communication using the TCP sockets:
>
>  implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>
>
>
> The std/out and std/err would be ready for use in your tests.
> One may ask, why we did not enable this TCP/IP channel by default.
> We want to let the users adapt first and check it out.
> Feel free to let us know about your findings.
>
> This approach gave you a certain freedom. For instance you can configure
> your extension.
> In the future we may introduce "bindAddress" in SurefireForkNodeFactory
> but this can be also done by the user:
>
>  implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory">
>
> 192.168.10.15
> 
>
> In the references you can find the documentation to the Extension API and
> SPI.
> This may help you out on implementing your own extensions.
>
> References:
>
> https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/site/apt/examples/process-communication.vm
>
>
>
>
>
>
> On Sat, Jun 13, 2020 at 9:15 PM Enrico Olivelli 
> wrote:
>
>> (I will cast my final vote on Monday)
>> Tibor
>> It is worth to note that this release includes the new communication
>> protocol between Maven and the forked JVM.
>> Can you please share a bit of help about how to try it?
>>
>> This is a great release of surefire, it is a big milestone for Maven and
>> Surefire
>>
>>
>> Enrico
>>
>> Il Sab 13 Giu 2020, 20:50 Michael Osipov  ha
>> scritto:
>>
>> > Am 2020-06-13 um 15:46 schrieb Tibor Digana:
>> > > Hi,
>> > >
>> > > We solved 40 issues:
>> > >
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12344612
>> > >
>> > > There are still a couple of issues left in JIRA:
>> > >
>> >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>> > >
>> > > Staging repo:
>> > > https://repository.apache.org/content/repositories/maven-1590/
>> > >
>> >
>> https://repository.apache.org/content/repositories/maven-1590/org/apache/maven/surefire/surefire/3.0.0-M5/surefire-3.0.0-M5-source-release.zip
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M5

[Tibor Digana]

Hi Herve,

We can fork the discussion about this problem apart in the Slack.
Thx for finding this.

T


On Sat, Jun 13, 2020 at 9:35 PM Hervé BOUTEMY  wrote:

> +1
>
> near full reproducibility of reference artifacts with JDK 8 on Windows: 48
> artifacts are ok, just 2 still have issues:
> - surefire-3.0.0-M5-source-release.zip: I don't know why my local build
> added 3 dependency-reduced-pom.xml that do not exist in reference build
> - surefire-shadefire-3.0.0-M5.jar: some strange timestamp issues for some
> shaded content, probably a subtle maven-shade-plugin bug
>
> Regards,
>
> Hervé
>
> Le samedi 13 juin 2020, 15:46:10 CEST Tibor Digana a écrit :
> > Hi,
> >
> > We solved 40 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&ve
> > rsion=12344612
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20
> > status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1590/
> >
> https://repository.apache.org/content/repositories/maven-1590/org/apache/mav
> > en/surefire/surefire/3.0.0-M5/surefire-3.0.0-M5-source-release.zip
> >
> > Source release checksum(s):
> > surefire-3.0.0-M5-source-release.zip  sha1:
> > 687a89ceb4a1b2e5dd472deec8d3843f2a98b68f
> > surefire-3.0.0-M5-source-release.zip  sha512:
> >
> e88ced058923b349acfe1948d4c4a7ff6f4bef08e5685f2f2ac73cfb26ad35fd6578f05309f0
> > 91081f01986b19bbca38a2fe6bf0fbd16980cd6f41228c529ee7
> >
> > Staging site:
> > http://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Cheers
> > Tibor
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: VOTE] Release Apache Maven Reporting Exec version 1.5.1

[Tibor Digana]

+1


On Tue, Jun 16, 2020 at 10:03 PM Hervé BOUTEMY 
wrote:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12348384&styleName=Text
> in addition to 4 issues from cancelled 1.5:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12341774&styleName=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1591/
>
> https://repository.apache.org/content/repositories/maven-1591/org/apache/maven/reporting/maven-reporting-exec/1.5.1/maven-reporting-exec-1.5.1-source-release.zip
>
> Source release checksum(s):
> maven-reporting-exec-1.5.1-source-release.zip sha512:
> d5b2e52458179ed0534abd2cd5b604890a1caa1d74d26970636e968b7dba625029666c2131004c08794535a36e4291ac4a42000b4990e7a8d3218b3cb0550857
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-reporting-exec-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M5

[Tibor Digana]

+1


On Sat, Jun 13, 2020 at 3:46 PM Tibor Digana  wrote:

> Hi,
>
> We solved 40 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12344612
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1590/
>
> https://repository.apache.org/content/repositories/maven-1590/org/apache/maven/surefire/surefire/3.0.0-M5/surefire-3.0.0-M5-source-release.zip
>
> Source release checksum(s):
> surefire-3.0.0-M5-source-release.zip  sha1:
> 687a89ceb4a1b2e5dd472deec8d3843f2a98b68f
> surefire-3.0.0-M5-source-release.zip  sha512:
> e88ced058923b349acfe1948d4c4a7ff6f4bef08e5685f2f2ac73cfb26ad35fd6578f05309f091081f01986b19bbca38a2fe6bf0fbd16980cd6f41228c529ee7
>
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers
> Tibor
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M5

[Tibor Digana]

Thank you, the vote has finished.
+1 : Romain Manni-Bucau, Michael Opsipov, Hervé BOUTEMY, Dan Tran, Enrico
Olivelli, Tibor Digana
  0 : none
-1 : none.

On Tue, Jun 16, 2020 at 11:50 PM Tibor Digana 
wrote:

> +1
>
>
> On Sat, Jun 13, 2020 at 3:46 PM Tibor Digana 
> wrote:
>
>> Hi,
>>
>> We solved 40 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12344612
>>
>> There are still a couple of issues left in JIRA:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1590/
>>
>> https://repository.apache.org/content/repositories/maven-1590/org/apache/maven/surefire/surefire/3.0.0-M5/surefire-3.0.0-M5-source-release.zip
>>
>> Source release checksum(s):
>> surefire-3.0.0-M5-source-release.zip  sha1:
>> 687a89ceb4a1b2e5dd472deec8d3843f2a98b68f
>> surefire-3.0.0-M5-source-release.zip  sha512:
>> e88ced058923b349acfe1948d4c4a7ff6f4bef08e5685f2f2ac73cfb26ad35fd6578f05309f091081f01986b19bbca38a2fe6bf0fbd16980cd6f41228c529ee7
>>
>> Staging site:
>> http://maven.apache.org/surefire-archives/surefire-LATEST/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Cheers
>> Tibor
>>
>

[RESULT] [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M5

[Tibor Digana]

Hi,

The vote has passed with the following result:

+1 : Romain Manni-Bucau, Michael Opsipov, Hervé BOUTEMY, Dan Tran, Enrico
Olivelli, Tibor Digana
  0 : none
-1 : none.

PMC quorum: accomplished.
I will promote the artifacts to the central repo.

[ANN] Apache Maven Surefire Plugin 3.0.0-M5 Released

[Tibor Digana]

The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire Plugin, version 3.0.0-M5.

The release contains 40 bug fixes.
Again we received contributions from the community in the form of bug
reports and bug fixes.
Thank you and keep them coming!

http://maven.apache.org/plugins/maven-surefire-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-surefire-plugin
  3.0.0-M5


or for failsafe:


  org.apache.maven.plugins
  maven-failsafe-plugin
  3.0.0-M5


or for surefire-report:


  org.apache.maven.plugins
  maven-surefire-report-plugin
  3.0.0-M5



You can download the appropriate sources etc. from the download page:
https://maven.apache.org/surefire/download.cgi

Release Notes - Maven Surefire - Version 3.0.0-M5


Bug

   - [SUREFIRE-1570 ]
   - Maven-fail-safe doesn't put testing JPMS module on module path
   - [SUREFIRE-1695 ]
   - Support multiple inheritance of @Categories
   - [SUREFIRE-1719 ]
   - Race condition results in "VM crash or System.exit called?" failure
   - [SUREFIRE-1721 ]
   - fixed typo in JavaDoc for Failsafe: mvn test
   -Dsurefire.enableProcessChecker=all
   - [SUREFIRE-1725 ]
   - Surefire in JUnit Vintage mode distributes tests very unevenly between
   forks, causing poor parallelism
   - [SUREFIRE-1741 ]
   - Exceptions in parameterized test sources are ignored
   - [SUREFIRE-1746 ]
   - Dependencies for dynamic provider contain Maven artifacts from the MOJO
   plugin
   - [SUREFIRE-1748 ]
   - JUnit 5 Assertions.fail() breaks reporting
   - [SUREFIRE-1749 ]
   - Correct useSystemClassloader used in message
   - [SUREFIRE-1759 ]
   - NullPointerException from RunEntryStatisticsMap#serialize when there's a
   class-level @Ignore annotation
   - [SUREFIRE-1762 ]
   - skipAfterFailureCount>0 with testng 7.1.0 resulting in
   java.lang.NoSuchMethodError:
   org.testng.TestNG.addListener(Lorg/testng/ITestListener;)V
   - [SUREFIRE-1782 ]
   - Configured Environment Variables do not take effect unless also added to
   excludedEnvironmentVariables
   - [SUREFIRE-1783 ]
   - Fork JVM defined by Toolchain should not inherit JAVA_HOME from Maven
   process
   - [SUREFIRE-1784 ]
   - Fork JVM defined by jvm parameter should not inherit JAVA_HOME from Maven
   process
   - [SUREFIRE-1797 ]
   - Surefire report with parameterized tests contain all names of test the
   same

New Feature

   - [SUREFIRE-1234 ]
   - Allow to configure JVM for tests by referencing a toolchain entry
   - [SUREFIRE-1516 ]
   - Should surefire specialize test runner when test isolation (i.e., fork)
   is needed?
   - [SUREFIRE-1658 ]
   - TCP/IP Channel for forked Surefire JVM. Extensions API and SPI.
   Polymorphism for remote and local process communication.
   - [SUREFIRE-1744 ]
   - Enable system-out for successfully passed tests as well
   - [SUREFIRE-1766 ]
   - Surefire does not display TestNG data provider values on command line

Improvement

   - [SUREFIRE-1378 ]
   - Nice to have systemPropertiesFile configurable by user property
   - [SUREFIRE-1728 ]
   - maven.test.failure.ignore: differentiate between test failure and timeout
   - [SUREFIRE-1729 ]
   - Run Order / JUnit5 supported in the Feature Matrix + tests
   - [SUREFIRE-1733 ]
   - Surefire and Failsafe JPMS additions for JUnit 5.x execution
   - [SUREFIRE-1740 ]
   - Prerequisite implementation for SUREFIRE-1658
   - [SUREFIRE-1758 ]
   - JUnit Platform provider isn't mentioned in the docu about groups and
   excludeGroups
   - [SUREFIRE-1770 ]

Re: custom default lifecycle per project

[Tibor Digana]

Hi Romain,

Do you expect another phases (life cycle) for specific technologies or
packaging.
What phases would you expect in case of frontend technologies, e.g.
JavaScript-like Angular, ReactJS, Vue?
What phases in case of scrip-like technologies and native technologies?
Should these phases be hardcoded alternatives? Or a customizable life cycle?

Cheers
T


On Sat, Jul 4, 2020 at 6:09 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau 
> wrote:
>
> > Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> a écrit :
> >
> > > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau 
> > > wrote:
> > >
> > > > Well, there are two points I'd like to emphasis:
> > > >
> > > > 1. I dont think we should wait for 2 majors to get that as a feature,
> > > would
> > > > be too late IMHO
> > >
> > >
> > > Well does my dynamic phases PR do what you need?
> > >
> >
> > Partly if you think to priority one, it moves the issue a bit further due
> > to priority usage which is not great in practice compare to names +
> > requires to use 100, 200 etc to be able to inject plugin between two
> others
> > in children with the project becoming more complex. Think we must have an
> > explicit control here even with complex hierarchies.
>
>
> If you need that much control then you’re doing something wrong.
>
> How often do you need more than 3-4 plugin executions in strict ordered
> succession?
>
> That sounds like a dedicated plugin use case
>
> >
> >
> >
> > >
> > > > 2. Pom model is based on inheritance whereas years showed composition
> > and
> > > > reuse is saner so IMHO it does not belong to pom but .mvn
> > >
> > >
> > > Your proposal would only work if all projects shared the same packaging
> > as
> > > Hervé pointed out that the lifecycle is pulled in based on packaging.
> > >
> >
> > No cause you define the packaging to use in  the pom already - since
> maven
> > 2 IIRC - so you can define as much packagings as you want in .mvn. To be
> > concrete, it just enables to have an exploded extension in the project
> > instead of requiring it to be packaged as a jar. Does not reinvent the
> > wheel ;).
> >
> >
> > > What you probably want is .mvn/${packaging}/lifecycle.xml so you can
> > > override custom
> > >
> > > A bug you may encounter is where phase names are not common across the
> > > reactor
> > >
> >
> > Yep, build/extension must enforce common checkpoints (package, install,
> > deploy out of my head) for all modules. Not a big deal if validated
> during
> > initialize phase I think.
> >
> >
> > >
> > > >
> > > > Le sam. 4 juil. 2020 à 10:19, Robert Scholte 
> a
> > > > écrit :
> > > >
> > > > > Stephen had an idea for it in Model 5.0.0[1], and IIRC I still had
> my
> > > > > concerns.
> > > > > It is still a draft with a lot of ideas, that hasn't really been
> > > > discussed
> > > > > yet, because it was still out of reach.
> > > > > However, we're getting closer
> > > > >
> > > > > Robert
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0#POMModelVersion5.0.0-%3Cproject%3Eelement
> > > > > On 4-7-2020 09:03:08, Romain Manni-Bucau 
> > > wrote:
> > > > > I agree I mixed both in my explanationcause they only make
> sense
> > > > > together for a build as shown by the pre/post recurrent request
> which
> > > > aims
> > > > > to enrich the lifecycle to bind custom plugins.
> > > > >
> > > > > Today projects are no more just about creating a jar - war are no
> > more
> > > > > about java etc... - most of the time (frontend, living doc, build
> > time
> > > > > generation, security validation, ). Indeed you can force to
> bind
> > > > > plugins to existing phases but it is quite hard, unatural and
> rarely
> > > > > maintainable in time: whatever you do, you want a custom packaging
> > > using
> > > > a
> > > > > custom lifecycle (to be able to run separately phases of the build
> -
> > > and
> > > > > sometimes independently, mvn frontend not depending of mvn package
> or
> > > mvn
> > > > > compile would be neat but not required for me).
> > > > >
> > > > > So the extension i have in mind will handle both or wouldnt be
> > usable.
> > > > >
> > > > > About loosing the convention, after fighting for 7 years to not
> > respect
> > > > it,
> > > > > I think the ecosystem changed and we must accept it as bazel and
> > gradle
> > > > do.
> > > > > Does not mean we break ourself, we keep our default, it just means
> an
> > > > > application must be able to redefining its own lifecycle+packaging
> > > (which
> > > > > is a pair named a build ;)).
> > > > >
> > > > > Think we can't stack plugin on a single phase anymore, having 5+
> > > plugins
> > > > on
> > > > > pre-package is very hard to maintain and share in a team - plus it
> > > doesnt
> > > > > really makes sense on a build point of view.
> > > > >
> > > > > Indeed we can add phases as we hav

Re: surefire M6?

[Tibor Digana]

If you guys mean the improvements seriously then we have to work on a PR
together. But this work is not for one hour. I am mainly repairing the unit
tests in the late evenings when I am watching the TV. So this is my daily
workflow.

The logs are flushed when BufferedOutputStream overflows, this means 64KB
buffer or when some control event is emitted. This makes such an effect on
the console that a big batch of logs suddenly appear.

Currently I am merging SUREFIRE-1809 which is in the interest of Camel and
Quarkus projects. Also a blocker issue which has however the workaround.



On Wed, Jul 8, 2020 at 9:07 AM Romain Manni-Bucau 
wrote:

> +1 perf and lost of output flushing are big drawbacks we should fix asap
> without regression (reverting m5 upgrade to m4 brings other issues)
>
> Le mer. 8 juil. 2020 à 07:32, Enrico Olivelli  a
> écrit :
>
> > Olivier,
> > If it is only a matter of doing the release I can pack it today or
> tomorrow
> > (not Friday).
> >
> > What's the status of master branch? I mean, are there any other blocker
> > issues waiting for fix or for review?
> >
> > Enrico
> >
> > Il Mer 8 Lug 2020, 01:40 Falko Modler  ha scritto:
> >
> > > Hi Oliver,
> > >
> > > which performance issue do you mean?
> > >
> > > I was actually hoping to revive
> > > https://github.com/apache/maven-surefire/pull/169 for M6 but I haven't
> > > had time thus far.
> > >
> > > Cheers,
> > >
> > > Falko
> > >
> > > Am 08.07.2020 um 00:38 schrieb Olivier Lamy:
> > > > Hi,
> > > > I wonder if there is a plan to release M6 ASAP with the performance
> > issue
> > > > fixed?
> > > > TBH M5 is definitely NOT usable but it contains some interesting
> fixes
> > > but
> > > > performance is awful.
> > > > I'm definitely happy to help.
> > > > let me know.
> > > >
> > > > cheers
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Re: surefire M6?

[Tibor Digana]

@Romain it is very strange that the internal person says that you want to
revise the existence of Surefire and also we have a colleague Christian who
creates a competitor plugin and again an internal new person, very strange.
Btw using the exec plugin would make the users unhappy. And in my
experiences with the users, they consider the Surefire as part of Maven
because it is part of it.

Regarding the Scala testing it is not true, as you said, that
scalatest-maven-plugin is popular. No! Another build process is popular, it
is SBT.
And there was one more plugin you mentioned but it is 6 years out of
maintenance, i do not remember the name of that plugin.

On Wed, Jul 8, 2020 at 1:58 PM Romain Manni-Bucau 
wrote:

> https://github.com/apache/maven-surefire/pull/305 mitigates the flush
> issue
> - understand it solves the user blocker but brings a new config which can
> be outdated in another milestone (not a big deal, milestones are there for
> that too IMHO) - but a clean solution is indeed to just be aligned on
> server flushing (doable wrapping the buffer itself) or just not needing it
> as it was in 2.x thanks to process piping.
>
> Long term we should revise surefire responsibilities IMHO because today it
> is trivial to supersede it with an exec-maven-plugin execution (you only
> lose maven site integration but gain in simplicity and site integration is
> not that much used today outside commons projects I think).
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 8 juil. 2020 à 13:42, Tibor Digana  a
> écrit :
>
> > If you guys mean the improvements seriously then we have to work on a PR
> > together. But this work is not for one hour. I am mainly repairing the
> unit
> > tests in the late evenings when I am watching the TV. So this is my daily
> > workflow.
> >
> > The logs are flushed when BufferedOutputStream overflows, this means 64KB
> > buffer or when some control event is emitted. This makes such an effect
> on
> > the console that a big batch of logs suddenly appear.
> >
> > Currently I am merging SUREFIRE-1809 which is in the interest of Camel
> and
> > Quarkus projects. Also a blocker issue which has however the workaround.
> >
> >
> >
> > On Wed, Jul 8, 2020 at 9:07 AM Romain Manni-Bucau  >
> > wrote:
> >
> > > +1 perf and lost of output flushing are big drawbacks we should fix
> asap
> > > without regression (reverting m5 upgrade to m4 brings other issues)
> > >
> > > Le mer. 8 juil. 2020 à 07:32, Enrico Olivelli  a
> > > écrit :
> > >
> > > > Olivier,
> > > > If it is only a matter of doing the release I can pack it today or
> > > tomorrow
> > > > (not Friday).
> > > >
> > > > What's the status of master branch? I mean, are there any other
> blocker
> > > > issues waiting for fix or for review?
> > > >
> > > > Enrico
> > > >
> > > > Il Mer 8 Lug 2020, 01:40 Falko Modler  ha scritto:
> > > >
> > > > > Hi Oliver,
> > > > >
> > > > > which performance issue do you mean?
> > > > >
> > > > > I was actually hoping to revive
> > > > > https://github.com/apache/maven-surefire/pull/169 for M6 but I
> > haven't
> > > > > had time thus far.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Falko
> > > > >
> > > > > Am 08.07.2020 um 00:38 schrieb Olivier Lamy:
> > > > > > Hi,
> > > > > > I wonder if there is a plan to release M6 ASAP with the
> performance
> > > > issue
> > > > > > fixed?
> > > > > > TBH M5 is definitely NOT usable but it contains some interesting
> > > fixes
> > > > > but
> > > > > > performance is awful.
> > > > > > I'm definitely happy to help.
> > > > > > let me know.
> > > > > >
> > > > > > cheers
> > > > >
> > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Automatic batch-mode activation in popular CI environments

[Tibor Digana]

It is better if you control the Maven and not when the Maven controls you 😁



Dňa ne 12. 7. 2020, 17:42 Martin Kanters 
napísal(a):

> Hi all,
>
> When setting up GitHub Actions for Maven (core) two weeks ago, I initially
> forgot to enable the -B/--batch-mode flag.
> While this gave no issues and was easy to fix, it could be avoided by
> detecting if Maven is executed on popular CI environments and in that case
> automatically enabling batch mode.
> Popular CI tools such as GitHub Actions [1] and GitLab CI [2] provide
> predefined environment variables, which could be used for this purpose.
> When this would automatically activate, we log this on INFO level. We would
> also need an option to turn batch-mode off to override this automatic
> behavior.
>
> The reason why I haven't created a JIRA issue yet is because I realize I do
> not know if this fits the usual workings for Maven.
> Based on best guesses (de-)activating certain functionality can in my
> vision be a quality-of-life improvement for our users.
> On the other hand I have the feeling currently Maven does favor users to
> explicitly set their CLI flags.
> Just wanted to know your opinion. If I get positive feedback I will create
> a JIRA issue.
> Otherwise we can consider alternatives (only log a hint: "CI run detected,
> did you want to run in --batch-mode?") or leave it like it is.
>
> Thanks,
> Martin
>
> [1]
>
> https://docs.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables
> [2] https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
>

Re: Assumption fail treated as unexcepted exception?!

[Tibor Digana]

yes it should be marked Skipped.
Many factors may turn this. As for instance I have these experiences with
Powermock which always fails the test in IntelliJ IDEA even if the
assumption fails.
Check it out with almost empty POM and a trivial test and compare the
outcome with the one you have attached. And then you will maybe see more.

@Test
public void test() {
 assumeTrue(false);
}

This code should work with JUnit 4.12 and whatever plugin version.
Turn this code to your specifics one by one and you will see what you have
added necessarily has changed the behavior.

T





On Sun, Aug 16, 2020 at 1:40 PM Markus KARG  wrote:

> Guys,
>
>
>
> I'm stuck with working on a new feature due to this, so I hope you can help
> me quickly:
>
>
>
> JUnit knows assumptions, assertions and exceptions. Failing assertions will
> FAIL tests (hence will fail maven builds). Failing assumptions will SKIP
> tests (hence will pass maven builds). Exceptions will ERROR tests (hence
> will break maven builds). Unfortunately today I noticed that assumptions
> actually ERROR test (hence fail builds) in Maven!
>
>
>
> (I simply added another test to maven dependency plugin which contains an
> always-failing assumption to proof the claim)
>
>
>
> [INFO] Results:
>
> [INFO]
>
> [ERROR] Errors:
>
> [ERROR]   TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip
>
> [INFO]
>
> [ERROR] Tests run: 257, Failures: 0, Errors: 1, Skipped: 0
>
>
>
> It seems maven treats JUnit assumptions just like JUnit exceptions! :-(
>
>
>
> Can someone tell my why that happens? Do I have to set some option tell
> Maven it shall SKIP instead of ERROR on failing assumptions?!
>
>
>
> Thanks in advance!
>
> -Markus Karg
>
>
>
>

Re: Assumption fail treated as unexcepted exception?!

[Tibor Digana]

Yes Piotr, this is another example why Markus has these unpleasant
experiences with JUnit3.
The code with JUnit4 annotation should be fine.

On Mon, Aug 17, 2020 at 1:34 PM Piotr Żygieło 
wrote:

> Please note, that TestCopyMojo is considered as JUnit3 TestCase
> (
> https://github.com/junit-team/junit4/blob/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8/src/main/java/org/junit/internal/builders/JUnit3Builder.java#L17
> ).
> So perhaps JUnit4+ features are not to be expected in such a case?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Assumption fail treated as unexcepted exception?!

[Tibor Digana]

Hi Markus,

It is a specific problem related to the JUnit library because the test
fails in IntelliJ IDEA and in Maven as well.

The JUnit4 assumptions fail with yellow markers in IDEA but here the
JUnit3' TestCase fails in red as a typical error or failure.
And Maven fails this test as follows but i think this behavior starts in
the junit library itself.

[INFO] Running test.TestAssumptions
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
0.028 s <<< FAILURE! - in test.TestAssumptions
[ERROR] test.TestAssumptions.testABC  Time elapsed: 0.01 s  <<< ERROR!
org.junit.AssumptionViolatedException: got: , expected: is 
at test/test.TestAssumptions.testABC(TestAssumptions.java:9)

[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   TestAssumptions.testABC:9 » AssumptionViolated got: ,
expected: is  wrote:

> Martin,
>
> I don't understand your question.
>
> You posted the Javadocs, and they tell it clearly: "A test for which an
> assumption fails should NOT generate a test case failure.".
>
> Also Assume's Javadocs
> (https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html) are pretty
> clear about it: "... A failed assumption does NOT mean the code is broken,
> but that the test provides no useful information. Assume basically means
> "don't RUN this test if these conditions don't apply". The default JUnit
> runner SKIPS tests with failing assumptions..."
>
> So do you really want me to ask the JUnit people whether they really MEAN
> what they clearly wrote...?
>
> -Markus
>
> -Ursprüngliche Nachricht-
> Von: Martin Gainty [mailto:mgai...@hotmail.com]
> Gesendet: Montag, 17. August 2020 12:27
> An: Maven Developers List
> Betreff: Re: Assumption fail treated as unexcepted exception?!
>
>
>/**
>  * Call to assume that actual satisfies the condition
> specified by matcher.
>  * If not, the test halts and is ignored.
>  * Example:
>  * :
>  *   assumeThat(1, is(1)); // passes
>  *   foo(); // will execute
>  *   assumeThat(0, is(1)); // assumption failure! test halts
>  *   int x = 1 / 0; // will never execute
>  * 
>  *
>  * @param  the static type accepted by the matcher (this can flag
> obvious compile-time problems such as {@code assumeThat(1, is("a"))}
>  * @param actual the computed value being compared
>  * @param matcher an expression, built of {@link Matcher}s, specifying
> allowed values
>  * @see org.hamcrest.CoreMatchers
>  * @see org.junit.matchers.JUnitMatchers
>  */
> public static  void assumeThat(T actual, Matcher matcher) {
> if (!matcher.matches(actual)) {
> throw new AssumptionViolatedException(actual, matcher);
> }
> }
>
> //does AssumptionViolatedException ever produce test case failure?
>
> /**
>  * An exception class used to implement assumptions (state in which
> a
> given test
>  * is meaningful and should or should not be executed). A test for which an
> assumption
>  * fails should not generate a test case failure.
>  *
>  * @see org.junit.Assume
>  * @since 4.12
>  */
> @SuppressWarnings("deprecation")
> public class AssumptionViolatedException extends
> org.junit.internal.AssumptionViolatedException {
> private static final long serialVersionUID = 1L;
>
> /**
>  * An assumption exception with the given actual value and a
> matcher describing
>  * the expectation that failed.
>  */
> public  AssumptionViolatedException(T actual, Matcher matcher) {
> super(actual, matcher);
> }
>
> /**
>  * An assumption exception with a message with the given actual
> value and a
>  * matcher describing the expectation that failed.
>  */
> public  AssumptionViolatedException(String message, T expected,
> Matcher matcher) {
> super(message, expected, matcher);
> }
>
> /**
>  * An assumption exception with the given message only.
>  */
> public AssumptionViolatedException(String message) {
> super(message);
> }
>
> /**
>  * An assumption exception with the given message and a cause.
>  */
> public AssumptionViolatedException(String assumption, Throwable t) {
> super(assumption, t);
> }
> }
>
> //will base class throw FAILURE for TestCase?
> /**
>  * An exception class used to implement assumptions (state in which
> a
> given test
>  * is meaningful and should or should not be executed). A test for which an
> assumption
>  * fails should not generate a test case failure.
>  *
>  * @see org.junit.Assume
>  */
> public class AssumptionViolatedException extends RuntimeException
> implements
> SelfDescribing {
> private static final long serialVersionUID = 2L;
>
> /*
>  * We have to use the f prefix until the next major release to ensure
>  * serialization compatibility.
>  * See https://github.com/junit-team/junit/issues/976
>  */
> private final String fAssumption;
> private final boolean fValueMatcher;
> priv

Re: Assumption fail treated as unexcepted exception?!

[Tibor Digana]

This is the outcome in IDEA:

"Tests failed: 1, passed: 0"

So the behavior is the same with Maven.

On Mon, Aug 17, 2020 at 6:35 PM Tibor Digana  wrote:

> Hi Markus,
>
> It is a specific problem related to the JUnit library because the test
> fails in IntelliJ IDEA and in Maven as well.
>
> The JUnit4 assumptions fail with yellow markers in IDEA but here the
> JUnit3' TestCase fails in red as a typical error or failure.
> And Maven fails this test as follows but i think this behavior starts in
> the junit library itself.
>
> [INFO] Running test.TestAssumptions
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 0.028 s <<< FAILURE! - in test.TestAssumptions
> [ERROR] test.TestAssumptions.testABC  Time elapsed: 0.01 s  <<< ERROR!
> org.junit.AssumptionViolatedException: got: , expected: is 
> at test/test.TestAssumptions.testABC(TestAssumptions.java:9)
>
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR]   TestAssumptions.testABC:9 » AssumptionViolated got: ,
> expected: is  [INFO]
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO]
> [INFO]
> 
> [INFO] BUILD FAILURE
>
> On Mon, Aug 17, 2020 at 3:07 PM Markus KARG 
> wrote:
>
>> Martin,
>>
>> I don't understand your question.
>>
>> You posted the Javadocs, and they tell it clearly: "A test for which an
>> assumption fails should NOT generate a test case failure.".
>>
>> Also Assume's Javadocs
>> (https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html) are pretty
>> clear about it: "... A failed assumption does NOT mean the code is broken,
>> but that the test provides no useful information. Assume basically means
>> "don't RUN this test if these conditions don't apply". The default JUnit
>> runner SKIPS tests with failing assumptions..."
>>
>> So do you really want me to ask the JUnit people whether they really MEAN
>> what they clearly wrote...?
>>
>> -Markus
>>
>> -Ursprüngliche Nachricht-
>> Von: Martin Gainty [mailto:mgai...@hotmail.com]
>> Gesendet: Montag, 17. August 2020 12:27
>> An: Maven Developers List
>> Betreff: Re: Assumption fail treated as unexcepted exception?!
>>
>>
>>/**
>>  * Call to assume that actual satisfies the condition
>> specified by matcher.
>>  * If not, the test halts and is ignored.
>>  * Example:
>>  * :
>>  *   assumeThat(1, is(1)); // passes
>>  *   foo(); // will execute
>>  *   assumeThat(0, is(1)); // assumption failure! test halts
>>  *   int x = 1 / 0; // will never execute
>>  * 
>>  *
>>  * @param  the static type accepted by the matcher (this can flag
>> obvious compile-time problems such as {@code assumeThat(1, is("a"))}
>>  * @param actual the computed value being compared
>>  * @param matcher an expression, built of {@link Matcher}s, specifying
>> allowed values
>>  * @see org.hamcrest.CoreMatchers
>>  * @see org.junit.matchers.JUnitMatchers
>>  */
>> public static  void assumeThat(T actual, Matcher matcher) {
>> if (!matcher.matches(actual)) {
>> throw new AssumptionViolatedException(actual, matcher);
>> }
>> }
>>
>> //does AssumptionViolatedException ever produce test case failure?
>>
>> /**
>>  * An exception class used to implement assumptions (state in
>> which a
>> given test
>>  * is meaningful and should or should not be executed). A test for which
>> an
>> assumption
>>  * fails should not generate a test case failure.
>>  *
>>  * @see org.junit.Assume
>>  * @since 4.12
>>  */
>> @SuppressWarnings("deprecation")
>> public class AssumptionViolatedException extends
>> org.junit.internal.AssumptionViolatedException {
>> private static final long serialVersionUID = 1L;
>>
>> /**
>>  * An assumption exception with the given actual value and a
>> matcher describing
>>  * the expectation that failed.
>>  */
>> public  AssumptionViolatedException(T actual, Matcher matcher) {
>> super(actual, matcher);
>> }
>>
>> /**
>>  * An assumption exception with a message with the given actual
>> value and a
>>  * matcher describing the expectation that failed.
>>  */
>> public  AssumptionViolatedException(String message, 

Re: Assumption fail treated as unexcepted exception?!

[Tibor Digana]

Markus, I was not talking about excuse. I only said that the JUnit library
has a bug regarding the old junit3 style. As far as I know the situation
with this library, it is very unlikely that it would be fixed.
The Surefire cannot do anything about it once the events are not fired from
JUnit3 TestCase.
As Piotr said you have to use the annotations and not to extend the class
TestCase. This would work for sure.
T

On Mon, Aug 17, 2020 at 7:58 PM Markus KARG  wrote:

> That doesn't make it any better, and it is no excuse that we do not simply
> catch that particular exception inside the Surefire plugin.
> So did we simply forget to implement this is the Surefire plugin (so I can
> add it), did we not implement it deliberately (so I shall not add it), or
> is it broken (so I shall fix it)?
> -Markus
>
> -Ursprüngliche Nachricht-
> Von: Tibor Digana [mailto:tibordig...@apache.org]
> Gesendet: Montag, 17. August 2020 18:37
> An: Maven Developers List
> Betreff: Re: Assumption fail treated as unexcepted exception?!
>
> This is the outcome in IDEA:
>
> "Tests failed: 1, passed: 0"
>
> So the behavior is the same with Maven.
>
> On Mon, Aug 17, 2020 at 6:35 PM Tibor Digana 
> wrote:
>
> > Hi Markus,
> >
> > It is a specific problem related to the JUnit library because the test
> > fails in IntelliJ IDEA and in Maven as well.
> >
> > The JUnit4 assumptions fail with yellow markers in IDEA but here the
> > JUnit3' TestCase fails in red as a typical error or failure.
> > And Maven fails this test as follows but i think this behavior starts in
> > the junit library itself.
> >
> > [INFO] Running test.TestAssumptions
> > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> > 0.028 s <<< FAILURE! - in test.TestAssumptions
> > [ERROR] test.TestAssumptions.testABC  Time elapsed: 0.01 s  <<< ERROR!
> > org.junit.AssumptionViolatedException: got: , expected: is 
> > at test/test.TestAssumptions.testABC(TestAssumptions.java:9)
> >
> > [INFO]
> > [INFO] Results:
> > [INFO]
> > [ERROR] Errors:
> > [ERROR]   TestAssumptions.testABC:9 » AssumptionViolated got: ,
> > expected: is  > [INFO]
> > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> > [INFO]
> > [INFO]
> > 
> > [INFO] BUILD FAILURE
> >
> > On Mon, Aug 17, 2020 at 3:07 PM Markus KARG 
> > wrote:
> >
> >> Martin,
> >>
> >> I don't understand your question.
> >>
> >> You posted the Javadocs, and they tell it clearly: "A test for which an
> >> assumption fails should NOT generate a test case failure.".
> >>
> >> Also Assume's Javadocs
> >> (https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html) are
> pretty
> >> clear about it: "... A failed assumption does NOT mean the code is
> broken,
> >> but that the test provides no useful information. Assume basically means
> >> "don't RUN this test if these conditions don't apply". The default JUnit
> >> runner SKIPS tests with failing assumptions..."
> >>
> >> So do you really want me to ask the JUnit people whether they really
> MEAN
> >> what they clearly wrote...?
> >>
> >> -Markus
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: Martin Gainty [mailto:mgai...@hotmail.com]
> >> Gesendet: Montag, 17. August 2020 12:27
> >> An: Maven Developers List
> >> Betreff: Re: Assumption fail treated as unexcepted exception?!
> >>
> >>
> >>/**
> >>  * Call to assume that actual satisfies the condition
> >> specified by matcher.
> >>  * If not, the test halts and is ignored.
> >>  * Example:
> >>  * :
> >>  *   assumeThat(1, is(1)); // passes
> >>  *   foo(); // will execute
> >>  *   assumeThat(0, is(1)); // assumption failure! test halts
> >>  *   int x = 1 / 0; // will never execute
> >>  * 
> >>  *
> >>  * @param  the static type accepted by the matcher (this can flag
> >> obvious compile-time problems such as {@code assumeThat(1, is("a"))}
> >>  * @param actual the computed value being compared
> >>  * @param matcher an expression, built of {@link Matcher}s,
> specifying
> >> allowed values
> >>  * @see org.hamcrest.CoreMatchers
> >>  * @see org.junit.matchers.JUnitMatchers
>

Re: [VOTE] Release Apache Maven PMD Plugin version 3.14.0

[Tibor Digana]

+1

In general, the build works but i have a problem with this statement in the
file selector.groovy
String jdk11Windows = 'f:\\jenkins\\tools\\java\\latest11'

IMO the value should be configured via a system property. It should not be
hard coded like it is written above.
And, if the path does not exist then this test should not be executed or
the test result should be ignored otherwise.
Also the README.md should express this exception and configuration too.

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-toolchains-plugin:3.0.0:toolchain (default)
on project MPMD-304-toolchain-support: Misconfigured toolchains.
Non-existing JDK home configuration at e:\Program Files\Java\jdk-11 ->
[Help 1]

On Sat, Oct 24, 2020 at 7:46 PM Andreas Dangel  wrote:

> Hi,
>
> We solved 9 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12346940&styleName=Text&projectId=12317621
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1611/
>
> https://repository.apache.org/content/repositories/maven-1611/org/apache/maven/plugins/maven-pmd-plugin/3.14.0/maven-pmd-plugin-3.14.0-source-release.zip
>
> Source release checksum(s):
> maven-pmd-plugin-3.14.0-source-release.zip sha512:
>
> b20cc1611abe5bdd5eed39bb5b7c0f601bcbba11dd98650f9fbdf3c8dcee996232904b39b6aaca0fde741c9ddc834433acf6f2eb79bc97821c22b6e2b257f706
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Regards,
> Andreas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Javac server?

[Tibor Digana]

The server makes sense when you want to have an incremental compiler.
We talked about it with Robert at the ASF conference 5 years ago.
If the server is tracing every change of your workspace (repo url, hash,
branch) and the list of sources too, then you can speed up the compiler.
T

On Sun, Nov 15, 2020 at 10:24 PM Enrico Olivelli 
wrote:

> Hey folks,
> I had never heard about this javac server before
> https://openjdk.java.net/jeps/139
>
>
> Is there any way we can exploit it in order to speed up the build?
> Is it enough to execute javac tool inside the same JVM of Maven core to get
> the same results?
>
> Do anyone have experience with it?
>
> Enrico
>

Re: MNG-6843 Parallel build fails due to missing JAR artifacts in compilePath

[Tibor Digana]

I commented on one issue regarding the NULL JAR file in Artifact a few days
ago.
The thing that some data is "missing" in some large object structures in
the environment with multiple threads may not necessarily have to do with
concurrent access.
There may not be any writes to MavenProject or MavenSession causing
"missed" data, and the answer why this happens is Memory Model.

It's the fact that non-concurrent or non-immutable objects may lose some
references very easily!
This has all to do with JMM and not the happens-before relationship.

Suppose that we have thread T1 creating ArrayList and adding elements into
this collection.
artifacts = new ArrayList();
artifacts.add(new DefaultArtifact(...));

Suppose thread T2 reads the artifacts from the collection right after
"artifacts.add()".
Artifact a = artifacts.get(0);

In practice the following happens:
artifacts.size() returns 1
but artifacts.get(0) returns NULL

Let;s explain why it happens.
The implementation of ArrayList is not native. It is a pure Java
implementation which has two variables inside:
+ count:int
+ array:Object[]
These two variables always appear in a critical section and they do not
have proper treatments in ArrayList.
Technically, the things are complicated on the CPU level and more
complicated than happens-before theorems.
T1 contains pointers and data in CPU registers or CPU cache. No Thread has
a direct access to a stack of another Thread, and of course it does not
operate on main memory.
The CPU uses memory barriers (assembler instructions) and a cache to
operate with RAM and memory coherency.
These instructions are used via Java keywords: final, volatile and
synchronized.
T2 may not see all elements completely from the ArrayList because there are
no safety mechanisms in the implementation of ArrayList to make this happen.
Thus the T2 may see the values in the Java variable "count" *but it may not
see the values in* "array", or vice versa.

The results are NPE, or missing JAR artifacts or the issues with Maven
Resolver, as we can see in https://github.com/apache/maven/pull/310

The solution with ThreadLocal would eat too much memory.
Reimplementing the POJO classes in Maven and making them thread safe would
solve many issues in the Core and Resolver.
Considering my examples with ArrayList, the thread safety should continue
deeper with the implementation of DefaultArtifact, etc.
In my experience, it's worth using the collection which appears in the
package "java.util.concurrent".
For instance, I use ConcurrentLinkedDequeue for simple iterators with small
amounts of elements. Alternatively use COWAL for large data and reordering
of elements by adding or removing them somewhere inside.

Cheers
Tibor17



On Sat, Jan 16, 2021 at 10:21 PM Dan Tran  wrote:

> we are facing the same issue at work (300+ modules), classpath
> empty randomly empty
>
> Love to see some resolution, will help to test it
>
> Thanks
>
> -D
>
> On Fri, Jan 15, 2021 at 1:51 PM Falko Modler  wrote:
>
> > Hi everyone,
> >
> > I'd like to raise awareness for the MavenProject concurrency problem
> > that is causing MNG-6843 "Parallel build fails due to missing JAR
> > artifacts in compilePath" [1] and probably others [2] [3] [4].
> >
> > Almost a month ago, I created a ThreadLocal-based fix for this [5]
> > (after another, older cloning-based approach had raised some concerns by
> > Robert Scholte [6]).
> >
> > Michael Osipov was the only one so far having a look (thanks!) and he
> > suggested that more Maven team members should review this.
> >
> > So, before I take a stab at the not so trivial integration test that
> > Michael proposed [7], I'd like to get an approval for the general
> > aproach (or a declination in case someone has a better idea).
> >
> > Thanks for your attention and feedback!
> >
> > Cheers,
> >
> > Falko
> >
> >
> > [1] https://issues.apache.org/jira/browse/MNG-6843
> >
> > [2] https://issues.apache.org/jira/browse/MNG-4996
> >
> > [3] https://issues.apache.org/jira/browse/MNG-5750
> >
> > [4] https://issues.apache.org/jira/browse/MNG-5960
> >
> > [5] https://github.com/apache/maven/pull/413
> >
> > [6] https://github.com/apache/maven/pull/310#issuecomment-571317501
> >
> > [7] https://github.com/apache/maven/pull/413#issuecomment-754661032
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.2

[Tibor Digana]

+1

Cheers
Tibor

On Sun, Jan 24, 2021 at 12:02 AM Sylwester Lachiewicz <
slachiew...@apache.org> wrote:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223&version=12347024&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCHECKSTYLE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1624/
>
> https://repository.apache.org/content/repositories/maven-1624/org/apache/maven/plugins/maven-checkstyle-plugin/3.1.2/maven-checkstyle-plugin-3.1.2-source-release.zip
>
> Source release checksum(s):
> maven-checkstyle-plugin-3.1.2-source-release.zip sha512:
>
> 4d90277a306390ec5a6434e01631295654fc4c45c1a4a0b5fae6c7c000a40e8357667fa943d05ddb55d1d742eae7628f371e4aba637941c538791bdd9ef39d08
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MNG-6843 Parallel build fails due to missing JAR artifacts in compilePath

[Tibor Digana]

Hi Falco,

This is not the first time I have been talking about these principles in
our team.
Seven years ago and then in 2019. But sorry I cannot force the people to do
it and they have to start by themself. We have to do it together.
All I can do is to provide some training and elaborate a problem but I am
convinced that we will meet again after the next seven years if we
don't understand the JMM. Thus we should prevent from redoing the same bad
and understand the process on how to make the code better in the early
beginning.

Cheers
Tibor17


On Sun, Jan 24, 2021 at 10:51 PM Falko Modler  wrote:

> Hi Tibor,
>
> thanks for this very elaborate answer and I always appreciate your
> feedback, but to me it kind of misses the point a bit...?
>
> > may not necessarily have to do with concurrent access.
> But it does in this special case. Please see the issue and the linked
> explanations.
>
> > The solution with ThreadLocal would eat too much memory.
> Is that so? Are you sure about this? How much is "too much"?
> Are there any predefined profiling tests I can run?
>
> I mean: yes, it is a workaround and immutable core classes that are
> _designed_ for concurrent access would be much better,
> but who is going to do such a massive refactoring (without breaking
> Maven extensions that are today mutating MavenProject etc.)?
>
> TBH, this is one of the, IMHO, critical bugs that should have been fixed
> before Maven 4.
>
> Cheers,
> Falko
>
> Am 21.01.2021 um 02:13 schrieb Tibor Digana:
> > I commented on one issue regarding the NULL JAR file in Artifact a few
> days
> > ago.
> > The thing that some data is "missing" in some large object structures in
> > the environment with multiple threads may not necessarily have to do with
> > concurrent access.
> > There may not be any writes to MavenProject or MavenSession causing
> > "missed" data, and the answer why this happens is Memory Model.
> >
> > It's the fact that non-concurrent or non-immutable objects may lose some
> > references very easily!
> > This has all to do with JMM and not the happens-before relationship.
> >
> > Suppose that we have thread T1 creating ArrayList and adding elements
> into
> > this collection.
> > artifacts = new ArrayList();
> > artifacts.add(new DefaultArtifact(...));
> >
> > Suppose thread T2 reads the artifacts from the collection right after
> > "artifacts.add()".
> > Artifact a = artifacts.get(0);
> >
> > In practice the following happens:
> > artifacts.size() returns 1
> > but artifacts.get(0) returns NULL
> >
> > Let;s explain why it happens.
> > The implementation of ArrayList is not native. It is a pure Java
> > implementation which has two variables inside:
> > + count:int
> > + array:Object[]
> > These two variables always appear in a critical section and they do not
> > have proper treatments in ArrayList.
> > Technically, the things are complicated on the CPU level and more
> > complicated than happens-before theorems.
> > T1 contains pointers and data in CPU registers or CPU cache. No Thread
> has
> > a direct access to a stack of another Thread, and of course it does not
> > operate on main memory.
> > The CPU uses memory barriers (assembler instructions) and a cache to
> > operate with RAM and memory coherency.
> > These instructions are used via Java keywords: final, volatile and
> > synchronized.
> > T2 may not see all elements completely from the ArrayList because there
> are
> > no safety mechanisms in the implementation of ArrayList to make this
> happen.
> > Thus the T2 may see the values in the Java variable "count" *but it may
> not
> > see the values in* "array", or vice versa.
> >
> > The results are NPE, or missing JAR artifacts or the issues with Maven
> > Resolver, as we can see in https://github.com/apache/maven/pull/310
> >
> > The solution with ThreadLocal would eat too much memory.
> > Reimplementing the POJO classes in Maven and making them thread safe
> would
> > solve many issues in the Core and Resolver.
> > Considering my examples with ArrayList, the thread safety should continue
> > deeper with the implementation of DefaultArtifact, etc.
> > In my experience, it's worth using the collection which appears in the
> > package "java.util.concurrent".
> > For instance, I use ConcurrentLinkedDequeue for simple iterators with
> small
> > amounts of elements. Alternatively use COWAL for large data and
> reordering
> > of elements by adding or removing them somewhere 

Re: [VOTE] Release Apache Maven Common Artifact Filters version 3.1.1

[Tibor Digana]

+1


On Sat, Jan 23, 2021 at 2:28 AM Sylwester Lachiewicz 
wrote:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12344661&styleName=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1623/
>
> https://repository.apache.org/content/repositories/maven-1623/org/apache/maven/shared/maven-common-artifact-filters/3.1.1/maven-common-artifact-filters-3.1.1-source-release.zip
>
> Source release checksum(s):
> maven-common-artifact-filters-3.1.1-source-release.zip sha512:
>
> 85da8be9ac71e56d6e6e7b107a7bd5f2b3ca98d2d2995c1a66a32092bea8c0fa8823cbcc67c61101d2717dcdca06ad1c1853a26a9e4bd84bfc43149c85561127
>
> Staging site:
>
> http://maven.apache.org/shared-archives/maven-common-artifact-filters-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Archiver version 3.5.1

[Tibor Digana]

+1


On Fri, Jan 22, 2021 at 11:30 PM Sylwester Lachiewicz <
slachiew...@apache.org> wrote:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12345175&styleName=Text&projectId=12317922&styleName=Text
>
> ** Improvement
> * [MSHARED-879] - make build Reproducible
> ** Dependency upgrade
> * [MSHARED-944] - Set minimum Maven version to 3.1.1
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-archiver
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1622/
>
> https://repository.apache.org/content/repositories/maven-1622/org/apache/maven/maven-archiver/3.5.1/maven-archiver-3.5.1-source-release.zip
>
> Source release checksum(s):
> /maven-archiver-3.5.1-source-release.zip-source-release.zip sha512:
>
> 7a3e64659fbf4f71770e1555210f228e72e8eedfd4a42cec0cf56b727f83a3f470428f832b44cc6d4d9a2a3e136c48bb5752373f1df4f5311040c54f9ec4a217
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-archiver-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Shared Invoker version 3.1.0

[Tibor Digana]

+1


On Thu, Feb 4, 2021 at 4:40 PM Sylwester Lachiewicz 
wrote:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12344858&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-invoker
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1626/
>
> https://repository.apache.org/content/repositories/maven-1626/org/apache/maven/shared/maven-invoker/3.1.0/maven-invoker-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-invoker-3.1.0-source-release.zip sha512:
>
> 92ba5308f5098fe06c0385980f48de15c06fb7b39f01e3aeec7d89fe4660ae265a7eee093a9783f90ebc0e16265fe87292216019880f18111b2df193ce67133a
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-invoker-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Incremental Maven - push the feature

[Tibor Digana]

Hi all,

There are two groups of multi-module projects:
- with many modules
- with one large module

The extension "gitflow-incremental-builder" and the cache are useful in the
first alternative.
But can we provide an incremental Java compiler for the second alternative?

If there is an argument that the Jenkins typically cleans up the workspace
and there is no way to keep the previous *.class files, then my argument is
that the incremental Java compiler (as a base of incremental build) would
be working fine if we had the "cache" on the Jenkins and Maven level too.
But there must be some Maven extension point able to cooperate with the
build systems as e.g. Jenkins. WDYT?

Cheers
Tibor17


On Sat, Feb 27, 2021 at 12:32 PM Maximilian Novikov <
maximilian.novi...@db.com> wrote:

> Dear Maven Dev,
>
> We would like to make a live demo of this feature and we will be happy to
> answer your questions.
> If you are interested to attend please reply directly to me and specify
> your timezone/preferable time.
>
> Kind regards,
> Maximilian Novikov
>
> -Original Message-
> From: Alexander Ashitkin [mailto:ashitkin.a...@gmail.com]
> Sent: Tuesday, February 23, 2021 5:28 AM
> To: dev@maven.apache.org
> Subject: Re: Incremental Maven - push the feature
>
> Hi Michael
> It's really a question of risks, time investments and expected benefits.
> Probably the main factor is how to improve the build without interruptions,
> failed deliveries and without regression in quality and productivity.
> Improving Maven was considered an optimal way at least tactically. So
> again, at least tactically this feature closed gap between maven and gradle
> to such an extent that future build system could be evaluated and planned
> without pressure.
>
> Thank you
> Aleks
>
> On 2021/02/22 10:57:29, Michael Osipov  wrote:
> > Am 2021-02-22 um 05:37 schrieb Alexander Ashitkin:
> > > Hi Maven Dev
> > >
> > > We would like to resume topic of incremental builds on Maven -
> > > https://www.mail-archive.com/dev@maven.apache.org/msg119816.html
> > > We’ve come a long way on Deutsche Bank side and currently few steps
> away from contribution. At this point Deutsche Bank Open Source council
> asked for support letter on behalf of the Maven project.
> > > So we are looking for some feedback on this piece from Maven Project –
> criticality, interest, usefulness, etc.
> > >
> > > Positive feedback and confirmation of interest is appreciated even
> more.
> > > Once approved on our side we plan to push the change in a feature
> branch. We don’t expect it to be merged to core and rather see it as a
> proof of concepts to facilitate collaboration and discussions.
> > > We are interested in future improvements and expect to hear feedback
> and guidance from experts on better design and implementation. From our
> side we’re ready to invest our time in further improvements. But it will be
> great to understand some approach to taking it forward.
> > >
> > > The feature is stable, it is used in many critical projects
> internally. It was cross checked, challenged and validated uncountable
> number of times on all possible levels.
> > >
> > > We’re are confident in quality, stability and seeking to advertise it
> as an experimental feature in Maven. Ideally we would like to see it as an
> unofficial distribution, but at bare minimum users could build it from the
> branch by themselves. As it is fully compatible with official distribution
> we expect that will encourage users to experiment and provide feedback.
> > >
> > > The feature was announced on local IT-conference Joker 2020 (
> https://jokerconf.com/en/) and gained significant interest both from
> organizers and guests.
> > >
> > > The talk is available here
> > > https://www.youtube.com/watch?v=caKWl2H-e18 (it is in Russian and
> > > hopefully auto translate can give you rough understanding of the
> > > feature. We also plan to create English version a bit later)
> >
> > Hi there,
> >
> > I watched the video and the keypoint in the comparison was not
> > explained: Except for the migration effort, why was Gradle not a
> > suitable option? All you said is that the Gradle Extensions for Maven
> > are not suited for now, but that's a different thing.
> >
> > Otherwise the video was quite promising and the approach was
> > adequately expressed in a superficial way which is fine for 12 min.
> >
> > Michael
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
> > additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional
> commands, e-mail: dev-h...@maven.apache.org
>
>
>
> ---
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immedia

Re: [VOTE] Release Apache Maven version 3.8.0

[Tibor Digana]

here is mine +1.
The amount of work means more for me than the version 3.7.0 we skipped. We
can improve it in the future of course!
Regarding the issues found with the Warning on the console, these issues
can be fixed as always, right after.
T

On Mon, Mar 22, 2021 at 8:40 PM Robert Scholte  wrote:

> Hi,
>
> For the details about this release, please read
> https://maven.apache.org/docs/3.8.0/release-notes.html
> Also please provide feedback on the release notes. (as you know, these are
> published separately from the release, so it doesn't have to block the
> release itself)
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12350003&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012316922%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1633/
>
>
> https://dist.apache.org/repos/dist/release/maven/maven-3/3.8.0/binaries/apache-maven-3.8.0-bin.zip
>
> https://dist.apache.org/repos/dist/release/maven/maven-3/3.8.0/source/apache-maven-3.8.0-src.zip
>
>
> Source release checksum(s):
>
> apache-maven-3.8.0-bin.zip sha512: 
> b56da9a0efa45e084e4882b795787fc7b61970d19835635b2db099b91a9854f14e3776a01d569e3f7af9db946a05af91abbfad41cdc5ac09e90df25077dec01e
>
> apache-maven-3.8.0-src.zip sha512: 
> 51a1570894e8fb1ef52cb19ce472866745ccae2720e45304edd3cabc212cdf105937c76502558fe87995aea81c41402d7f581cc8e9393af234b64696e9a45893
>
>
> Staging site:
> https://maven.apache.org/ref/3-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Tibor Digana]

Hi Som Lima,

Regarding (1), the Maven Central works with HTTPS for some time already.
Regarding the Repository Managers, e.g. Nexus or JFrog they have to be
updated to HTTPS in companies which is normal work for the administrators
and devops teams, not for the users or devs, but nowadays the
worldwide situation is so that security is the higher priority and it can
be configured very easily. It;s not only Maven Central but also RedHat
Maven Repository https://maven.repository.redhat.com/ga/ which works with
HTTPS and I believe that many other Providers have already switched their
repositories to HTTPS. It would be more difficult to find the opposite!
Regarding the instructions to upgrade Nexus to HTTPS, it's quite easy, but
as I said before, this is the task for the devops teams mostly.
T

On Sun, Mar 28, 2021 at 12:28 PM Som Lima  wrote:

> As a user these points would be  MAJOR concerns
> 1. external HTTP insecure URLs are now blocked by default
>
> 2. your builds may fail when using this new Maven release.
>
> I would say go for version 5.0 suggesting a fresh start. A clear
> separation.
>
> Leaving you enough versions to fix 3.6.3 bugs where existing project are
> still compatible.
>
> Just floating an indea.
>
>
>
>
> On Sun, 28 Mar 2021, 11:07 Hervé BOUTEMY,  wrote:
>
> > thank you Romain for your view
> >
> > current reasoning behind 3.8.0 choice is written in release notes [1]
> >
> > -  Why not 3.6.4?
> > This is not just a bugfix as it contains three features that cause a
> > change of default behavior (external HTTP insecure URLs are now blocked
> by
> > default): your builds may fail when using this new Maven release, if you
> > use now blocked repositories. Please check and eventually fix before
> > upgrading.
> >
> > - Why not 3.7.0?
> > Apache Maven 3.7.0 has been advertised in the past that it would be the
> > first release where you could optionally activate the build/consumer
> > feature: the version containing this feature has been renamed to 4.0.0.
> > Reusing 3.7.0 might lead to confusion, hence we picked the next available
> > minor version.
> >
> >
> > I personally have a strong feeling against 3.6.4: it's not just a bugfix,
> > it would cause surprises to users upgrading with full confidence.
> >
> > On 3.7 vs 3.8, reasoning is fully written. We skipped versions in the
> > past, it's not a big deal.
> >
> > tm me, 3.8.0 is the best choice for users (and if they have questions why
> > this version, they have 2 little answers in the release notes)
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1]
> >
> https://maven.apache.org/docs/3.8.0/release-notes.html#why-does-this-version-have-the-value-3-8-0
> >
> > Le dimanche 28 mars 2021, 11:47:11 CEST Romain Manni-Bucau a écrit :
> > > Hi all,
> > >
> > > Before we reroll the failed 3.8.0 I'd like we discuss openly the next
> > > versioning since it seems we didn't reach a consensus yet and trying to
> > not
> > > create too much friction for users and in the community.
> > >
> > > As a reminder the only feature the release will get is to prevent HTTP
> > repo
> > > (in favor of HTTPS ones). In that regard it is a breaking change if
> users
> > > rely on HTTP repo but a security fix (I don't come back on the HTTP ->
> > > HTTPS move IT ecosystem got recently here).
> > >
> > > So it seems there are multiple versioning options:
> > >
> > > 1. 3.6.4: seems natural since it is a security fix, enables companies
> to
> > > get this fix respecting a project versioning policy without having to
> > > upgrade and avoids us to have to maintain 3.6 + 3.7/3.8 and soon 4.x.
> > > Indeed it requires a very well documented paragraph about this change
> and
> > > how to workaround it (local proxy/mirror is a trivial one for example)
> > but
> > > it will be the case whatever version we pick anyway IMHO.
> > > 2. 3.7.0: since it is a breaking change it can seem natural too (but
> has
> > > the pitfall to likely require a backport in 3.6 anyway, due to the
> > > versioning policies which can prevent some users to upgrade to a 3.7)
> > > 3. 3.8.0: was the vote, seems the rational was that originally we
> > > targetting mvnw in 3.7 and since we didn't make it 3.8 was used. Have
> to
> > > admit I'm not sure of this reasoning more than that (cause for me if we
> > > don't have a planned feature we can either try to push/wait for it or
> > > postpone it but not skip a version due to that) so if anyone wants to
> > > complete the reasoning here it would be great.
> > >
> > > Indeed my preference is for 3.6.4 which has the most advantages for
> > > everyone and no additional drawbacks compared to 3.7 or 3.8 options
> until
> > > we try to push to get mvnw in which would mean 3.7 becomes more natural
> > > (and likely imply a 3.6.x maintenance version).
> > >
> > > Goal of this thread is to feel the overall trend and see if we can
> refine
> > > the proposals (for example: can we drop 3.8 one and only keep 3.7 and
> 3.6
> > > or - best - can we refine it to a single v

Re: Cutting a release for Surefire?

[Tibor Digana]

It is only a milestone version which means a work in progress. The fixes
made so far are really minor, no need to make any release.
If you take a look at the road map, you will see that I do not need to fix
tiny issues, I need to rework the additional attributes which will transfer
events about tests. There are testId and RunOrder. Without them the BIGGER
fixes, than the ones you are aiming for, would not be possible, e.g. better
xml marshaller, logs from parallel tests and re-run which is currently
unstable due to it relies on the order of test run. The next thing which
seems to be easier and also necessary is the execution of UUID and Script
which is needed by Cucumber and junit5.
The sad thing is that mostly common users participate and they become
committers. Our official committers do not. So Enrico, pls participate in
coding because many of us like performing releases but there are only few
hard workers. Making a release is easy but taking the responsibility for
the binaries in the world is much harder. So, pls participate in
Stackoverflow like Karl does and me, participate in coding and then we can
talk about taking a benefit from a release.

Yeah, one more very important thing. We introduced TCP connector for making
the above plan possible. The user found that the TCP feature hangs somehow,
see https://issues.apache.org/jira/browse/SUREFIRE-1881. It took me several
months to understand the rootcase. It has nothing to do with TCP itself,
nothing but process pipes which are full of bytes before the tcp makes
handshaking. Releasing the work in the middle and unstable is silly. You
know when I found the root cause? It was at 1:30 early in the morning.
Again pls come to work and spend less time in discussions, let;s work in
PRs on GitHub and we will have a chance to make releases earlier.
I am sorry that I am a bad guy, but I asked Enrico several times to work in
this OSS as well. I know Enrico that you participate in another OSSes too
but you have to decide, since the day has only 24 hours, how much you will
do and what you will do, but sorry making a release without working on it
is not adequate.

T

On Sat, Apr 3, 2021 at 11:08 AM Enrico Olivelli  wrote:

> What about cutting a release for Surefire plugin?
> We already fixed important problems that are on 3.0.0-M5 and I saw that
> current master branch works well.
>
> Thoughts?
> Volunteers?
>
> Enrico
>

Re: [VOTE] Release Apache Maven version 3.8.1

[Tibor Digana]

Hi Robert,

The release note contains points 1. and 2., but the problem is that 2. is
empty.
Here is the picture attached, pls have a look, thx.

[image: obrázok.png]


On Tue, Mar 30, 2021 at 10:59 PM Robert Scholte 
wrote:

> Hi,
>
> For the details about this release, please read
> https://maven.apache.org/docs/3.8.1/release-notes.html
> Also please provide feedback on the release notes. (as you know, these are
> published separately from the release, so it doesn't have to block the
> release itself)
>
> We solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12350032&styleName=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1634/
>
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.zip
>
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/source/apache-maven-3.8.1-src.zip
>
> Source release checksum(s):
>
> apache-maven-3.8.1-bin.zip sha512: 
> c585847bfbcf8647aeabfd3e8bf0ac3f67a037bd345545e274766f144c2b978b3457cbc3e31545e62c21ad69e732695de01ec96ea2580e5da67bd85df095c0f4
> apache-maven-3.8.1-src.zip
> sha512: 
> 893988635349985074c88ce5ef27ac5ccb62fcdf58846209eee8a7ea5515238288b91c202347ca42e201ab336c14d83f3f5fd8194070e57b9366bcce2414614d
>
> Knows issues:
> When building with the sources with JDK-16 and above, the unittest
> MavenCliTest#testStyleColors will fail. This will be fix with MNG-7127[1],
> but is left out to keep focus on the real purpose of this release.
>
> Staging site:
> https://maven.apache.org/ref/3-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> ---
> [1] https://issues.apache.org/jira/browse/MNG-7127

Re: Why no mvn daemon?

[Tibor Digana]

I think two years ago we were talking about Maven dockerization.
We had the work in progress and I think I will be able to find it again.
The Docker image included local repo.
I think the biggest latencies are when you are downloading artifacts.
Of course, you have one local repo, but that's suitable for those CI
systems which do not want to override the local repo or share the artifacts
with other projects. It is our case in Apache.

T

On Wed, Apr 7, 2021 at 8:34 AM Guillaume Nodet  wrote:

> Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
> project, should you choose to accept it.
>
> Cheers,
> Guillaume
>
> Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau  a
> écrit :
>
> > Up 4 years later ;)
> >
> > Now mvnd exists and proves it is very interesting to have such a feature,
> > should it be something which can fit maven standard delivery?
> > If overall yes we can start by asking mvnd if it can be contributed with
> > main codebase and if not we can either decide to do our own (hope not ;))
> > or that maven does not care about caching/optimizations in its "core" and
> > that it is only done in extensions (I know 3 "main" ones as of today).
> >
> > Wdyt?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 9 mars 2016 à 23:58, Jeff Jensen <
> > jeffjen...@upstairstechnology.com>
> > a écrit :
> >
> > > Thanks!  It's running just fine.  :-)  It's very cool.  Really nice
> > > directory traversal and completion, colors, and commands/features I
> don't
> > > know yet!
> > >
> > > Very interesting timing diffs (for each casual test, I ran the command
> > for
> > > each multiple times to seed infra caches):
> > >  * on some asciidoc gen with "mvn generate-resources", it was about the
> > > same duration as CLI but after running each about 10 times, mvnshell
> > saved
> > > about 20% consistently (possibly due to JIT? besides directory
> traversal,
> > > this was the first things I did).  This was my key use case for
> wanting a
> > > "mvn server" - handling situations like this with repeated runs
> > (asciidoc,
> > > site, etc.).
> > >
> > >  * on a simple "mvn clean", mvnshell was about 2x faster than CLI.
> > >
> > >  * on a small module build, "mvn install" was about 20% faster over CLI
> > > (after a mvn clean for each).
> > >
> > > I look forward to trying more things.
> > >
> > > Nice to have, thank you Jason!
> > >
> > >
> > > On Wed, Mar 9, 2016 at 4:17 PM, Jason Dillon 
> > > wrote:
> > >
> > > > Jason, if you have a built version, do you mind adding it as a
> download
> > > to
> > > >
> > > > the release files?
> > > >
> > > > I can make a binary of this, though I do plan on fixing it up so that
> > > > folks can build it in the near future.
> > > >
> > > > Build up here for the moment:
> > > >
> > > >
> > >
> >
> https://www.dropbox.com/sh/yvt1g43r2pr2scj/AADqM__VhJaFf_x57OiUEZXva?dl=0
> > > >
> > > > gshell:master should be buildable with just central now, dangling ref
> > to
> > > > older version of jline for classifer=tests which was unused and
> > polluting
> > > > the build dependencies.
> > > >
> > > > —jason
> > > >
> > > >
> > > >
> > >
> >
>
>
> --
> 
> Guillaume Nodet
>

Re: Why no mvn daemon?

[Tibor Digana]

Romain, our builds are always downloading the artifacts.
The I/O cannot be 0 time. We invest in safety builds rather than
performance and so we rather download fresh artifacts.
Other teams may cach the artifacts which may not be always so safe - other
preferences.

If you think that the Cache or AppCDS or GraalVM would have an effect, feel
free to make a prototype and try to measure the performance.
Publish the benchmark test result and we will see how big percentage
improvement it would be in categories (asciidoc, normal build, specific
builds, whatever...)

As I can see the following article, such a benchmark test can be made in a
spare time:
https://medium.com/@toparvion/appcds-for-spring-boot-applications-first-contact-6216db6a4194


Cheers
T


On Wed, Apr 7, 2021 at 3:52 PM Romain Manni-Bucau 
wrote:

> Hi Tibor,
>
> I see what you mean but I think this topic is actually unrelated to IO
> since this remote latency is actually 0 in the case we are discussing and
> this case is generally solved by caching on all CI (jenkins, gh actions,
> travis for the ones I can speak about out of my head) - and locally by your
> local m2 as you mentionned.
> So overall the download time is always skipped in this daemon topic since
> it is a pay once cost that devs rarely face.
>
> What we care about is to a have sane defaults and the capacity to stop
> creating and recreating ClassRealm with potentially slow init in these
> realms (use asciidoctor to see something slow to create ;)).
> A daemon enables to add a ton of caches which save a lot of time in
> practise when rebuilding the same project.
> Indeed part of these enhancements can be backported to maven core - and
> thanks mvnd team to have done part of it - but not all of them since by
> design the biggest slow part of a JVM is the classloading (it is one part
> GraalVM speeds up a lot by bypassing it), in particular with plexus
> classrealm hierarchy and impl.
> At least this feature can justify a daemon for me but also having an in
> memory cache to not resolving and resolving is the second big feature maven
> benefits a lot from what I saw (it is crazy how we loose time there).
> Indeed, as soon as instances can be reused plugins could cache more without
> breaking the "not daemon" cache and provide way more boosts but current
> behavior is already impressive (I expected the boost to be important but
> less when I started the thread 4 years ago to be honest).
>
> Le mer. 7 avr. 2021 à 15:40, Tibor Digana  a
> écrit :
>
> > I think two years ago we were talking about Maven dockerization.
> > We had the work in progress and I think I will be able to find it again.
> > The Docker image included local repo.
> > I think the biggest latencies are when you are downloading artifacts.
>
> Of course, you have one local repo, but that's suitable for those CI
> > systems which do not want to override the local repo or share the
> artifacts
> > with other projects. It is our case in Apache.
> >
> > T
> >
> > On Wed, Apr 7, 2021 at 8:34 AM Guillaume Nodet 
> wrote:
> >
> > > Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
> > > project, should you choose to accept it.
> > >
> > > Cheers,
> > > Guillaume
> > >
> > > Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > a
> > > écrit :
> > >
> > > > Up 4 years later ;)
> > > >
> > > > Now mvnd exists and proves it is very interesting to have such a
> > feature,
> > > > should it be something which can fit maven standard delivery?
> > > > If overall yes we can start by asking mvnd if it can be contributed
> > with
> > > > main codebase and if not we can either decide to do our own (hope not
> > ;))
> > > > or that maven does not care about caching/optimizations in its "core"
> > and
> > > > that it is only done in extensions (I know 3 "main" ones as of
> today).
> > > >
> > > > Wdyt?
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > 

Re: Why no mvn daemon?

[Tibor Digana]

What was the third run? It was one thread with GraalVM?
$ time mvnd install -DskipTests -Dinvoker.skip=true
real 0m11,295s
user 0m0,354s
sys 0m0,176s

On Wed, Apr 7, 2021 at 7:09 PM Romain Manni-Bucau 
wrote:

> Le mer. 7 avr. 2021 à 17:08, Tibor Digana  a
> écrit :
>
> > Romain, our builds are always downloading the artifacts.
> > The I/O cannot be 0 time. We invest in safety builds rather than
> > performance and so we rather download fresh artifacts.
> > Other teams may cach the artifacts which may not be always so safe -
> other
> > preferences.
> >
>
> Got it, note that redownloading a release is normally wrong and caching a
> snapshot is also but this is your policy and a docker solution will not
> solve that since you will need to update the docker base image as often as
> you want updates (likely daily for snapshot) or still use snapshots so at
> the end docker is not what helps *for this factor*.
>
>
> >
> > If you think that the Cache or AppCDS or GraalVM would have an effect,
> feel
> > free to make a prototype and try to measure the performance.
> > Publish the benchmark test result and we will see how big percentage
> > improvement it would be in categories (asciidoc, normal build, specific
> > builds, whatever...)
> >
>
> We already discussed it multiple times but graalvm boost or cds boost can
> be siginificative but without rewriting *all* maven design gain is 0 (both
> only work with a flat classpath - even a bit more constraints) so it means
> no more isolated plugins, no more plexus-classworld etc, not sure we want
> to do that anytime soon since it is a big feature of maven.
>
>
> >
> > As I can see the following article, such a benchmark test can be made in
> a
> > spare time:
> >
> >
> https://medium.com/@toparvion/appcds-for-spring-boot-applications-first-contact-6216db6a4194
>
>
> Figures already had been shared on the list and it is not rare to have
> around 30% boost on real life projects.
> If you want something closer, maven-surefire figures are:
>
> $ time mvn install -DskipTests -Dinvoker.skip=true
> real 0m29,606s
> user 2m10,142s
> sys 0m3,160s
>
> $ time mvn install -DskipTests -Dinvoker.skip=true -T15 # I have 16 core,
> just to match mvnd defaults
> real 0m19,494s
> user 2m47,651s
> sys 0m4,098s
>
> $ time mvnd install -DskipTests -Dinvoker.skip=true
> real 0m11,295s
> user 0m0,354s
> sys 0m0,176s
>
>
> 42% faster (I skipped tests to only include project pipeline but it is the
> kind of boost the caching + long running daemon provides you)
>
>
>
> >
> >
> >
> > Cheers
> > T
> >
> >
> > On Wed, Apr 7, 2021 at 3:52 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > Hi Tibor,
> > >
> > > I see what you mean but I think this topic is actually unrelated to IO
> > > since this remote latency is actually 0 in the case we are discussing
> and
> > > this case is generally solved by caching on all CI (jenkins, gh
> actions,
> > > travis for the ones I can speak about out of my head) - and locally by
> > your
> > > local m2 as you mentionned.
> > > So overall the download time is always skipped in this daemon topic
> since
> > > it is a pay once cost that devs rarely face.
> > >
> > > What we care about is to a have sane defaults and the capacity to stop
> > > creating and recreating ClassRealm with potentially slow init in these
> > > realms (use asciidoctor to see something slow to create ;)).
> > > A daemon enables to add a ton of caches which save a lot of time in
> > > practise when rebuilding the same project.
> > > Indeed part of these enhancements can be backported to maven core - and
> > > thanks mvnd team to have done part of it - but not all of them since by
> > > design the biggest slow part of a JVM is the classloading (it is one
> part
> > > GraalVM speeds up a lot by bypassing it), in particular with plexus
> > > classrealm hierarchy and impl.
> > > At least this feature can justify a daemon for me but also having an in
> > > memory cache to not resolving and resolving is the second big feature
> > maven
> > > benefits a lot from what I saw (it is crazy how we loose time there).
> > > Indeed, as soon as instances can be reused plugins could cache more
> > without
> > > breaking the "not daemon" cache and provide way more boosts but current
> > > behavior is already impressive (I expected the boost to be important
> but
> > > less when I started the thread 

Re: [VOTE] Release Apache Maven Wrapper Plugin version 3.0.2

[Tibor Digana]

+1

On Mon, Apr 5, 2021 at 4:29 PM Robert Scholte  wrote:

> To: "Maven Developers List" 
> Subject: [VOTE] Release Apache Maven Wrapper Plugin version 3.0.2
>
> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721&version=12348358&styleName=Text
>
> There are zero issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012323721%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1637/
>
> https://repository.apache.org/content/repositories/maven-1637/org/apache/maven/plugins/maven-wrapper-plugin/3.0.2/maven-wrapper-plugin-3.0.2-source-release.zip
>
> Source release checksum(s):
>
> maven-wrapper-plugin-3.0.2-source-release.zip sha512: 
> 3b185d5486249f9ad4e0133462d294aeae05bc80fa3cbc7dd622c50689eb9316d5b260fa28a03e1922fe3e2ec1beb22f69c033c7f4894d90c4d874e1835089cc
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-wrapper-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Testing the plugin with Maven 3 will fail (see MWRAPPER-8)
> To test the plugin with Maven 4, ensure to add the following repository:
>
> 
>   apache.snapshots
>   Apache Snapshot Repository
>   https://repository.apache.org/snapshots
>   
> false
>   
> 
>
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [VOTE] Release Apache Maven Release Plugin version 3.0.0-M4

[Tibor Digana]

+1

On Mon, Apr 12, 2021 at 7:31 PM Robert Scholte  wrote:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317824&version=12348079&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317824%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1639
>
> https://repository.apache.org/content/repositories/maven-1639/org/apache/maven/release/maven-release/3.0.0-M4/maven-release-3.0.0-M4-source-release.zip
>
> Source release checksum(s):
>
> maven-release-3.0.0-M4-source-release.zip sha512: 
> 49ec8c495b11696671e83ccdeee3408223d0aef3cfd5f48e2a4afc66e225f550069a060702205152e3e59238f9db64efd85ac626b25b05596be3ef422b991895
>
> Staging site:
> https://maven.apache.org/maven-release-archives\maven-release-LATEST
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: Failing IT's on Linux in GitHub Actions

[Tibor Digana]

I had exactly the same problem and I added one more step to the CI which
checked all open ports.
For instance they changed something in Github and 8081 or 8082 was
allocated.
There was a conflict with the ports and I had to shift mine, that;s it.

T

On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders 
wrote:

> Hi all,
>
> It seems the following IT's predictably fail on Linux (not on Windows or
> MacOS) in GitHub Actions, but not at all in Jenkins:
>
> * MavenIT0146InstallerSnapshotNaming
> * MavenITmng2387InactiveProxyTest
> * MavenITmng4991NonProxyHostsTest
>
> This is also the case in master, by the way. What they have in common is
> that they all spin up an HTTP server during the test, but apparently
> that server cannot be reached under all circumstances.
>
> Does anyone have an idea what might be causing this and how we could
> address this?
>
> Thanks,
>
> Maarten
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Failing IT's on Linux in GitHub Actions

[Tibor Digana]

Port 0 does not exist, only in your code.
0 means that a new unused local port is allocated.
Again you have to use local loopback 127.0.0.1 as me. I had the same
problem and I solved it.
T

On Mon, Apr 19, 2021 at 8:41 AM Maarten Mulders 
wrote:

> All of those tests seem to follow the process of starting a server at
> port 0 indeed. Some tests even start two servers in one test:
> MavenITmng4991NonProxyHostsTest and MavenITmng2387InactiveProxyTest. And
> in all three scenarios they use
> `InetAddress.getLocalHost().getCanonicalHostName()` to lookup their
> hostname. I'm not sure if that's the best way to do it?
>
> Interestingly, I now see that those tests do not *always* fail on Linux.
> During the last GitHub Action run (640, [1]), two out of four Linux jobs
> actually succeeded. The failing ones logged stuff like this:
>
>
> Connect to fv-az154-166.internal.cloudapp.net:34307
> [fv-az154-166.internal.cloudapp.net/10.1.0.103] failed: Connection timed
> out (Connection timed out)
>
> Connect to fv-az292-806.internal.cloudapp.net:33785
> [fv-az292-806.internal.cloudapp.net/10.1.0.129] failed: Connection timed
> out (Connection timed out)
>
>
> Interestingly, they seem to not be able to connect, but the name lookup
> doesn't seem the issue, right?
>
>
> Thanks,
>
>
> Maarten
>
>
> [1] https://github.com/apache/maven/actions/runs/761300517
>
>
> On 19/04/2021 00:31, Tibor Digaňa wrote:
> > yes, there was one more issue with host.
> > I also had to turn "localhost" to 127.0.0.1 in the socket.
> > T
> >
> > On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy  wrote:
> >
> >> Hi,
> >> Do not change ports or use hard coded ports.
> >> The current ITs are using port 0 which means Jetty will allocate a
> >> random available port.
> >> There must be some problems with host lookup. In some environments
> (such as
> >> kubernetes) using localhost or 127.0.0.1 can be problematic.
> >> What is the error?
> >>
> >> What is the status of using java8 for IT tests? (current ITs are using a
> >> very very old version of Jetty 9.0.4...)
> >>
> >>
> >> On Mon, 19 Apr 2021 at 06:56, Tibor Digana 
> wrote:
> >>
> >>> I had exactly the same problem and I added one more step to the CI
> which
> >>> checked all open ports.
> >>> For instance they changed something in Github and 8081 or 8082 was
> >>> allocated.
> >>> There was a conflict with the ports and I had to shift mine, that;s it.
> >>>
> >>> T
> >>>
> >>> On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders  >
> >>> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> It seems the following IT's predictably fail on Linux (not on Windows
> >> or
> >>>> MacOS) in GitHub Actions, but not at all in Jenkins:
> >>>>
> >>>> * MavenIT0146InstallerSnapshotNaming
> >>>> * MavenITmng2387InactiveProxyTest
> >>>> * MavenITmng4991NonProxyHostsTest
> >>>>
> >>>> This is also the case in master, by the way. What they have in common
> >> is
> >>>> that they all spin up an HTTP server during the test, but apparently
> >>>> that server cannot be reached under all circumstances.
> >>>>
> >>>> Does anyone have an idea what might be causing this and how we could
> >>>> address this?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Maarten
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
> >> Olivier Lamy
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Failing IT's on Linux in GitHub Actions

[Tibor Digana]

I had this problem with GH CI:

java.net.BindException: Cannot assign requested address
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:461)
at sun.nio.ch.Net.bind(Net.java:453)
at
sun.nio.ch.AsynchronousServerSocketChannelImpl.bind(AsynchronousServerSocketChannelImpl.java:163)

and solved it see
https://github.com/apache/maven-surefire/commit/a1d3866eb0dd81e8ea62f740f93fde93#diff-24d3dc1df1df617f7318394dde0b087beef68c26909828ccca72bf2af78ed9bfR84
and now the CI is green.
I guess we have the same problem in our ITs.

T






On Mon, Apr 19, 2021 at 10:09 AM Tibor Digana 
wrote:

> Port 0 does not exist, only in your code.
> 0 means that a new unused local port is allocated.
> Again you have to use local loopback 127.0.0.1 as me. I had the same
> problem and I solved it.
> T
>
> On Mon, Apr 19, 2021 at 8:41 AM Maarten Mulders 
> wrote:
>
>> All of those tests seem to follow the process of starting a server at
>> port 0 indeed. Some tests even start two servers in one test:
>> MavenITmng4991NonProxyHostsTest and MavenITmng2387InactiveProxyTest. And
>> in all three scenarios they use
>> `InetAddress.getLocalHost().getCanonicalHostName()` to lookup their
>> hostname. I'm not sure if that's the best way to do it?
>>
>> Interestingly, I now see that those tests do not *always* fail on Linux.
>> During the last GitHub Action run (640, [1]), two out of four Linux jobs
>> actually succeeded. The failing ones logged stuff like this:
>>
>>
>> Connect to fv-az154-166.internal.cloudapp.net:34307
>> [fv-az154-166.internal.cloudapp.net/10.1.0.103] failed: Connection timed
>> out (Connection timed out)
>>
>> Connect to fv-az292-806.internal.cloudapp.net:33785
>> [fv-az292-806.internal.cloudapp.net/10.1.0.129] failed: Connection timed
>> out (Connection timed out)
>>
>>
>> Interestingly, they seem to not be able to connect, but the name lookup
>> doesn't seem the issue, right?
>>
>>
>> Thanks,
>>
>>
>> Maarten
>>
>>
>> [1] https://github.com/apache/maven/actions/runs/761300517
>>
>>
>> On 19/04/2021 00:31, Tibor Digaňa wrote:
>> > yes, there was one more issue with host.
>> > I also had to turn "localhost" to 127.0.0.1 in the socket.
>> > T
>> >
>> > On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy  wrote:
>> >
>> >> Hi,
>> >> Do not change ports or use hard coded ports.
>> >> The current ITs are using port 0 which means Jetty will allocate a
>> >> random available port.
>> >> There must be some problems with host lookup. In some environments
>> (such as
>> >> kubernetes) using localhost or 127.0.0.1 can be problematic.
>> >> What is the error?
>> >>
>> >> What is the status of using java8 for IT tests? (current ITs are using
>> a
>> >> very very old version of Jetty 9.0.4...)
>> >>
>> >>
>> >> On Mon, 19 Apr 2021 at 06:56, Tibor Digana 
>> wrote:
>> >>
>> >>> I had exactly the same problem and I added one more step to the CI
>> which
>> >>> checked all open ports.
>> >>> For instance they changed something in Github and 8081 or 8082 was
>> >>> allocated.
>> >>> There was a conflict with the ports and I had to shift mine, that;s
>> it.
>> >>>
>> >>> T
>> >>>
>> >>> On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders <
>> mthmuld...@apache.org>
>> >>> wrote:
>> >>>
>> >>>> Hi all,
>> >>>>
>> >>>> It seems the following IT's predictably fail on Linux (not on Windows
>> >> or
>> >>>> MacOS) in GitHub Actions, but not at all in Jenkins:
>> >>>>
>> >>>> * MavenIT0146InstallerSnapshotNaming
>> >>>> * MavenITmng2387InactiveProxyTest
>> >>>> * MavenITmng4991NonProxyHostsTest
>> >>>>
>> >>>> This is also the case in master, by the way. What they have in common
>> >> is
>> >>>> that they all spin up an HTTP server during the test, but apparently
>> >>>> that server cannot be reached under all circumstances.
>> >>>>
>> >>>> Does anyone have an idea what might be causing this and how we could
>> >>>> address this?
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> Maarten
>> >>>>
>> >>>> -
>> >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >>>> For additional commands, e-mail: dev-h...@maven.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Olivier Lamy
>> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>> >>
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: [VOTE] Release Apache Maven JXR Plugin version 3.1.1

[Tibor Digana]

+1

On Sun, Apr 18, 2021 at 9:12 PM Robert Scholte  wrote:

> Hi,
>
> We solved 12 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317527&version=12344185&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317527%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1640/
>
> https://repository.apache.org/content/repositories/maven-1640/org/apache/maven/jxr/jxr/3.1.1/jxr-3.1.1-source-release.zip
>
> Source release checksum(s):
>
> jxr-3.1.1-source-release.zip sha512: 
> d7bdbedc72568192a9b63132a91852379ad542c606d222a87cf316e1cef8e60434c4b573b55d7e39c1159cb17728eb5ae5c1cb0922337bb5c06885805a36d76c
>
> Staging site:
> https://maven.apache.org/jxr-archives/jxr-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: JPMS compile problems

[Tibor Digana]

You must have different Java packages in Jar modules in order to have
regular JMPS modules.
One user of Maven reported a bug against IntelliJ IDEA that the IDE does
not understand src/test/java/module-info.java.
The only way on how to support one common Java package and two JPMS modules
too is to bundle src/target/classes and src/target/test-classes and merge
both module-info.class, but it is against the idea of Maven lifecycle and
it may be erroneous.
T

On Sun, Apr 25, 2021 at 8:47 AM Ralph Goers 
wrote:

> I am trying to convert Log4j 2 to be fully modularized and am running into
> problems with Log4j-core.  First, I have hit a couple of nasty bugs when
> compiling
> on MacOS that are reflected in
> https://issues.apache.org/jira/browse/MCOMPILER-461 <
> https://issues.apache.org/jira/browse/MCOMPILER-461> and
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826 <
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826>.
> Basically the compiler seems to be converting directory names that have a
> class with the same name in the same package to upper case.
>
> To combat this I am forced to compile without a module-info.java during
> annotation processing and again with the module-info.java.
>
> To make matters worse, the log4j-api, log4j-plugins, and log4j-core
> modules all have test classes that need to be made available to downstream
> modules for
> testing. Prior to JPMS we just passed the test jars on, but since many of
> the unit tests need to use the same packages as the main source the test
> modules to be
> passed on had to be placed into their own “test” package and so had to be
> moved out from the rest of the unit test classes so they could be package
> in a valid
> module.
>
> As a result of this I had to convert my directory structure into
> src/main/java/ main classes
> src/main/java9/module-info.java
> src/test/java/ unit test classes & module-info.java
> src/test/java-test. Shared test classes
> src/test/java-test9/module-info.java
>
> and my build consists of:
> 1. Running Log4j’s annotation processor against the main classes without
> module-info.java.
> 2. Compiling Log4j’s main classes with module-info.java.
> 3. Compiling the separate test classes with its module-info.java.
> 4. Packaging these test classes into the tests jar.
> 5. Running Log4j’s annotation processor against the unit test classes.
> 6. Compiling the unit tests.
>
> But the build fails at step 5. If I do not include a module-info.java in
> the unit tests I get failures due to milling modules because maven is
> setting the module
> path (presumably because the main classes have one). If I do include the
> module-info.java then I run into the reported bugs and the compile fails
> with
> duplicate class errors. I’ve thought of trying to compile without
> module-info.java but I have to create a valid JPMS module for the separate
> test classes so that
> has to be done before starting on the unit tests.
>
> The only way I can see to do this is to run the annotation processor
> without the module path but it seems the compiler plugin provides no option
> to do that.
>
> My next thought is to try using
> https://github.com/bsorrentino/maven-annotation-plugin <
> https://github.com/bsorrentino/maven-annotation-plugin> to perform the
> annotation processing and see if I have better luck.
>
> I should also add that these projects look like hell in Intellij as it has
> no idea how to resolve the second test directory.
>
> Does anyone have any thoughts on how this could be more easily
> accomplished?  I can’t imagine I am the only person who needs to create a
> valid test jar.
>
> Ralph

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.1.2

[Tibor Digana]

+1

On Sun, Apr 25, 2021 at 9:46 PM Michael Osipov  wrote:

> Hi,
>
> We solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&version=12349521
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1642/
>
> https://repository.apache.org/content/repositories/maven-1642/org/apache/maven/plugins/maven-project-info-reports-plugin/3.1.2/maven-project-info-reports-plugin-3.1.2-source-release.zip
>
> Source release checksum(s):
> maven-project-info-reports-plugin-3.1.2-source-release.zip
> sha512:
>
> 9cd09f24de9a11530116f1b40c403557d0c9bfdbdca4f05be4db52ec9cdb9a75d1faa1104eae16c0ea7ece90b7c6fe09139f6738a4862ab67a0c57e695f1761f
>
> Staging site:
>
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Plugin Tools version 3.6.1

[Tibor Digana]

+1

On Fri, Apr 23, 2021 at 2:56 PM Robert Scholte  wrote:

> Hi,
>
> We solved 14 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820&version=12344365&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317820%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1641/
>
> https://repository.apache.org/content/repositories/maven-1641/org/apache/maven/plugin-tools/maven-plugin-tools/3.6.1/maven-plugin-tools-3.6.1-source-release.zip
>
> Source release checksum(s):
>
> maven-plugin-tools-3.6.1-source-release.zip sha512: 
> 53346c71923025ec5935fb944a356535ad77b68768087e021b669e9736a8800db879839e5707b3b0a4d0cd45401481e98850148b68e3f76059325cb60ea0b4b5
>
> Staging site:
> https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: MNG-6843 Parallel build fails due to missing JAR artifacts in compilePath

[Tibor Digana]

We have already moved ahead and the new Resolver should solve this issue.
This looks similar to the issue in Surefire which was closed as a bug of
Resoler. Michael is currently working on a new Resolver and he was
participating in the analysis of the bug too. So, maybe it is still the
same root cause for this one.

T

On Sun, May 2, 2021 at 10:24 PM Dan Tran  wrote:

> we are in pain with this issue :-)
>
> -D
>
> On Sun, Jan 24, 2021 at 2:56 PM Tibor Digana 
> wrote:
>
> > Hi Falco,
> >
> > This is not the first time I have been talking about these principles in
> > our team.
> > Seven years ago and then in 2019. But sorry I cannot force the people to
> do
> > it and they have to start by themself. We have to do it together.
> > All I can do is to provide some training and elaborate a problem but I am
> > convinced that we will meet again after the next seven years if we
> > don't understand the JMM. Thus we should prevent from redoing the same
> bad
> > and understand the process on how to make the code better in the early
> > beginning.
> >
> > Cheers
> > Tibor17
> >
> >
> > On Sun, Jan 24, 2021 at 10:51 PM Falko Modler  wrote:
> >
> > > Hi Tibor,
> > >
> > > thanks for this very elaborate answer and I always appreciate your
> > > feedback, but to me it kind of misses the point a bit...?
> > >
> > > > may not necessarily have to do with concurrent access.
> > > But it does in this special case. Please see the issue and the linked
> > > explanations.
> > >
> > > > The solution with ThreadLocal would eat too much memory.
> > > Is that so? Are you sure about this? How much is "too much"?
> > > Are there any predefined profiling tests I can run?
> > >
> > > I mean: yes, it is a workaround and immutable core classes that are
> > > _designed_ for concurrent access would be much better,
> > > but who is going to do such a massive refactoring (without breaking
> > > Maven extensions that are today mutating MavenProject etc.)?
> > >
> > > TBH, this is one of the, IMHO, critical bugs that should have been
> fixed
> > > before Maven 4.
> > >
> > > Cheers,
> > > Falko
> > >
> > > Am 21.01.2021 um 02:13 schrieb Tibor Digana:
> > > > I commented on one issue regarding the NULL JAR file in Artifact a
> few
> > > days
> > > > ago.
> > > > The thing that some data is "missing" in some large object structures
> > in
> > > > the environment with multiple threads may not necessarily have to do
> > with
> > > > concurrent access.
> > > > There may not be any writes to MavenProject or MavenSession causing
> > > > "missed" data, and the answer why this happens is Memory Model.
> > > >
> > > > It's the fact that non-concurrent or non-immutable objects may lose
> > some
> > > > references very easily!
> > > > This has all to do with JMM and not the happens-before relationship.
> > > >
> > > > Suppose that we have thread T1 creating ArrayList and adding elements
> > > into
> > > > this collection.
> > > > artifacts = new ArrayList();
> > > > artifacts.add(new DefaultArtifact(...));
> > > >
> > > > Suppose thread T2 reads the artifacts from the collection right after
> > > > "artifacts.add()".
> > > > Artifact a = artifacts.get(0);
> > > >
> > > > In practice the following happens:
> > > > artifacts.size() returns 1
> > > > but artifacts.get(0) returns NULL
> > > >
> > > > Let;s explain why it happens.
> > > > The implementation of ArrayList is not native. It is a pure Java
> > > > implementation which has two variables inside:
> > > > + count:int
> > > > + array:Object[]
> > > > These two variables always appear in a critical section and they do
> not
> > > > have proper treatments in ArrayList.
> > > > Technically, the things are complicated on the CPU level and more
> > > > complicated than happens-before theorems.
> > > > T1 contains pointers and data in CPU registers or CPU cache. No
> Thread
> > > has
> > > > a direct access to a stack of another Thread, and of course it does
> not
> > > > operate on main memory.
> > > > The CPU uses memory barriers (assembler instructions) and a cache to
> > > &g

Re: [VOTE] Release Apache Maven GPG Plugin version 3.0.1

[Tibor Digana]

+1   but I have one negative remark to the tradition with "Merge pull
request". If you watch the code, you would think that the project
duplicates some code, but it is not real. Whole problem is with these Merge
requests because they join several commits together, you type some comments
to the developers about code duplicates but then you realise that the Merge
Requests are totally messy and you are not able to separate PR changes from
the changes of other PRs or colleagues. Here is the history:

https://github.com/apache/maven-gpg-plugin/commits/master


T

On Wed, May 5, 2021 at 6:46 PM Hervé BOUTEMY  wrote:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&version=12348086&styleName=Text
>
> in addition to the cancelled 3.0.0 release candidate that solved 13 other
> issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&version=12330781&styleName=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1645/
>
> https://repository.apache.org/content/repositories/maven-1645/org/apache/maven/plugins/maven-gpg-plugin/3.0.1/maven-gpg-plugin-3.0.1-source-release.zip
>
> Source release checksum(s):
> maven-gpg-plugin-3.0.1-source-release.zip sha512:
> 10eef9c1f3e71724b328e0f8d76303d251922a4e7a05ffbbe44191e2293c097e976b0f6b7ec3b8783b04da13c74bbe5b34f4dabc5e0dd3a7cb5fe7aa92122af0
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Resolver version 1.7.0

[Tibor Digana]

+1


On Sat, May 8, 2021 at 11:36 AM Michael Osipov  wrote:

> Hi,
>
> we solved 23 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12349416
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20Resolver
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1646/
>
> https://repository.apache.org/content/repositories/maven-1646/org/apache/maven/resolver/maven-resolver/1.7.0/maven-resolver-1.7.0-source-release.zip
>
> Source release checksum(s):
> maven-resolver-1.7.0-source-release.zip
>
> 6d7d7ca9e6fc07623856646f18bd6054127a3f190b27568bca52b16398694edb3ebb00d5be14cf472b4e6ea40c0e2f54103e2237af825dc9dfb4f3a30478e21c
>
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Artifact Plugin version 3.1.0

[Tibor Digana]

+1
@Herve you'r welcome ;-)
T

On Sun, May 9, 2021 at 8:15 PM Hervé BOUTEMY  wrote:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324322&version=12349726&styleName=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1647/
>
> https://repository.apache.org/content/repositories/maven-1647/org/apache/maven/plugins/maven-artifact-plugin/3.1.0/maven-artifact-plugin-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-artifact-plugin-3.1.0-source-release.zip sha512:
> 355dc1704decec85a1af78a6541c468506475e2a0edc213a1609fc0039803a5c2ef3f071517cfa983a64b28ba8ba2c9cad5fce765cab6e5991f5adc470ce8872
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-artifact-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Resolver Ant Tasks version 1.3.1

[Tibor Digana]

+1

On Thu, May 13, 2021 at 8:17 PM Michael Osipov  wrote:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12350159
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20component%20%3D%20%22ant%20tasks%22%20AND%20resolution%20%3D%20Unresolved%20
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1648/
>
> https://repository.apache.org/content/repositories/maven-1648/org/apache/maven/resolver/maven-resolver-ant-tasks/1.3.1/maven-resolver-ant-tasks-1.3.1-source-release.zip
>
> Source release checksum(s):
> maven-resolver-ant-tasks-1.3.1-source-release.zip
> sha512:
>
> ce64c7220fb71c55367a29d795c4527f17251fd7e488e9579ba63ff008bc2e72b72208b9ef9281a52a931e49852882c48bace1b6a69c79751360ad86f5a815e7
>
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-ant-tasks-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Race condition in slf4j-simple

[Tibor Digana]

Hi Ceki,

The Jira issue is https://jira.qos.ch/browse/SLF4J-515

T

On Thu, Jul 8, 2021 at 3:54 PM Ceki  wrote:

> Hi Tibor,
>
> Your analysis makes sense. As SimpleLogger acts as an appender as found
> in log4j/logback backends, SimpleLogger should cater for concurrent
> access with some sort of synchronization. It currently does not.
>
> Please create a jira issue for this problem.
>
> Best regards,
> --
> Ceki Gülcü
>
> On 08.07.2021 15:23, Tibor Digaňa wrote:
> > Hi Ceki,
> >
> > We have observed a strange behavior of the logger slf4j-simple when two
> > or more parallel Maven modules log the exceptions and the messages.
> >
> > It produces corrupted lines in the log and they are partially mixed with
> > other lines.
> > The lines look like this and they are obviously not expected in the log.
> >
> > [ERROR] R] *.util.json.formatter.JsonFormatterTest
> >   [ERROR] Process Exit Code: 0
> > [ERROR] *.util.json.formatter.JsonFormatterTest
> >
> >
> > After our analysis we found the place in SLF4J code which seems to be
> > the root cause.
> >
> > The method [1] is a critical section and must be synchronized with a
> > singleton lock which avoids reordering of the nested method calls across
> > multiple Threads. Without it, the normal messages and stack trace may
> > mix especially if two parallel Maven modules print the stacktrace.
> >
> > [1]:
> >
> https://github.com/qos-ch/slf4j/blob/39e3b81e5ea69c6610c8d5fd57fd974e090d9fc1/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLogger.java#L243
> > <
> https://github.com/qos-ch/slf4j/blob/39e3b81e5ea69c6610c8d5fd57fd974e090d9fc1/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLogger.java#L243
> >
> >
> > Pls analyse the class SimpleLogger.java and answer with your opinion
> > about this issue and a proposal with the fix.
> > If there are more other critical sections which need to have some
> > concurrency treatments, we can talk about it in this mailing list.
> >
> > --
> > Cheers
> > Tibor
>
>
>

Re: [VOTE] Import mvndaemon/mvnd project @ Apache

[Tibor Digana]

+1

Tibor

On Wed, Jun 16, 2021 at 8:50 AM Olivier Lamy  wrote:

> Hi
> As already proposed by Guillaume, it looks to be a good idea to
> import mvndaemon/mvnd here at Apache.
>
> I'd like to propose a vote for this.
> +1: import the project here
> 0  : no real idea
> -1 : no (please explain why)
>
> cheers
> --
> Olivier
> PS: Actually I have no idea how binding works in such vote.
>

Re: [VOTE] Release Apache Parent POM version 24

[Tibor Digana]

A good patch!
+1

T

On Sat, Jul 10, 2021 at 3:39 AM Hervé BOUTEMY  wrote:

> Hi,
>
> We solved 17 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250&version=12346845&styleName=Text
>
> https://github.com/apache/maven-apache-parent/compare/apache-23...apache-24
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheapache-1021/
>
> https://repository.apache.org/content/repositories/orgapacheapache-1021/org/apache/apache/24/apache-24-source-release.zip
>
> Source release checksum(s):
> apache-24-source-release.zip sha512:
> 3c0667eee535523ba16309c991e5aed4ef59f48bae623eea6757762ff03ec3ef3ab51d11958a75c032efb95be491c2c8a367b46c7ca0104e6203a5003c878ad8
>
> Staging site:
> https://maven.apache.org/pom-archives/asf-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Shade Plugin version 3.3.0

[Tibor Digana]

-1, the reason is that the contributors and committers are waiting for PR
#90 and #95, and pls restart the Vote which is faster right now.
T

On Sun, Jul 18, 2021 at 12:34 PM Michael Osipov  wrote:

> I need one more binding vote...
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Shade Plugin version 3.3.0

[Tibor Digana]

In my experience, one should make a lookup through the pull-requests, these
two #90 #95 are ready to go. It is not harmful to say -1 since Andreas as
an author of the PR provided arguments for his PR and I can see that it was
matter of time, one/two/three days, which correlates with the time period
of the release, therefore the release manager should have a look, ask for
PR competition and then it is does not matter if the release Vote would
start today or three days later. The people who are developing the PR for
several months and it is close to complete, it would be worth pinging them
to complete it asap and include the fix in release notes.
T

On Sun, Jul 18, 2021 at 5:53 PM Enrico Olivelli  wrote:

> Tibor
>
> Il Dom 18 Lug 2021, 17:06 Tibor Digana  ha
> scritto:
>
> > -1, the reason is that the contributors and committers are waiting for PR
> > #90 and #95, and pls restart the Vote which is faster right now.
> > T
> >
>
> In my humble opinion this is not a good motivation for a binding -1.
>
> If the code is in good shape and there are no blockers there is no need to
> block the release.
> It is up to the RM to decide whether to cut a new RC.
>
> That said, everybody is free to cast his/her VOTE the way he/she likes
>
> Enrico
>
>
> > On Sun, Jul 18, 2021 at 12:34 PM Michael Osipov 
> > wrote:
> >
> > > I need one more binding vote...
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Re: [shade] which java version

[Tibor Digana]

What's the cost of this task? A day?
Do you want to include it in the release version  3.4.0?


On Wed, Jul 21, 2021 at 8:09 AM Romain Manni-Bucau 
wrote:

> Hi all,
>
> shade plugin pom defines java version to 7 (1.7) but it uses streams which
> are java 8 only, should javaVersion property be updated?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>

Re: [JENKINS] - New Maven Controller for the project

[Tibor Digana]

In my company, I also used 1GB for Xmx of Java Heap for the Jenkins JVM and
it was enough.
The subprocesses like Maven need to have much more memory to allocate for
themself rather than Jenkins JVM.
T

On Wed, Jul 21, 2021 at 6:38 PM Arnaud Héritier  wrote:

> I am looking at our builds and I try to understand why our agents are often
> disconnected during the builds.
> We have in general a stacktrace like
>
> maven6 was marked offline: Connection was broken: java.io.IOException:
> Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:118)
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:101)
> at
> hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:92)
> at
> hudson.remoting.ChunkedInputStream.readHeader(ChunkedInputStream.java:73)
> at
> hudson.remoting.ChunkedInputStream.readUntilBreak(ChunkedInputStream.java:103)
> at
> hudson.remoting.ChunkedCommandTransport.readBlock(ChunkedCommandTransport.java:39)
> at
> hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
> at
> hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:63)
>
>
>
> As far I can see we are using 16Gb "hosts" for linux agents
>
> Something very strange is that the jenkins agent (this small component
> doing the link between the build host and the controller) is configured
> with `-Xms8g -Xmx8g` thus we are reserving for it 50% of the server mem
> (even more because of the non-heap)
> This one in general should require in general really less. 1Gb is already a
> lot from my exp.
> Due to this, the OS can see it has the biggest process on the host and
> decide to kill it when the rest of the memory is used by the build.
> I think we should decrease this value.
> (I can do it but I don't know how was configured the ci.apache.org agents
> and I would like to not add more issue if this setting was here in the past
>
> I don't think it is the root cause of our instabilities (at least all) and
> there is something else I have to find but it's a cheap fix to try
>
> FYI our agents VMs are ~like this today:
>
> - Java
> + Home: `/usr/local/asfpackages/java/oraclejdk-1.8.0-291/jre`
> + Vendor: Oracle Corporation
> + Version: 1.8.0_291
> + Maximum memory: 7.67 GB (8232370176)
> + Allocated memory: 7.67 GB (8232370176)
> + Free memory: 6.03 GB (6470953760)
> + In-use memory: 1.64 GB (1761416416)
> + GC strategy: ParallelGC
> + Available CPUs: 4
>
> 8Gb is reserved, 1Gb is used (because the GC does nothing as the Free mem
> is high)
>
> I would be in favor to try to launch them with -Xms128m
> -Xmx1g -XX:+UseG1GC -XX:+UseStringDeduplication
>
> I think it's enough customization to start with
>
> Cheers
>
> On Wed, Jul 21, 2021 at 1:28 PM Arnaud Héritier 
> wrote:
>
> > I am not sure about the setup
> > AFAICS we don't use any JDK installer (
> > https://ci-maven.apache.org/configureTools/ ) thus I suppose that the
> > different JDKs are supposed to be installed directly on the agent ?
> > I am not sure how it was done on the previous environment
> >
> > On Sun, Jul 18, 2021 at 5:30 PM Tibor Digana 
> > wrote:
> >
> >> The new CI  system has the following issue:
> >>
> >> /home/jenkins/tools/java/latest1.7/bin/java: not found
> >>
> >>
> >>
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-surefire/job/master/104/execution/node/183/log/
> >>
> >>
> >>
> >> On Wed, Jun 30, 2021 at 8:03 PM Gavin McDonald 
> >> wrote:
> >>
> >> > Hi Maven folks.
> >> >
> >> > Infra has decided to separate off the Maven build jobs from
> >> > ci-builds.apache.org over to its very own Jenkins Controller and
> >> Agents.
> >> >
> >> > This means that Maven now has a dedicated Jenkins environment for
> >> itself.
> >> > It
> >> > also means that no other projects build jobs can build on the Maven
> >> nodes;
> >> > and
> >> > then Maven jobs will no longer  be able to build on the ci-builds
> jobs.
> >> >
> >> > Your new Controller is set up as https://ci-maven.apache.org and all
> >> Maven
> >> > Committers
> >> > can login via LDAP and create jobs.
> >> >
> >> > At the time of writing, there is one node/agent attached but I 

New release of Maven Shade Plugin

[Tibor Digana]

Can we cut a new release of m-shade-p?
Is there any pending bug fix or improvement that you want to include in the
release?

Cheers
Tibor

Re: [JENKINS] - New Maven Controller for the project

[Tibor Digana]

Can you install AdoptOpenJdk for the Jenkins controller?
It contains Eclipse OpenJ9 Garbage Collector and it significantly decreases
memory consumption of the application due to the meta space goes to the
disk.
You should save 40 - 75% out of 3GB.
I used G1, Shenandoah, ZGC and Eclipse OpenJ9 which saved the most memory.

On Thu, Jul 22, 2021 at 9:23 AM Arnaud Héritier  wrote:

> yes for the controller it depends of its size (number of jobs and types of
> jobs) but here we are fine it seems with our 3Gb
>
> * Java
> - Version: 1.8.0_292
> - Maximum memory: 3.00 GB (3221225472)
> - Allocated memory: 3.00 GB (3221225472)
> - Free memory: 750.15 MB (786591664)
> - In-use memory: 2.27 GB (2434633808)
> - GC strategy: G1
> - Available CPUs: 2
>
> For agents I reduced the memory allocated to the agent process but it
> doesn't help much (it seems - even if it is still a good thing to do)
>
> What is strange is that I see our agents sometimes disconnected even when
> we have no activity on the jenkins controller
>
> Sadly jenkins is deployed on Apache Tomcat thus I cannot get access to its
> logs
>
> In general the connection lost is detected by what we call the PingThread (
>
> https://www.jenkins.io/doc/book/system-administration/monitoring/#ping-thread
> ) but not only
>
> https://ci-maven.apache.org/log/all
>
> For example it was few minutes ago we got 3 agents disconnected while
> nothing was running
>
> 2021-07-22 06:58:21.769+ [id=106291] INFO
> hudson.slaves.ChannelPinger$1#onDead:
> Ping failed. Terminating the channel maven4.
> java.util.concurrent.TimeoutException: Ping started at 1626936861769 hasn't
> completed by 1626937101769
> at hudson.remoting.PingThread.ping(PingThread.java:134)
> at hudson.remoting.PingThread.run(PingThread.java:90)
> 2021-07-22 06:58:21.778+ [id=106292] INFO
> hudson.slaves.ChannelPinger$1#onDead:
> Ping failed. Terminating the channel maven3.
> java.util.concurrent.TimeoutException: Ping started at 1626936861777 hasn't
> completed by 1626937101778
> at hudson.remoting.PingThread.ping(PingThread.java:134)
> at hudson.remoting.PingThread.run(PingThread.java:90)
> 2021-07-22 06:58:21.983+ [id=106295] INFO
> hudson.slaves.ChannelPinger$1#onDead:
> Ping failed. Terminating the channel maven5.
> java.util.concurrent.TimeoutException: Ping started at 1626936861982 hasn't
> completed by 1626937101983
> at hudson.remoting.PingThread.ping(PingThread.java:134)
> at hudson.remoting.PingThread.run(PingThread.java:90)
>
> @Gavin McDonald  In terms of network, is it the same
> environment we use today compared to the ci-builds.apache.org environment
> ?
>
>
> On Wed, Jul 21, 2021 at 11:48 PM Tibor Digana 
> wrote:
>
> > In my company, I also used 1GB for Xmx of Java Heap for the Jenkins JVM
> and
> > it was enough.
> > The subprocesses like Maven need to have much more memory to allocate for
> > themself rather than Jenkins JVM.
> > T
> >
> > On Wed, Jul 21, 2021 at 6:38 PM Arnaud Héritier 
> > wrote:
> >
> > > I am looking at our builds and I try to understand why our agents are
> > often
> > > disconnected during the builds.
> > > We have in general a stacktrace like
> > >
> > > maven6 was marked offline: Connection was broken: java.io.IOException:
> > > Pipe closed after 0 cycles
> > > at
> > >
> >
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:118)
> > > at
> > >
> >
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:101)
> > > at
> > >
> >
> hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:92)
> > > at
> > >
> hudson.remoting.ChunkedInputStream.readHeader(ChunkedInputStream.java:73)
> > > at
> > >
> >
> hudson.remoting.ChunkedInputStream.readUntilBreak(ChunkedInputStream.java:103)
> > > at
> > >
> >
> hudson.remoting.ChunkedCommandTransport.readBlock(ChunkedCommandTransport.java:39)
> > > at
> > >
> >
> hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
> > > at
> > >
> >
> hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:63)
> > >
> > >
> > >
> > > As far I can see we are using 16Gb "hosts" for linux agents
> > >
> > > Something very strange is that the jenkins agent (this small component
> > > 

Re: [VOTE] Release Apache Maven version 3.8.2

[Tibor Digana]

+1

On Wed, Aug 4, 2021 at 10:02 PM Michael Osipov  wrote:

> Hi,
>
> We solved 68 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12349965
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1657/
>
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.2/
>
> Source release checksums:
> apache-maven-3.8.2-src.zip sha512:
>
> 228ae07dfd89f73cc7d0b10b60708db2730465dbe6022968bde6c5d7f0df9bcd7f460fe1d8012726a29f136486bdb63d1e1ba932e307380fe4c1f4db440407dd
> apache-maven-3.8.2-src.tar.gz sha512:
>
> 617377ad85ced7961f972610ed88535fd3f1ab18e104556d8a3adee7769515ee67ee3cbaff50afcffd74a443b471b806acb1ae92f91a259bc8ccaab56795baf6
>
> Binary release checksums:
> apache-maven-3.8.2-bin.zip sha512:
>
> 59ad2cbd6b7abde34ebedda94ce5631256373718e71b55202035bd1190d0144f071433f78b99e16f1204413b3eb888659e5039009e1ad0106f16332e3c62bced
> apache-maven-3.8.2-bin.tar.gz sha512:
>
> b0bf39460348b2d8eae1c861ced6c3e8a077b6e761fb3d4669be5de09490521a74db294cf031b0775b2dfcd57bd82246e42ce10904063ef8e3806222e686f222
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/251
>
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: JUnit Platform, forkCount > 1 and the TestPlan

[Tibor Digana]

If you use forkCount > 1, the Surefire loads test classes via load balancer.
If you use default forkCount = 0, all the classes are run eagerly as a
suite via JUnit5 Launcher in one shot.

If you are aiming for Arquillian, testing the applications in the
application server, you should use maven-failsafe-plugin which has another
testing model.
See the plugin goals of Failsafe plugin. Maven Failsafe Plugin – Plugin
Documentation (apache.org)

https://maven.apache.org/surefire/maven-failsafe-plugin/plugin-info.html
There are Maven phases:
pre-integration-test
integration-test
post-integration-test
verify

Therefore you should start the application server in the phase
pre-integration-test.
Accordingly, you should stop it in the phase post-integration-test.

Then use Failsafe plugin in the phases integration-test and verify.

Cheers
Tibor



On Fri, Sep 10, 2021 at 12:42 PM Emond Papegaaij 
wrote:

> Hi all,
>
> First of all, sorry for the lengthy post. I decided to add some context to
> explain things a bit, but it resulted in quite a long e-mail. For the past
> few weeks I've been trying to come up with a solution for the issue I
> filled under SUREFIRE-1935, but I'm getting stuck and starting to feel like
> the issue cannot be solved with the current JUnit Platform API. To give
> some perspective into why this issue is important for us, I first have to
> explain a bit about our setup.
>
> We write our tests in the Spock framework and use Arquillian to run the
> tests in the application container. Some of our tests, especially the
> Selenium based tests, require quite some setup and tear down. Prior to
> starting the test, Arquillian cube builds and starts several docker
> containers and the tests are run against these containers. We currently use
> the JUnit 4 based Spock 1.3 with Groovy 2.5, but we like to upgrade to
> Spock 2 and Groovy 3, which runs on top of the JUnit Platform. For this,
> I've already started working on a Spock extension that integrates Spock 2
> in the Arquillian test life cycle [1]. This extension is inspired by the
> (currently Alpha) JUnit5 module for Arquillian [2]. Both use a global
> registration to keep track of the state managed by Arquilllian. This will
> end up somewhere at the root of the TestPlan (for example see [3]).
>
> Because our tests are quite extensive, with a total run time of 6 hours, we
> run them with a forkCount of 8, greatly reducing the total duration.
> However, this is where SUREFIRE-1935 comes into play. With a forkCount > 1,
> the entire test life cycle is started over and over again for every test
> class. This happens in JUnitPlatformProvider at line 197 [4]. This results
> in the entire Arquillian suite being torn down and setup for every class,
> in our case adding several minutes to the execution of every test class
> because the docker setup is done over and over again.
>
> To overcome this issue, the state from one test class execution has to be
> carried to the next. It seems the LauncherSession (introduced in JUnit 5.8)
> is meant to close this gap. However, this would mean my extension would
> also need to implement a LauncherSessionListener, and I'm not sure if
> extensions are supposed to integrate with the launcher as well. Also, for
> this surefire would need to start a session prior to the tests, and close
> it when done. I think this is a good idea anyway when running on platform
> 1.8 or higher.
>
> Another solution could be a (sort of) dynamic test that produces the tests
> to be run one by one. However, here my knowledge of JUnit really falls
> short. I've got no idea of this is even possible.
>
> I hope someone can help me out on this one and point me in the right
> direction, as we like to upgrade our test frameworks and this is blocking
> us at the moment.
>
> Best regards,
> Emond Papegaaij
>
> [1] Arquillian extension for Spock Framework 2:
>
> https://github.com/topicusonderwijs/arquillian-testrunner-spock/tree/spock-2.0-junit5
> [2] Arquillian module for JUnit 5:
> https://github.com/arquillian/arquillian-core/tree/master/junit5
> [3] Registration in root store:
>
> https://github.com/arquillian/arquillian-core/blob/master/junit5/core/src/main/java/org/jboss/arquillian/junit5/JUnitJupiterTestClassLifecycleManager.java#L20
> [4] JUnitPlatformProvider launching the tests:
>
> https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java#L197
>

Re: JUnit Platform, forkCount > 1 and the TestPlan

[Tibor Digana]

Please read the documentation
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

On Fri, Sep 10, 2021 at 5:05 PM Tibor Digana  wrote:

> If you use forkCount > 1, the Surefire loads test classes via load
> balancer.
> If you use default forkCount = 0, all the classes are run eagerly as a
> suite via JUnit5 Launcher in one shot.
>
> If you are aiming for Arquillian, testing the applications in the
> application server, you should use maven-failsafe-plugin which has another
> testing model.
> See the plugin goals of Failsafe plugin. Maven Failsafe Plugin – Plugin
> Documentation (apache.org)
> <https://maven.apache.org/surefire/maven-failsafe-plugin/plugin-info.html>
> https://maven.apache.org/surefire/maven-failsafe-plugin/plugin-info.html
> There are Maven phases:
> pre-integration-test
> integration-test
> post-integration-test
> verify
>
> Therefore you should start the application server in the phase
> pre-integration-test.
> Accordingly, you should stop it in the phase post-integration-test.
>
> Then use Failsafe plugin in the phases integration-test and verify.
>
> Cheers
> Tibor
>
>
>
> On Fri, Sep 10, 2021 at 12:42 PM Emond Papegaaij <
> emond.papega...@gmail.com> wrote:
>
>> Hi all,
>>
>> First of all, sorry for the lengthy post. I decided to add some context to
>> explain things a bit, but it resulted in quite a long e-mail. For the past
>> few weeks I've been trying to come up with a solution for the issue I
>> filled under SUREFIRE-1935, but I'm getting stuck and starting to feel
>> like
>> the issue cannot be solved with the current JUnit Platform API. To give
>> some perspective into why this issue is important for us, I first have to
>> explain a bit about our setup.
>>
>> We write our tests in the Spock framework and use Arquillian to run the
>> tests in the application container. Some of our tests, especially the
>> Selenium based tests, require quite some setup and tear down. Prior to
>> starting the test, Arquillian cube builds and starts several docker
>> containers and the tests are run against these containers. We currently
>> use
>> the JUnit 4 based Spock 1.3 with Groovy 2.5, but we like to upgrade to
>> Spock 2 and Groovy 3, which runs on top of the JUnit Platform. For this,
>> I've already started working on a Spock extension that integrates Spock 2
>> in the Arquillian test life cycle [1]. This extension is inspired by the
>> (currently Alpha) JUnit5 module for Arquillian [2]. Both use a global
>> registration to keep track of the state managed by Arquilllian. This will
>> end up somewhere at the root of the TestPlan (for example see [3]).
>>
>> Because our tests are quite extensive, with a total run time of 6 hours,
>> we
>> run them with a forkCount of 8, greatly reducing the total duration.
>> However, this is where SUREFIRE-1935 comes into play. With a forkCount >
>> 1,
>> the entire test life cycle is started over and over again for every test
>> class. This happens in JUnitPlatformProvider at line 197 [4]. This results
>> in the entire Arquillian suite being torn down and setup for every class,
>> in our case adding several minutes to the execution of every test class
>> because the docker setup is done over and over again.
>>
>> To overcome this issue, the state from one test class execution has to be
>> carried to the next. It seems the LauncherSession (introduced in JUnit
>> 5.8)
>> is meant to close this gap. However, this would mean my extension would
>> also need to implement a LauncherSessionListener, and I'm not sure if
>> extensions are supposed to integrate with the launcher as well. Also, for
>> this surefire would need to start a session prior to the tests, and close
>> it when done. I think this is a good idea anyway when running on platform
>> 1.8 or higher.
>>
>> Another solution could be a (sort of) dynamic test that produces the tests
>> to be run one by one. However, here my knowledge of JUnit really falls
>> short. I've got no idea of this is even possible.
>>
>> I hope someone can help me out on this one and point me in the right
>> direction, as we like to upgrade our test frameworks and this is blocking
>> us at the moment.
>>
>> Best regards,
>> Emond Papegaaij
>>
>> [1] Arquillian extension for Spock Framework 2:
>>
>> https://github.com/topicusonderwijs/arquillian-testrunner-spock/tree/spock-2.0-junit5
>> [2] Arquillian module for JUnit 5:
>> https://github.com/arquillian/arquillian-core/tree/master/junit5
>> [3] Registration in root store:
>>
>> https://github.com/arquillian/arquillian-core/blob/master/junit5/core/src/main/java/org/jboss/arquillian/junit5/JUnitJupiterTestClassLifecycleManager.java#L20
>> [4] JUnitPlatformProvider launching the tests:
>>
>> https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java#L197
>>
>

Re: JUnit Platform, forkCount > 1 and the TestPlan

[Tibor Digana]

We have to dig into Junit 5. Surefire is a streamer of classes across the
forks which is our load balancer. Therefore each class is running
separately, pre and post fixtures. If the Junit 5 used Java Streamer
including dome kind of control of fixtures then web would have this issue.

Dňa pi 10. 9. 2021, 18:03 Emond Papegaaij 
napísal(a):

> On Fri, Sep 10, 2021 at 5:06 PM Tibor Digana 
> wrote:
>
> > If you use forkCount > 1, the Surefire loads test classes via load
> > balancer.
> > If you use default forkCount = 0, all the classes are run eagerly as a
> > suite via JUnit5 Launcher in one shot.
> >
>
> Yes, this is what I saw in the JUnitPlatformProvider. The cause of my
> issues lies in the difference in events triggered by Arquillian due to the
> classes executed one by one. The demo-project attached to the ticket
> demonstrates this in just a few lines of code.
>
> If you are aiming for Arquillian, testing the applications in the
> > application server, you should use maven-failsafe-plugin which has
> another
> > testing model.
> > See the plugin goals of Failsafe plugin. Maven Failsafe Plugin – Plugin
> > Documentation (apache.org)
> > <
> https://maven.apache.org/surefire/maven-failsafe-plugin/plugin-info.html>
> > https://maven.apache.org/surefire/maven-failsafe-plugin/plugin-info.html
> > There are Maven phases:
> > pre-integration-test
> > integration-test
> > post-integration-test
> > verify
> >
> > Therefore you should start the application server in the phase
> > pre-integration-test.
> > Accordingly, you should stop it in the phase post-integration-test.
> >
> > Then use Failsafe plugin in the phases integration-test and verify.
> >
>
> Unfortunately, this is not how arquillian is setup. You can run tests
> against running servers (which you can then start in pre-integration-test),
> but using arquillian cube, these containers can be started as part of the
> test lifecycle. Also, Arquillian is just a single incarnation of the
> underlying issue. Every extension that takes more than a few seconds to
> start and is built to only initialize once for a suite will trigger this
> same problem (as can be seen by the demo project). As surefire and failsafe
> use the same JUnitPlatformProvider, the problem will also be the same.
>
> What do you think about the solution of using a LauncherSession to bind the
> multiple executions together? This will require JUnit Platform 1.8 and
> changes in the JUnitPlatformProvider. However, I'm not sure what the
> intended audience of LauncherSessionListener is.
>
> Best regards,
> Emond
>
> On Fri, Sep 10, 2021 at 12:42 PM Emond Papegaaij <
> emond.papega...@gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > First of all, sorry for the lengthy post. I decided to add some context
> > to
> > > explain things a bit, but it resulted in quite a long e-mail. For the
> > past
> > > few weeks I've been trying to come up with a solution for the issue I
> > > filled under SUREFIRE-1935, but I'm getting stuck and starting to feel
> > like
> > > the issue cannot be solved with the current JUnit Platform API. To give
> > > some perspective into why this issue is important for us, I first have
> to
> > > explain a bit about our setup.
> > >
> > > We write our tests in the Spock framework and use Arquillian to run the
> > > tests in the application container. Some of our tests, especially the
> > > Selenium based tests, require quite some setup and tear down. Prior to
> > > starting the test, Arquillian cube builds and starts several docker
> > > containers and the tests are run against these containers. We currently
> > use
> > > the JUnit 4 based Spock 1.3 with Groovy 2.5, but we like to upgrade to
> > > Spock 2 and Groovy 3, which runs on top of the JUnit Platform. For
> this,
> > > I've already started working on a Spock extension that integrates
> Spock 2
> > > in the Arquillian test life cycle [1]. This extension is inspired by
> the
> > > (currently Alpha) JUnit5 module for Arquillian [2]. Both use a global
> > > registration to keep track of the state managed by Arquilllian. This
> will
> > > end up somewhere at the root of the TestPlan (for example see [3]).
> > >
> > > Because our tests are quite extensive, with a total run time of 6
> hours,
> > we
> > > run them with a forkCount of 8, greatly reducing the total duration.
> > > However, this is where SUREFIRE-1935 comes into play. With a forkCount
> >
> &

Re: JUnit Platform, forkCount > 1 and the TestPlan

[Tibor Digana]

Sorry for typos, I sent it from my mobile.
T

On Fri, Sep 10, 2021 at 6:18 PM Tibor Digana  wrote:

> We have to dig into Junit 5. Surefire is a streamer of classes across the
> forks which is our load balancer. Therefore each class is running
> separately, pre and post fixtures. If the Junit 5 used Java Streamer
> including dome kind of control of fixtures then web would have this issue.
>
> Dňa pi 10. 9. 2021, 18:03 Emond Papegaaij 
> napísal(a):
>
>> On Fri, Sep 10, 2021 at 5:06 PM Tibor Digana 
>> wrote:
>>
>> > If you use forkCount > 1, the Surefire loads test classes via load
>> > balancer.
>> > If you use default forkCount = 0, all the classes are run eagerly as a
>> > suite via JUnit5 Launcher in one shot.
>> >
>>
>> Yes, this is what I saw in the JUnitPlatformProvider. The cause of my
>> issues lies in the difference in events triggered by Arquillian due to the
>> classes executed one by one. The demo-project attached to the ticket
>> demonstrates this in just a few lines of code.
>>
>> If you are aiming for Arquillian, testing the applications in the
>> > application server, you should use maven-failsafe-plugin which has
>> another
>> > testing model.
>> > See the plugin goals of Failsafe plugin. Maven Failsafe Plugin – Plugin
>> > Documentation (apache.org)
>> > <
>> https://maven.apache.org/surefire/maven-failsafe-plugin/plugin-info.html>
>> >
>> https://maven.apache.org/surefire/maven-failsafe-plugin/plugin-info.html
>> > There are Maven phases:
>> > pre-integration-test
>> > integration-test
>> > post-integration-test
>> > verify
>> >
>> > Therefore you should start the application server in the phase
>> > pre-integration-test.
>> > Accordingly, you should stop it in the phase post-integration-test.
>> >
>> > Then use Failsafe plugin in the phases integration-test and verify.
>> >
>>
>> Unfortunately, this is not how arquillian is setup. You can run tests
>> against running servers (which you can then start in
>> pre-integration-test),
>> but using arquillian cube, these containers can be started as part of the
>> test lifecycle. Also, Arquillian is just a single incarnation of the
>> underlying issue. Every extension that takes more than a few seconds to
>> start and is built to only initialize once for a suite will trigger this
>> same problem (as can be seen by the demo project). As surefire and
>> failsafe
>> use the same JUnitPlatformProvider, the problem will also be the same.
>>
>> What do you think about the solution of using a LauncherSession to bind
>> the
>> multiple executions together? This will require JUnit Platform 1.8 and
>> changes in the JUnitPlatformProvider. However, I'm not sure what the
>> intended audience of LauncherSessionListener is.
>>
>> Best regards,
>> Emond
>>
>> On Fri, Sep 10, 2021 at 12:42 PM Emond Papegaaij <
>> emond.papega...@gmail.com>
>> > wrote:
>> >
>> > > Hi all,
>> > >
>> > > First of all, sorry for the lengthy post. I decided to add some
>> context
>> > to
>> > > explain things a bit, but it resulted in quite a long e-mail. For the
>> > past
>> > > few weeks I've been trying to come up with a solution for the issue I
>> > > filled under SUREFIRE-1935, but I'm getting stuck and starting to feel
>> > like
>> > > the issue cannot be solved with the current JUnit Platform API. To
>> give
>> > > some perspective into why this issue is important for us, I first
>> have to
>> > > explain a bit about our setup.
>> > >
>> > > We write our tests in the Spock framework and use Arquillian to run
>> the
>> > > tests in the application container. Some of our tests, especially the
>> > > Selenium based tests, require quite some setup and tear down. Prior to
>> > > starting the test, Arquillian cube builds and starts several docker
>> > > containers and the tests are run against these containers. We
>> currently
>> > use
>> > > the JUnit 4 based Spock 1.3 with Groovy 2.5, but we like to upgrade to
>> > > Spock 2 and Groovy 3, which runs on top of the JUnit Platform. For
>> this,
>> > > I've already started working on a Spock extension that integrates
>> Spock 2
>> > > in the Arquillian test life cycle [1]. This extension is inspired by
>> the
>> > > (curr

Re: JUnit Platform, forkCount > 1 and the TestPlan

[Tibor Digana]

Hi Emond,

Are you looking for this?
https://github.com/junit-team/junit5/blob/main/documentation/src/test/java/example/UsingTheLauncherDemo.java#L86-L96

On Fri, Sep 10, 2021 at 10:49 PM Emond Papegaaij 
wrote:

> On Fri, Sep 10, 2021 at 9:15 PM Emond Papegaaij  >
> wrote:
>
> > On Fri, Sep 10, 2021 at 8:41 PM Christian Stein 
> > wrote:
> >
> >> On Fri, Sep 10, 2021 at 8:27 PM Emond Papegaaij <
> >> emond.papega...@gmail.com>
> >> wrote:
> >>
> >> For now, I think the LauncherSession is the best way to at least provide
> >> > some hooks for pre and post fixtures. It shouldn't be too hard to get
> >> this
> >> > in the current code base with backwards compatibility for JUnit
> Platform
> >> > 1.7 and older. I'll see if I can create a pull request for this
> >> somewhere
> >> > next week.
> >> >
> >>
> >> Before investing too much energy into a PR, please start a discussion or
> >> open a feature request first - chances are that what you seek to achieve
> >> is already possible, or somebody else has filed a similar request.
> >
> >
> > You mean at JUnit? I'm pretty sure that it's currently not possible. I've
> > been stepping through that code for quite some time now, and the whole
> > TestPlan construction is very static. There doesn't seem to be an open
> > request for this at the moment.
> >
> > The API for a LauncherSession is very simple and I think it's a good idea
> > to use it anyway. The hardest part will be to only start the session when
> > using 1.8 or higher.
> >
>
> That was easier than I thought. I've already got a working POC at
>
> https://github.com/topicusonderwijs/maven-surefire/commit/b112130170c244846d5e35353a4c90afaf42aff1
> . The only problems at the moment are that some tests fail because a
> TestPlan is immutable in 1.8, the main process creates a LauncherSession
> that is never closed and I screwed up the formatting in some places. With
> this change, a LauncherSession is created when JUnit Platform 1.8 is used.
> This session is closed when all tests have been executed. When running on
> 1.7 or lower, it falls back to the old behavior. I've verified that only
> one LauncherSession is created per fork when running with forkCount > 1.
>
> Best regards,
> Emond
>

Re: JUnit Platform, forkCount > 1 and the TestPlan

[Tibor Digana]

Hi Emond,

This section of code is executed for the forkCount > 1
https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java#L194-L202
The above part runs if the forkCount is 1.

Do you think that using the session together with the try-with-resource in
the selected section of code makes the trick?
Pls check it your local in your local branch and your project.

T



On Fri, Sep 10, 2021 at 11:33 PM Emond Papegaaij 
wrote:

> Hi Tibor,
>
> That's what I implemented, although I couldn't use the fancy try, because
> of the way the code is structured. The LauncherSession is started by
> LazyLauncher. This will allow registering a listener for opening and
> closing the session, given a place for pre and post fixtures.
>
> Best regards,
> Emond
>
> Op vr 10 sep. 2021 23:00 schreef Tibor Digana :
>
> > Hi Emond,
> >
> > Are you looking for this?
> >
> >
> https://github.com/junit-team/junit5/blob/main/documentation/src/test/java/example/UsingTheLauncherDemo.java#L86-L96
> >
> > On Fri, Sep 10, 2021 at 10:49 PM Emond Papegaaij <
> > emond.papega...@gmail.com>
> > wrote:
> >
> > > On Fri, Sep 10, 2021 at 9:15 PM Emond Papegaaij <
> > emond.papega...@gmail.com
> > > >
> > > wrote:
> > >
> > > > On Fri, Sep 10, 2021 at 8:41 PM Christian Stein 
> > > > wrote:
> > > >
> > > >> On Fri, Sep 10, 2021 at 8:27 PM Emond Papegaaij <
> > > >> emond.papega...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> For now, I think the LauncherSession is the best way to at least
> > provide
> > > >> > some hooks for pre and post fixtures. It shouldn't be too hard to
> > get
> > > >> this
> > > >> > in the current code base with backwards compatibility for JUnit
> > > Platform
> > > >> > 1.7 and older. I'll see if I can create a pull request for this
> > > >> somewhere
> > > >> > next week.
> > > >> >
> > > >>
> > > >> Before investing too much energy into a PR, please start a
> discussion
> > or
> > > >> open a feature request first - chances are that what you seek to
> > achieve
> > > >> is already possible, or somebody else has filed a similar request.
> > > >
> > > >
> > > > You mean at JUnit? I'm pretty sure that it's currently not possible.
> > I've
> > > > been stepping through that code for quite some time now, and the
> whole
> > > > TestPlan construction is very static. There doesn't seem to be an
> open
> > > > request for this at the moment.
> > > >
> > > > The API for a LauncherSession is very simple and I think it's a good
> > idea
> > > > to use it anyway. The hardest part will be to only start the session
> > when
> > > > using 1.8 or higher.
> > > >
> > >
> > > That was easier than I thought. I've already got a working POC at
> > >
> > >
> >
> https://github.com/topicusonderwijs/maven-surefire/commit/b112130170c244846d5e35353a4c90afaf42aff1
> > > . The only problems at the moment are that some tests fail because a
> > > TestPlan is immutable in 1.8, the main process creates a
> LauncherSession
> > > that is never closed and I screwed up the formatting in some places.
> With
> > > this change, a LauncherSession is created when JUnit Platform 1.8 is
> > used.
> > > This session is closed when all tests have been executed. When running
> on
> > > 1.7 or lower, it falls back to the old behavior. I've verified that
> only
> > > one LauncherSession is created per fork when running with forkCount >
> 1.
> > >
> > > Best regards,
> > > Emond
> > >
> >
>

Re: JUnit Platform, forkCount > 1 and the TestPlan

[Tibor Digana]

I do not want to stick to the latest version 1.8.
We have to stick to version 1.3 as it is right now.
We do not have a critical issue which could not be solved by reflection.
This reflection call, I proposed in GH, is made only once, no performance
penalty.

T

On Sat, Sep 11, 2021 at 7:52 AM Marc Philipp  wrote:

> Hi Emond and Tibor,
>
> I’m glad you discovered the new LauncherSession API which was added for
> this purpose. The JUnit 5.8 GA release will come in the next few days.
>
> As you mentrioned, the official documentation does not (yet!) do a good
> job of explaining its intended use case:
>
> https://junit.org/junit5/docs/5.8.0-RC1/user-guide/#launcher-api-launcher-session-listeners-custom
>
> Here’s a more complete example that I wrote for Gradle’s test distribution
> plugin:
>
> https://docs.gradle.com/enterprise/test-distribution-gradle-plugin/#junit_5_8_and_later
>
> It demonstrates how to initialize a “fixture” only once for an entire
> session and only if tests are actually going to be executed not just
> discovered. I’ll make sure to update the official JUnit docs to include a
> similar example before the release.
>
> To only differentiate between the different versions of JUnit in one place
> and stay backwards compatible, you could create an adapter class like this:
>
> public class BackwardsCompatibleLauncherSession implements AutoCloseable {
>
> public static BackwardsCompatibleLauncherSession open() {
> try {
> LauncherSession launcherSession =
> LauncherFactory.openSession();
> return new
> BackwardsCompatibleLauncherSession(launcherSession.getLauncher(),
> launcherSession::close);
> } catch (NoSuchMethodError ignore) {
> // JUnit Platform version on test classpath does not yet
> support launcher sessions
> return new
> BackwardsCompatibleLauncherSession(LauncherFactory.create(), () -> {});
> }
> }
>
> private final Launcher launcher;
> private final Runnable onClose;
>
> private BackwardsCompatibleLauncherSession(Launcher launcher, Runnable
> onClose) {
> this.launcher = launcher;
> this.onClose = onClose;
> }
>
> Launcher getLauncher() {
> return launcher;
> }
>
> @Override
> public void close() {
> onClose.run();
> }
> }
>
> Cheers,
>
> Marc
>

Re: JUnit Platform, forkCount > 1 and the TestPlan

[Tibor Digana]

LauncherSessionListener can be obviously used as a hack by the end users
but I do not see the reason why we should use it.
We do not want to explicitly call fixture methods because this would lead
to maintenance if Junit5 introduces new fixture mechanisms.

On Sat, Sep 11, 2021 at 12:25 PM Tibor Digana 
wrote:

> I do not want to stick to the latest version 1.8.
> We have to stick to version 1.3 as it is right now.
> We do not have a critical issue which could not be solved by reflection.
> This reflection call, I proposed in GH, is made only once, no performance
> penalty.
>
> T
>
> On Sat, Sep 11, 2021 at 7:52 AM Marc Philipp  wrote:
>
>> Hi Emond and Tibor,
>>
>> I’m glad you discovered the new LauncherSession API which was added for
>> this purpose. The JUnit 5.8 GA release will come in the next few days.
>>
>> As you mentrioned, the official documentation does not (yet!) do a good
>> job of explaining its intended use case:
>>
>> https://junit.org/junit5/docs/5.8.0-RC1/user-guide/#launcher-api-launcher-session-listeners-custom
>>
>> Here’s a more complete example that I wrote for Gradle’s test
>> distribution plugin:
>>
>> https://docs.gradle.com/enterprise/test-distribution-gradle-plugin/#junit_5_8_and_later
>>
>> It demonstrates how to initialize a “fixture” only once for an entire
>> session and only if tests are actually going to be executed not just
>> discovered. I’ll make sure to update the official JUnit docs to include a
>> similar example before the release.
>>
>> To only differentiate between the different versions of JUnit in one
>> place and stay backwards compatible, you could create an adapter class like
>> this:
>>
>> public class BackwardsCompatibleLauncherSession implements AutoCloseable {
>>
>> public static BackwardsCompatibleLauncherSession open() {
>> try {
>> LauncherSession launcherSession =
>> LauncherFactory.openSession();
>> return new
>> BackwardsCompatibleLauncherSession(launcherSession.getLauncher(),
>> launcherSession::close);
>> } catch (NoSuchMethodError ignore) {
>> // JUnit Platform version on test classpath does not yet
>> support launcher sessions
>> return new
>> BackwardsCompatibleLauncherSession(LauncherFactory.create(), () -> {});
>> }
>> }
>>
>> private final Launcher launcher;
>> private final Runnable onClose;
>>
>> private BackwardsCompatibleLauncherSession(Launcher launcher,
>> Runnable onClose) {
>> this.launcher = launcher;
>> this.onClose = onClose;
>> }
>>
>> Launcher getLauncher() {
>> return launcher;
>> }
>>
>> @Override
>> public void close() {
>> onClose.run();
>> }
>> }
>>
>> Cheers,
>>
>> Marc
>>
>

Re: system path dependency warning, accurate or not?

[Tibor Digana]

Scope=system is not like the Maven has proposed its biggest strength with
Maven dependencies and GAV. This scope should be deprecated or even removed.

Dňa pi 24. 9. 2021, 16:43 Romain Manni-Bucau 
napísal(a):

> Hi all,
>
> wonder if there is any reason to see this warning when using a jar in the
> project in system scope:
>
>
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for io.yupiik.foo:foo:jar:0.0.1-SNAPSHOT
> [WARNING] 'dependencies.dependency.systemPath' for foo:bar:jar should not
> point at files within the project directory,
> ${project.basedir}/m2/lib/bar.jar will be unresolvable by dependent
> projects @ line 71, column 19
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
>
> since the absolute path starts with a "in project" path the build will be
> stable, the jar will be resolvable etc so there is no reason for the
> warnings nor maven to not support it in a future version.
>
> Is it just due to fixing the "tools.jar" dependency (where the warning is
> relevant) or is there another rational behind that and the warning is not a
> bug?
> If so i'm concerned there is no real alternative until you get a m2 https
> server which is not always an option so the last sentence requires us to
> work toward a solution (that said it will likely be the same so I'd prefer
> to drop the warning if the dpeendency is in the project).
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>

Re: Another take on [MRESOLVER-7] Download dependency POMs in parallel

[Tibor Digana]

Hi Ivan,

Basically the process is simple.
You should fork the master to your branch named, e.g. MRESOLVER-7.

I think the process is not a big issue right now.
The big issue here is the analysis of the code and a proposed fix.

It would be fine to split the changes into several independent commits or
(branches if possible and necessary) upon the my hints in Jira:
1. root cause of hanging Maven and deadlock of thread-resources starvation,
2. problems with thread-unsafe classes,
3. overrided objects across threads,
4. one unclear part in the algorithm

The ideal would be to isolate these four however it is a theory and still
keep the build success.

You should step into 1 at first, start the code analysis, understand the
problem with resource starvation and propose a fix or alternatives in a
comment. Then we would make a decision together.
Then the code will be changed and the community should check it out by
integrating into Maven and ITs. We would be happy if we could not have any
regression in each step.

If we could isolate the work in 4 or more fixes and Jira tickets, we would
have an easier life to bisect the commits and verify them separately while
we are in troubles in the future.

T









On Sat, Oct 16, 2021 at 5:21 PM Ivan Babiankou 
wrote:

> I would love to prepare decent PR
> 
> for the MRESOLVER-7 issue, so that it makes it to one of the upcoming
> releases. But I could definitely use some guidance, given the history of
> the ticket
> 
> and the fact that it’s my first contribution to Maven and OSS in general.
> Is there anyone willing to point me in the right direction (in email or a
> quick 15-30min call)?  I would really appreciate it.
>
> For now I’m reading the general things about contributing to Maven and
> looking at the old branch that was merged and then reverted.
>
>
> I see the master branch of Maven Resolver corresponds to v1.7.x, which
> requires Maven 4, however I would love to target the current Maven 3.x.
> Where should I start my PR off master or  maven-resolver-1.6.x?
>
> Thanks,
> Ivan
>
>
>

Re: Surefire - multiple tests framework on classpath

[Tibor Digana]

Hi Slawomir,

The reality is different.
It's not the frameworks but providers.
So the plugin iterates over providers.
You may choose whether you will define the provider artifacts in plugin
deps or you let the plugin to select the providers upon dependencies which
means that there is some logic and JUnit5 deps may activate one provider
for both the junit4 and 5.

T

On Tue, Nov 2, 2021 at 7:46 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> When multiple test frameworks are present on project classpath surefire
> chooses one framework for running the tests.
>
> In such situations, some tests are silently skipped.
>
>
> I've created issue [1] for it with a simple proposition.
>
> After discussion on slack another proposition was in place to detect the
> test framework with other dependencies and choose a proper provider.
>
> Or use multiple providers instead of only one.
>
>
> It will be good to choose how to solve this problem.
>
>
> [1] https://issues.apache.org/jira/browse/SUREFIRE-1954
>
> --
> Sławomir Jaranowski
>
> https://twitter.com/SlawekJaran
> https://github.com/slawekjaranowski
> https://linkedin.com/in/slawomirjaranowski
>

Re: Surefire - multiple tests framework on classpath

[Tibor Digana]

Hi Slawomir,

Pls follow this page
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html

There is a chapter "How to run multiple APIs or Engines". There are also
some links pointing to our integration test in the Apache project.
Pls have a look.

Cheers
Tibor



On Wed, Nov 3, 2021 at 6:22 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> I understand the difference  between framework and providers.
> I also know that we can add specific providers as dependency to the plugin
> and in the result we have manually selected providers.
>
> When we don't configure any dependency the provider is chosen automatically
> depending on what we have on classpath, what framework.
>
> eg. When we have on classpath junit4 and junit5, but without junit5 vintage
> - junit4 tests are silently skipped.
>
> In most cases in the project we use one testing framework so
> automatically choosing one provider is ok.
>
> When we use more that one framework it is probably during migration, so we
> should define proper dependency.
> It is ok when we have control on what we do in a project, but there are
> some situations when we can make mistakes, like
> - user add second testing framework and forgot about configuration
> - we change project dependency and in transitive dependency we got next
> testing framework
>
> So I want to mitigate the risk of skipped tests by warning / failing that
> we have many frameworks and automatically provider selection takes place.
>
> We can also try to choose many providers (not one) automatically, but I
> think it will be more complicated and in standard usage is not needed.
> For automatic detection we have many corner cases, like testng + junit4  -
> testng by default runs junit4 tests, so without special configuration for
> testng we run some of the tests twice.
>
>
> śr., 3 lis 2021 o 15:09 Tibor Digana  napisał(a):
>
> > Hi Slawomir,
> >
> > The reality is different.
> > It's not the frameworks but providers.
> > So the plugin iterates over providers.
> > You may choose whether you will define the provider artifacts in plugin
> > deps or you let the plugin to select the providers upon dependencies
> which
> > means that there is some logic and JUnit5 deps may activate one provider
> > for both the junit4 and 5.
> >
> > T
> >
> > On Tue, Nov 2, 2021 at 7:46 PM Slawomir Jaranowski <
> s.jaranow...@gmail.com
> > >
> > wrote:
> >
> > > Hi,
> > >
> > > When multiple test frameworks are present on project classpath surefire
> > > chooses one framework for running the tests.
> > >
> > > In such situations, some tests are silently skipped.
> > >
> > >
> > > I've created issue [1] for it with a simple proposition.
> > >
> > > After discussion on slack another proposition was in place to detect
> the
> > > test framework with other dependencies and choose a proper provider.
> > >
> > > Or use multiple providers instead of only one.
> > >
> > >
> > > It will be good to choose how to solve this problem.
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1954
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> > > https://twitter.com/SlawekJaran
> > > https://github.com/slawekjaranowski
> > > https://linkedin.com/in/slawomirjaranowski
> > >
> >
>
>
> --
> Sławomir Jaranowski
>

Re: Surefire - multiple tests framework on classpath

[Tibor Digana]

Usually you will endup with one engine and one or more test APIs.
The documentation above solves all combinations with junit4, junit5 and
testng.
If somebody uses one @Test annotation and wants to say that f/w1 should run
test class 1 but f/w2 should run test class 2, then the plugin should be
configured with two executions within one phase default-test.
I don't think we should rewrap entire plugin config params per provider
since it can be solved with Maven's  in POM.
T

On Wed, Nov 3, 2021 at 6:22 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> I understand the difference  between framework and providers.
> I also know that we can add specific providers as dependency to the plugin
> and in the result we have manually selected providers.
>
> When we don't configure any dependency the provider is chosen automatically
> depending on what we have on classpath, what framework.
>
> eg. When we have on classpath junit4 and junit5, but without junit5 vintage
> - junit4 tests are silently skipped.
>
> In most cases in the project we use one testing framework so
> automatically choosing one provider is ok.
>
> When we use more that one framework it is probably during migration, so we
> should define proper dependency.
> It is ok when we have control on what we do in a project, but there are
> some situations when we can make mistakes, like
> - user add second testing framework and forgot about configuration
> - we change project dependency and in transitive dependency we got next
> testing framework
>
> So I want to mitigate the risk of skipped tests by warning / failing that
> we have many frameworks and automatically provider selection takes place.
>
> We can also try to choose many providers (not one) automatically, but I
> think it will be more complicated and in standard usage is not needed.
> For automatic detection we have many corner cases, like testng + junit4  -
> testng by default runs junit4 tests, so without special configuration for
> testng we run some of the tests twice.
>
>
> śr., 3 lis 2021 o 15:09 Tibor Digana  napisał(a):
>
> > Hi Slawomir,
> >
> > The reality is different.
> > It's not the frameworks but providers.
> > So the plugin iterates over providers.
> > You may choose whether you will define the provider artifacts in plugin
> > deps or you let the plugin to select the providers upon dependencies
> which
> > means that there is some logic and JUnit5 deps may activate one provider
> > for both the junit4 and 5.
> >
> > T
> >
> > On Tue, Nov 2, 2021 at 7:46 PM Slawomir Jaranowski <
> s.jaranow...@gmail.com
> > >
> > wrote:
> >
> > > Hi,
> > >
> > > When multiple test frameworks are present on project classpath surefire
> > > chooses one framework for running the tests.
> > >
> > > In such situations, some tests are silently skipped.
> > >
> > >
> > > I've created issue [1] for it with a simple proposition.
> > >
> > > After discussion on slack another proposition was in place to detect
> the
> > > test framework with other dependencies and choose a proper provider.
> > >
> > > Or use multiple providers instead of only one.
> > >
> > >
> > > It will be good to choose how to solve this problem.
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1954
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> > > https://twitter.com/SlawekJaran
> > > https://github.com/slawekjaranowski
> > > https://linkedin.com/in/slawomirjaranowski
> > >
> >
>
>
> --
> Sławomir Jaranowski
>

Re: [VOTE] Release Apache Maven version 3.8.4

[Tibor Digana]

+1
Cheers
Tibor17

On Sun, Nov 14, 2021 at 2:28 PM Michael Osipov  wrote:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12350685
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1669/
>
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.4/
>
> Source release checksums:
> apache-maven-3.8.4-src.zip sha512:
>
> 2f57dd7476ee1831867930dbe33ebe669b8fc0a9863586093a4eb2188745c5ddc2710beea1bf076263923ce38a487ef92d570bc752c77d0e0f1e3416b65bc785
> apache-maven-3.8.4-src.tar.gz sha512:
>
> ea4b5f2b29be45d22e716099d0ef87367c78766aade094e8d7f295fe3b2c98cba2bf0f214d3ed55e2c17d2f74c82352cf9dc83fa47ddc97a8d2b847315500431
>
> Binary release checksums:
> apache-maven-3.8.4-bin.zip sha512:
>
> bcd1e99548ac8a5b9ec159ee16c23d29d6799696c92140d583d25eb323433aadcc0b47c45b0b6bd9dbcf344bbba38b56dd056a9c49ae714cfc22dc06bb4a4230
> apache-maven-3.8.4-bin.tar.gz sha512:
>
> a9b2d825eacf2e771ed5d6b0e01398589ac1bfa4171f36154d1b5787879605507802f699da6f7cfc80732a5282fd31b28e4cd6052338cbef0fa1358b48a5e3c8
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/274
>
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open until 2021-11-19T18:00Z
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.2.0

[Tibor Digana]

+1

On Thu, Jan 27, 2022 at 1:21 PM Michael Osipov  wrote:

> Hi,
>
> We solved 7 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&version=12351277
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1700/
>
> https://repository.apache.org/content/repositories/maven-1700/org/apache/maven/plugins/maven-project-info-reports-plugin/3.2.0/maven-project-info-reports-plugin-3.2.0-source-release.zip
>
> Source release checksum(s):
> maven-project-info-reports-plugin-3.2.0-source-release.zip
> sha512:
>
> 241e3f9c22b65abbfba1e20718eb5de39dbf7217a31de4c9e1cbba7b7c51f66ffefdde0fcc90a0ea8afab69306b4e6a4abfd1b9caac2722a6a6bb898243697c9
>
> Staging site:
>
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Commit Review Policy

[Tibor Digana]

It's nice to write some rules but still the developers are not machines.
You can, for instance, get some vote for totally crazy things like removing
public method in a library which is widely used in ASF or in the world.
Yes, your right against the rules but was this according to the best
practices, those best practices which must be learned by the developers for
years?
Was the public method @Deprecated before removal?
Did you check the consumers of this artifact in the Maven repository and
checked or asked the projects if it can be removed?
Did you announce the community on the site?
What if there are other deprecated methods and they have survived several
releases but still not removed, and this method is going to be removed
without deprecation? Is it consistent in project which is used by others?
These are all the things which cannot be written in the rules but we have
it somewhere in our mind.
Do you obey your internal rules?
Which have higher priority?

I don't need to have an answer for my questions, since they are not
questions...

T

On Tue, Jan 25, 2022 at 8:46 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> On the page "Apache Maven Project Roles" [1] we have paragraph
> about Committers with:
>
> The Apache Maven project uses a Commit then Review policy and has a number
> of conventions which should be followed.
>
>
> Looks like Review then Commit policy is from svn time, so should be
> refreshed or confirmed that is actual.
>
> When we want Review than Commit policy, we need some rules which allow us
> to effectively work if nobody is interested for feedback.
> We also need rules / examples for direct commits, when they are acceptable.
>
> Do we need different rules for Maven core, plugins, shared ... etc
>
> Example of rule:
>
> PR -> no feedback for X days -> send a mail on dev@, if still not feedback
> after X days after mail  -> proceed alone
>
> [1] https://maven.apache.org/project-roles.html#committers
>
> --
> Sławomir Jaranowski
>

Re: Commit Review Policy

[Tibor Digana]

IMHO the reactions against PRs should be technically critical.
IMHO the PRs from contributors should not be accepted unless there are
objections or pending objections.
Example, would you move your hand up and accept long commit in a PR even if
you do not see the following statements?
*if ( cha[] == char[] )*
Sometimes, you need to open the PR in your IDE because GH view is pure for
complex changes. You should do everything in order to understand the PR and
you must be convinced about the proposals almost like you were the author
of the PR even if you are not the author.


On Thu, Feb 3, 2022 at 12:23 PM Xeno Amess  wrote:

> 3 days?
> according to my experience, usually you need 30 - 180 days.
>
> Tibor Digana  于2022年1月28日周五 06:40写道：
>
> > It's nice to write some rules but still the developers are not machines.
> > You can, for instance, get some vote for totally crazy things like
> removing
> > public method in a library which is widely used in ASF or in the world.
> > Yes, your right against the rules but was this according to the best
> > practices, those best practices which must be learned by the developers
> for
> > years?
> > Was the public method @Deprecated before removal?
> > Did you check the consumers of this artifact in the Maven repository and
> > checked or asked the projects if it can be removed?
> > Did you announce the community on the site?
> > What if there are other deprecated methods and they have survived several
> > releases but still not removed, and this method is going to be removed
> > without deprecation? Is it consistent in project which is used by others?
> > These are all the things which cannot be written in the rules but we have
> > it somewhere in our mind.
> > Do you obey your internal rules?
> > Which have higher priority?
> >
> > I don't need to have an answer for my questions, since they are not
> > questions...
> >
> > T
> >
> > On Tue, Jan 25, 2022 at 8:46 PM Slawomir Jaranowski <
> > s.jaranow...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > On the page "Apache Maven Project Roles" [1] we have paragraph
> > > about Committers with:
> > >
> > > The Apache Maven project uses a Commit then Review policy and has a
> > number
> > > of conventions which should be followed.
> > >
> > >
> > > Looks like Review then Commit policy is from svn time, so should be
> > > refreshed or confirmed that is actual.
> > >
> > > When we want Review than Commit policy, we need some rules which allow
> us
> > > to effectively work if nobody is interested for feedback.
> > > We also need rules / examples for direct commits, when they are
> > acceptable.
> > >
> > > Do we need different rules for Maven core, plugins, shared ... etc
> > >
> > > Example of rule:
> > >
> > > PR -> no feedback for X days -> send a mail on dev@, if still not
> > feedback
> > > after X days after mail  -> proceed alone
> > >
> > > [1] https://maven.apache.org/project-roles.html#committers
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>