Re: [RESULT] [VOTE] Release Maven Surefire version 3.0.0-M8

[Tibor Digana]

Regarding the history, one of our contributor created a project, release
Jar atrifact which contains native libraries.
This artifact is not part of Surefire/Failsafe plugin.
It is used only in our ITs.
Naturally ARM is not supported because that time ARM was not much popular,
maybe only on the embedded systems.
S, if you want to have the support, try to find the guy according to the
history in GitHub. Otherwise, feel free to skip the tests for this CPU.

T

On Thu, Jan 12, 2023 at 12:06 PM Enrico Olivelli 
wrote:

> For reference:
>
> This is the issue
> https://issues.apache.org/jira/browse/SUREFIRE-2141
>
> The problem is about the compatibility of a third party library used
> in the tests, that doesn't work on ARM platforms
>
> There is no quick fix
>
> Enrico
>
> Il giorno gio 12 gen 2023 alle ore 02:24 Nick Stolwijk
>  ha scritto:
> >
> > Hi Michael,
> >
> > Thanks for the release! A little side note for next time, the link in the
> > announcement mail is not working. It should be
> > https://maven.apache.org/surefire/ instead of
> > https://maven.apache.org/maven-surefire/.
> >
> > With regards,
> >
> > Nick Stolwijk
> >
> > ~~~ Try to leave this world a little better than you found it and, when
> > your turn comes to die, you can die happy in feeling that at any rate you
> > have not wasted your time but have done your best ~~~
> >
> > Lord Baden-Powell
> >
> >
> > On Wed, 11 Jan 2023 at 22:24, Michael Osipov 
> wrote:
> >
> > > Hi,
> > >
> > > The vote has passed with the following result:
> > >
> > > +1: Herve Boutemy, Slawomir Jaranowski, Romain Manni-Bucau, Karl Heinz
> > > Marbaise, Petr Široký
> > >
> > > PMC quorum: reached
> > >
> > > I will promote the artifacts to the central repo, the source release
> ZIP
> > > file
> > > and add this release the board report.
> > >
>
> -
> 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 Impl version 4.0.0-M2

[Tibor Digana]

+1, all fine
T

On Wed, Jul 6, 2022 at 10:08 PM Michael Osipov  wrote:

> Hi,
>
> We solved 7 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12352045
>
> There are no 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-reporting-impl
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1776/
>
> https://repository.apache.org/content/repositories/maven-1776/org/apache/maven/reporting/maven-reporting-impl/4.0.0-M2/maven-reporting-impl-4.0.0-M2-source-release.zip
>
> Source release checksum(s):
> maven-reporting-impl-4.0.0-M2-source-release.zip
> sha512:
>
> e0b2028d5f41d7a12728d8ba7ad76a486b47b2e7494d1cf39987116f956be72da96d8c1f24f654de2a0f919ae02aa3d1b08dd984ea6a53e4391b1afbb6f93136
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-reporting-impl-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: [RESULT] [VOTE] Apache Maven Surefire 3.0.0-M7

[Tibor Digana]

David,
Sending from my mobile, so will be short. I wrote the roadmap with purpose
you was talking about. We can discuss it in a voice conf which would be
much faster and you can help us too but it would not be done by the way to
fire a random PRs. I neededed a break because of my job and illness but
this happens.
Regarding the release of 2.22.3, this is ready to go. Maybe somebody wants
to backport some latest fixes...

T


Dňa pi 10. 6. 2022, 19:52 David Karr 
napísal(a):

> Well, we had found that we couldn't get all the required variations of
> JUnit 5 working in Maven without the M release, so we had to upgrade.  We
> have tested our scenarios with M7, including test suites and mixed Junit4
> and JUnit5 tests, and we're not seeing any problems (including one scenario
> that produced the BufferOverflow exception with M6).
>
> The thing is, if you're not confident enough with it to produce a non-M
> release, that makes us a little nervous also.  The scenarios we've tested
> are a tiny fraction of the services that will be using this. I don't expect
> to see any unexpected problems, but that's normal.
>
> However, I can certainly understand you concluding you don't have enough
> data to really be confident it's fully ready.  The one thing we've
> determined in our testing is that if a particular service finds some
> unexpected problem at any level of the JUnit 5 upgrade (starting with
> simply upgrading the surefire version to 3.0.0-M7), they can simply stay
> with JUnit 4 and Surefire 2.x, and they can move forward with that, while
> we file that as a scenario that we need to troubleshoot.  We can live with
> that.
>
> On Wed, Jun 8, 2022 at 6:20 PM Olivier Lamy  wrote:
>
> > On Wed, 8 Jun 2022 at 04:29, David Karr 
> > wrote:
> >
> > > Now that M7 is released, I have a feeling I know the answer to this,
> but
> > > what are your thoughts about when a full release will go out with these
> > > latest changes? I'm currently evaluating whether we can upgrade our
> > > internal platform to support Junit 5.  As far as we know, M7 will
> address
> > > the last problem we were seeing (buffer overflow), and we'll be testing
> > > that this morning, but my "platform" team only has a small set of
> > services
> > > we can easily test platform upgrades with.  Our platform is used by a
> > large
> > > number of services.  Using a "beta" version carries some amount of
> > > indeterminate risk (sort of redundant), so I have to be more careful
> > about
> > > planning for contingencies if we discover unexpected problems from the
> M7
> > > version in other services we don't directly support.  Those
> contingencies
> > > include staying on Surefire 2.22.0, but still using Spring Boot 2.3.12
> > > (upgrading this will be coming soon), and only using JUnit 4.
> > >
> >
> >
> > Well I think using Mx is because we are a bit conservative :)
> > version naming is a bit of a chicken and egg problem!
> > We'd like to have more feedback/tests (even issues :)) etc.. from the
> real
> > world but as it's called M* people do not upgrade.
> > I do not see real issues with junit5.
> > BUT I think there are still some problems with JPMS and the default (and
> > non configurable) options used.
> > Let me explain that. First you need to know surefire (and few other
> plugins
> > such compiler, javadoc) rely on a library called plexus-java which from a
> > list of jars will parse all the module-info files to build a sort of
> graph
> > and so build the module-path and the classpath.
> > 3.0.0-M5 has been released in June 2020 with plexus-java 1.0.5 from
> > February 2020.
> > 3.0.0-M6 has been released at the end of March 2022 with plexus-java
> 1.1.1
> > from January 2022.
> > It's always 2 years between those releases and by the way plenty of
> changes
> > in the plexus-java library (because of some issues with compiler, javadoc
> > etc..)
> > (With my committer of Jetty project hat) we use JPMS now and moving from
> > 3.0.0-M5 to M6 is impossible because of
> > https://issues.apache.org/jira/browse/SUREFIRE-2057 which is breaking
> > change in plexus-java
> > and now upgrading to M7 is impossible either because of another issue
> > (which I need to create a jira for it). (but there is a gist explaining
> the
> > problem here
> > https://gist.github.com/olamy/d651e21fd89b73612a42e3617a1d0261
> > )
> > Ideally I'd like to have more configurable options for jpms (e.g module
> > graph resolution) because actually it's based on some assumptions which
> can
> > be wrong for some use cases.
> > I'm currently collecting use cases etc... Then I will create a Jira to
> ask
> > for comments (such as what do you want guys to be configurable for jpms:
> > test scope should be in module-path or classpath, same for provided, do
> we
> > need to add automatically providers to the module-path even if it's a
> test
> > dependency).
> > I think this needs to be fixed before removing the M* :) because jpms get
> > more and more adoptions now.
> >
> >
> 

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

[Tibor Digana]

+1

Dňa ut 31. 5. 2022, 19:57 Andreas Dangel  napísal(a):

> Hi,
>
> We solved 15 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351350=Text=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-1756/
>
> https://repository.apache.org/content/repositories/maven-1756/org/apache/maven/plugins/maven-pmd-plugin/3.17.0/maven-pmd-plugin-3.17.0-source-release.zip
>
> Source release checksum(s):
> maven-pmd-plugin-3.17.0-source-release.zip sha512:
>
> b95a6f1b54332747c09af93ddbda6ef3d49745bb5a2a31fadf43221549919c7eb7a20541234eb9f8f02b1dfd75b9b94305322097194d98cb7e837328493673a3
>
> 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: [VOTE] Release Maven Javadoc Plugin version 3.4.0

[Tibor Digana]

It works on JDK1.8 but it does not work on JDK18.
Do you have experiences with such issues?
T

On Mon, Apr 18, 2022 at 9:21 PM Michael Osipov  wrote:

> Am 2022-04-18 um 21:19 schrieb Tibor Digana:
> > Did everybody run a local build?
> > I did and the IT failed MJAVADOC-538 with Maven 3.8.5 and JDK18.
> > It should be reproducible because the logs say:
> >
> > MyClass.java:24: warning: use of default constructor, which does not
> > provide a comment
> > [WARNING] public class MyClass
> > [WARNING] ^
> > ...
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-javadoc-plugin:3.4.0:javadoc (default-cli)
> > on project mjavadoc-538: An error has occurred in Javadoc report
> > generation: Project contains Javadoc Warnings -> [Help 1]
> > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> > goal org.apache.maven.plugins:maven-javadoc-plugin:3.4.0:javadoc
> > (default-cli) on project mjavadoc-538: An error has occurred in Javadoc
> > report generation: Project contains Javadoc Warnings
>
> WTF?! Seems like a new weirdo with Javadoc 18?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Site Plugin version 3.12.0

[Tibor Digana]

+1
sha .. ok
build .. ok

T

On Sat, Apr 16, 2022 at 11:20 PM Michael Osipov  wrote:

> Hi,
>
> We solved 11 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923=12351337
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1738/
>
> https://repository.apache.org/content/repositories/maven-1738/org/apache/maven/plugins/maven-site-plugin/3.12.0/maven-site-plugin-3.12.0-source-release.zip
>
> Source release checksum(s):
> maven-site-plugin-3.12.0-source-release.zip
> sha512:
>
> 88898a0890fba18a80f07080955239504df6b899df926936ba16b462236e0bdf5dc875e674621e61685cf7afa6960926d712350dec24e924a7851feb8d9a0d48
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-site-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 Maven Javadoc Plugin version 3.4.0

[Tibor Digana]

Did everybody run a local build?
I did and the IT failed MJAVADOC-538 with Maven 3.8.5 and JDK18.
It should be reproducible because the logs say:

MyClass.java:24: warning: use of default constructor, which does not
provide a comment
[WARNING] public class MyClass
[WARNING] ^
...
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.4.0:javadoc (default-cli)
on project mjavadoc-538: An error has occurred in Javadoc report
generation: Project contains Javadoc Warnings -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-javadoc-plugin:3.4.0:javadoc
(default-cli) on project mjavadoc-538: An error has occurred in Javadoc
report generation: Project contains Javadoc Warnings

T

On Sun, Apr 17, 2022 at 10:02 AM Michael Osipov  wrote:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12330874
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MJAVADOC/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1739/
>
> https://repository.apache.org/content/repositories/maven-1739/org/apache/maven/plugins/maven-javadoc-plugin/3.4.0/maven-javadoc-plugin-3.4.0-source-release.zip
>
> Source release checksum(s):
> maven-javadoc-plugin-3.4.0-source-release.zip
> sha512:
>
> 57850b2ec36f414dceb336fd0de47ffc3216cecfaf19771f3589242c978e8ea6af9bb077d1d22c0f0e8942c58fc9016de606543883e37b37b5eeb05dd61689ad
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-javadoc-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 Reporting API version 4.0.0-M1

[Tibor Digana]

+1
sha .. ok
build with jdk18 .. ok
T

On Sun, Apr 17, 2022 at 6:23 PM Michael Osipov  wrote:

> Hi,
>
> We solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12351595
>
> 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-reporting-api
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1740/
>
> https://repository.apache.org/content/repositories/maven-1740/org/apache/maven/reporting/maven-reporting-api/4.0.0-M1/maven-reporting-api-4.0.0-M1-source-release.zip
>
> Source release checksum(s):
> maven-reporting-api-4.0.0-M1-source-release.zip
> sha512:
>
> 8c708914cc3cd0f50b464289d84ee9202cb9197028c3534373f4ba29367a997d0ae4fb10c9aa871e65f2b8c0bd27e366af91f5016b15fb48d4a46b9eab4a97e9
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-reporting-api-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 Maven Resolver version 1.8.0

[Tibor Digana]

+1
sha .. ok
build with jdk18 .. ok


On Thu, Apr 14, 2022 at 10:37 PM Michael Osipov  wrote:

> Hi,
>
> We solved 15 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12351121
>
> 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-1737/
>
> https://repository.apache.org/content/repositories/maven-1737/org/apache/maven/resolver/maven-resolver/1.8.0/maven-resolver-1.8.0-source-release.zip
>
> Source release checksum(s):
> maven-resolver-1.8.0-source-release.zip
>
> 7800b44016cd63a91ac1e9422f64914f3338a4533b756ac301f89f5e5133b884f8344aa82154b999b49fd950031663d6c08c4f2929fdd85969d8d05601bcdad1
>
> 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
>
>

[ANN] Apache Maven Surefire Plugin 3.0.0-M6 Released

[Tibor Digana]

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

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

https://maven.apache.org/surefire/index.html

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


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


or for failsafe:


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


or for surefire-report:


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



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-M6

Bug

   - [SUREFIRE-1398 ]
   - TestNG test fails when both JUnitCore provider and TestNG provider are on
   classpath
   - [SUREFIRE-1426 ]
   - Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
   - [SUREFIRE-1432 ]
   - trimStackTrace = false by default
   - [SUREFIRE-1556 ]
   - Test XML file is not valid when rerun "fails" with an assumption
   - [SUREFIRE-1659 ]
   - Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
   - [SUREFIRE-1800 ]
   - SurefireForkChannel binds to wrong IP
   - [SUREFIRE-1806 ]
   - Site: Link to "TCP/IP Communication between Forks" is broken
   - [SUREFIRE-1809 ]
   - Differences between Oracle JDK and AdoptOpenJDK caused by JPMS
   - [SUREFIRE-1815 ]
   - Thread interrupted state cleared on any console output
   - [SUREFIRE-1820 ]
   - Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
   - [SUREFIRE-1840 ]
   - Why sudo docker?
   - [SUREFIRE-1842 ]
   - Surefire - NPE at end of successful test run
   - [SUREFIRE-1844 ]
   - Trademarks / privacy policy footer displays broken
   - [SUREFIRE-1851 ]
   - NPE in SmartStackTraceParser causes false positive test results
   - [SUREFIRE-1857 ]
   - JUnit 5 report does not contain assertion failure message
   - [SUREFIRE-1865 ]
   - ChecksumCalculator getSha1 does not compute checksums correctly
   - [SUREFIRE-1869 ]
   - Classloader.getResource() doesn't encode blanks with forkCount=0
   - [SUREFIRE-1881 ]
   - Java agent printing to native console makes build block when using
   SurefireForkNodeFactory
   - [SUREFIRE-1882 ]
   - Fix failures when compiled on Java 9+ and run on Java 8
   - [SUREFIRE-1890 ]
   - Not compatible with TestNG 7.4.0
   - [SUREFIRE-1894 ]
   - Surefire report XML schema is incomplete (attribute version not allowed
   in testsuite)
   - [SUREFIRE-1909 ]
   - Support JUnit 5 reflection access by changing add-exports to add-opens
   - [SUREFIRE-1910 ]
   - Misleading error message when using -Dtest=
   - [SUREFIRE-1912 ]
   - user.dir should not be set lazily within the surefire fork JVM
   - [SUREFIRE-1913 ]
   - system properties should be restored after the in-process tests have been
   executed
   - [SUREFIRE-1914 ]
   - XML report omits method signature / display name of Junit 5 parameterized
   tests if testset reporter is configured to use phrased naming
   - [SUREFIRE-1926 ]
   - Console logs should be synchronized
   - [SUREFIRE-1935 ]
   - Upgrade to JUnit Platform 1.8, start Launcher via LauncherSession
   - [SUREFIRE-1945 ]
   - crashed tests - unit tests with large logging output does not produce
   surefire report
   - 

Re: Review of used reports for Maven project sites.

[Tibor Digana]

It is a nice report in Jenkins but still this cannot be compared with Sonar.
Anyway, guys, feel free to continue in this discussion.
T

On Mon, Apr 4, 2022 at 2:26 AM Olivier Lamy  wrote:

> On Mon, 4 Apr 2022 at 08:51, Tibor Digana  wrote:
>
> > Regarding the next 4 reports out of 5:
> >
> > Test report
> > Checkstyle report
> > PMD report and
> > Taglist report
> >
> > we should use the Sonar Cube as a substitution and the development +
> > release process should take the Sonar into account on the fly.
> >
>
> no need for yet another external tool as we already use Jenkins.
> Jenkins already offers test report, jacoco
>
> https://ci-maven.apache.org/job/Maven/job/ci-reporting-test/job/maven-compiler-plugin/job/ci-reporting/
>
> And now even some static analysis data collection of data produced by Maven
> plugins as prototyped here
>
> https://ci-maven.apache.org/job/Maven/job/ci-reporting-test/job/maven-compiler-plugin/job/ci-reporting/2/linux-jdk11/
>
>
> > Then I would understand the purpose of removal.
> > But now I don't!
> >
> > T
> >
> >
> >
> >
> > On Sun, Apr 3, 2022 at 10:46 PM Slawomir Jaranowski <
> > s.jaranow...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > We have plans for the next release for parents poms.
> > >
> > > Maybe I will be boring, but I still do not see any values for some of
> the
> > > reports for static documentation sites of components.
> > >
> > > Result of tests during release time has no value after some time.
> > Important
> > > is the current result of tests on CI systems.
> > >
> > > Maybe someone will show me the value of it ... so I will stop asking.
> > >
> > > So proposition to remove:
> > >
> > > - surefire [1]
> > > - checkstyle [2]
> > > - pmd [3]
> > > - taglist [4]
> > > - invoker [5]
> > >
> > > [1] https://github.com/apache/maven-parent/pull/49
> > > [2] https://github.com/apache/maven-parent/pull/51
> > > [3] https://github.com/apache/maven-parent/pull/52
> > > [4] https://github.com/apache/maven-parent/pull/53
> > > [5] https://github.com/apache/maven-parent/pull/54
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>

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

[Tibor Digana]

+1
sha512 ok
build ok

T

On Sun, Apr 3, 2022 at 5:36 PM Hervé BOUTEMY  wrote:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324322=12350902=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1734/
>
> https://repository.apache.org/content/repositories/maven-1734/org/apache/maven/plugins/maven-artifact-plugin/3.3.0/maven-artifact-plugin-3.3.0-source-release.zip
>
> Source release checksum(s):
> maven-artifact-plugin-3.3.0-source-release.zip sha512:
> f8fb4239a33a3699b4902a161252855e0033a6635b4bece0d26f15243c2e96b905bde82e8c1d2e97dd7c757ae182c783d69e36f1332cd64954685c06d9d1a10f
>
> 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 Apache Maven Clean Plugin Version 3.2.0

[Tibor Digana]

+1
The issues mentioned by Slawomir should be fixed after the release is
complete. Those issues are not a typical blocker.

On Fri, Apr 1, 2022 at 11:31 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> We solved 10 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12343770=Text=12317224
>
> There are still one issue left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCLEAN%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20ASC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1733
>
>
> https://repository.apache.org/service/local/repositories/maven-1733/content/org/apache/maven/plugins/maven-clean-plugin/3.2.0/maven-clean-plugin-3.2.0-source-release.zip
>
> Source release checksum(s):
> maven-clean-plugin-3.2.0-source-release.zip sha512:
>
> c0b28aa05009948f9dc65cb3e55e332c1c000f88e2f81de848611ac9f0d4b446a4c4afc6f86961a07d0f40d9862fb294c608a6aa12be316dc457ff76b80d0cf9
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-clean-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
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Review of used reports for Maven project sites.

[Tibor Digana]

Regarding the next 4 reports out of 5:

Test report
Checkstyle report
PMD report and
Taglist report

we should use the Sonar Cube as a substitution and the development +
release process should take the Sonar into account on the fly.

Then I would understand the purpose of removal.
But now I don't!

T




On Sun, Apr 3, 2022 at 10:46 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> We have plans for the next release for parents poms.
>
> Maybe I will be boring, but I still do not see any values for some of the
> reports for static documentation sites of components.
>
> Result of tests during release time has no value after some time. Important
> is the current result of tests on CI systems.
>
> Maybe someone will show me the value of it ... so I will stop asking.
>
> So proposition to remove:
>
> - surefire [1]
> - checkstyle [2]
> - pmd [3]
> - taglist [4]
> - invoker [5]
>
> [1] https://github.com/apache/maven-parent/pull/49
> [2] https://github.com/apache/maven-parent/pull/51
> [3] https://github.com/apache/maven-parent/pull/52
> [4] https://github.com/apache/maven-parent/pull/53
> [5] https://github.com/apache/maven-parent/pull/54
>
>
> --
> Sławomir Jaranowski
>

Re: Review of used reports for Maven project sites.

[Tibor Digana]

hm, I do not understand his change regarding PR #49.
The CI result is used to fail due to the Socket timeout. The same has
happened in the latest surefire result vote. The build was red, we tried to
restart the build for 3 days, and finally the build got green at the end of
the Vote.

Instead of removing the surefire report, we should adjust the process and
the template should be changed and a new entry (CI URL) should be added
along with Site link, SHA512, etc.

If one report is going to be removed, there should be some substitution but
mandatory substitution done prior.

This would improve the process while you prepare the release on your own,
but this should not be all. PR #49 seems to be incomplete.

On Sun, Apr 3, 2022 at 10:46 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> We have plans for the next release for parents poms.
>
> Maybe I will be boring, but I still do not see any values for some of the
> reports for static documentation sites of components.
>
> Result of tests during release time has no value after some time. Important
> is the current result of tests on CI systems.
>
> Maybe someone will show me the value of it ... so I will stop asking.
>
> So proposition to remove:
>
> - surefire [1]
> - checkstyle [2]
> - pmd [3]
> - taglist [4]
> - invoker [5]
>
> [1] https://github.com/apache/maven-parent/pull/49
> [2] https://github.com/apache/maven-parent/pull/51
> [3] https://github.com/apache/maven-parent/pull/52
> [4] https://github.com/apache/maven-parent/pull/53
> [5] https://github.com/apache/maven-parent/pull/54
>
>
> --
> Sławomir Jaranowski
>

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

[Tibor Digana]

Thank You guys.

The vote has passed with the following result:

+1 : Tibor Digana, Tamás Cservenák, Slawomir Jaranowski, Romain
Manni-Bucau, Christian Stein, Karl Heinz Marbaise, Delany, Sylwester
Lachiewicz, Dan Tran, Olivier Lamy, Arnaud Héritier, Hervé BOUTEMY

PMC quorum: accomplished.

I will promote the artifacts to the central repo.

T

On Thu, Mar 31, 2022 at 2:35 PM Tibor Digana  wrote:

> Hi,
>
> We solved 111 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12344613
>
> 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-1731/
>
> https://repository.apache.org/content/repositories/maven-1731/org/apache/maven/surefire/surefire/3.0.0-M6/surefire-3.0.0-M6-source-release.zip
>
> Source release checksum(s):
> surefire-3.0.0-M6-source-release.zip   sha512:
>
> 2ad963a52445100438c68ecc2d2eb3c3e2191a33494b255969d9ec37f1a418012b8cd71567201a87839f10a47a01d6b304a625a53d90237637755b06234f4bc7
>
> 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-M6

[Tibor Digana]

Thank You guys.

The vote has passed with the following result:

+1 : Tibor Digana, Tamás Cservenák, Slawomir Jaranowski, Romain
Manni-Bucau, Christian Stein, Karl Heinz Marbaise, Delany, Sylwester
Lachiewicz, Dan Tran, Olivier Lamy, Arnaud Héritier, Hervé BOUTEMY

PMC quorum: accomplished.

I will promote the artifacts to the central repo.

T

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

[Tibor Digana]

Hi Delany,

RunOrder reimplementation is a request received from several users.
If you have a concrete plan or a feature request, pls open a ticket and we
can talk about it in ASF Jira.
(This particular log message is printed if runOrder=random and the
ranOrderRandomSeed is NULL. Now I am not able to tell you my opinion, it
can be rather discussed with the author and the community in the JIRA.)
T

On Sat, Apr 2, 2022 at 9:36 PM Delany  wrote:

> Hi Tibor,
>
> When I run tests in random order I get the message "Tests will run in
> random order. To reproduce ordering use flag
> -Dsurefire.runOrder.random.seed=55174043965113"
> Can you make it always do that? When I provide the flag, I don't get the
> message, so there's no record of the seed.
>
> +1
> Tested on Linux & Windows, JDK8 & 11
> Delany
>
> On Sat, 2 Apr 2022 at 15:48, Tibor Digana  wrote:
>
> > Hi Delany,
> >
> > You used the plugin. Feel free to vote in this release.
> >
> > T
> >
> > On Thu, Mar 31, 2022 at 4:43 PM Delany 
> wrote:
> >
> > > Thanks. Tests run fine and I tried out the
> > > maven-surefire-junit5-tree-reporter
> > > Delany
> > >
> > > On Thu, 31 Mar 2022 at 16:22, Slawomir Jaranowski <
> > s.jaranow...@gmail.com>
> > > wrote:
> > >
> > > > Hi Delany,
> > > >
> > > > Site is staged:
> > > http://maven.apache.org/surefire-archives/surefire-LATEST/
> > > >
> > > >
> > > > czw., 31 mar 2022 o 15:50 Delany 
> > > napisał(a):
> > > >
> > > > > Hi Tibor,
> > > > >
> > > > > Does the site get staged as well, or do I have to build it myself?
> > > > >
> > > > > Thanks,
> > > > > Delany
> > > > >
> > > > > On Thu, 31 Mar 2022 at 14:35, Tibor Digana  >
> > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > We solved 111 issues:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12344613
> > > > > >
> > > > > > 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-1731/
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-1731/org/apache/maven/surefire/surefire/3.0.0-M6/surefire-3.0.0-M6-source-release.zip
> > > > > >
> > > > > > Source release checksum(s):
> > > > > > surefire-3.0.0-M6-source-release.zip   sha512:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 2ad963a52445100438c68ecc2d2eb3c3e2191a33494b255969d9ec37f1a418012b8cd71567201a87839f10a47a01d6b304a625a53d90237637755b06234f4bc7
> > > > > >
> > > > > > 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
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Sławomir Jaranowski
> > > >
> > >
> >
>

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

[Tibor Digana]

+1

T

On Thu, Mar 31, 2022 at 2:35 PM Tibor Digana  wrote:

> Hi,
>
> We solved 111 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12344613
>
> 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-1731/
>
> https://repository.apache.org/content/repositories/maven-1731/org/apache/maven/surefire/surefire/3.0.0-M6/surefire-3.0.0-M6-source-release.zip
>
> Source release checksum(s):
> surefire-3.0.0-M6-source-release.zip   sha512:
>
> 2ad963a52445100438c68ecc2d2eb3c3e2191a33494b255969d9ec37f1a418012b8cd71567201a87839f10a47a01d6b304a625a53d90237637755b06234f4bc7
>
> 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-M6

[Tibor Digana]

Hi Delany,

You used the plugin. Feel free to vote in this release.

T

On Thu, Mar 31, 2022 at 4:43 PM Delany  wrote:

> Thanks. Tests run fine and I tried out the
> maven-surefire-junit5-tree-reporter
> Delany
>
> On Thu, 31 Mar 2022 at 16:22, Slawomir Jaranowski 
> wrote:
>
> > Hi Delany,
> >
> > Site is staged:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> >
> > czw., 31 mar 2022 o 15:50 Delany 
> napisał(a):
> >
> > > Hi Tibor,
> > >
> > > Does the site get staged as well, or do I have to build it myself?
> > >
> > > Thanks,
> > > Delany
> > >
> > > On Thu, 31 Mar 2022 at 14:35, Tibor Digana 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > We solved 111 issues:
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12344613
> > > >
> > > > 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-1731/
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-1731/org/apache/maven/surefire/surefire/3.0.0-M6/surefire-3.0.0-M6-source-release.zip
> > > >
> > > > Source release checksum(s):
> > > > surefire-3.0.0-M6-source-release.zip   sha512:
> > > >
> > > >
> > >
> >
> 2ad963a52445100438c68ecc2d2eb3c3e2191a33494b255969d9ec37f1a418012b8cd71567201a87839f10a47a01d6b304a625a53d90237637755b06234f4bc7
> > > >
> > > > 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
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>

Re: Trying Maven v4

[Tibor Digana]

AFAIK, maven 4 is just a prototype.
T

On Sat, Apr 2, 2022 at 3:00 PM John Patrick  wrote:

> Hi,
> If I want to start testing maven v4.x is it the master branch or the mvn4
> branch I need to build?
> Or is there a guide I can look at with current/known issues or work
> arounds?
>
> I've a few issues/features I would like to raise and see if I can do
> patches for, mostly more profile options like for;
> settings.xml profile support for servers and mirrors.
> extensions.xml profile support for extensions.
> profile activation based upon other profiles being active or disabled.
>
> i.e. the com.soebes.maven.extensions:maven-buildtime-profiler is good to
> look into high build times, but for day to day usage I don't want every
> developer or cicd build with the extra overhead or verbose output. Just
> want it on release builds or when a developer enables a specific profile.
>
> Someone with a home office nexus so has a * to their
> own proxy, then whilst at a conference want to build they need to change
> their default settings.xml to remove that mirror. I've 4 settings.xml
> depending if home, travelling, in office or building from a maven staging
> repo like maven-1731 (for surefire v3.0.0-M6).
>
> All things just seam simpler switching different profiles.
>
> Cheers,
> John
>

Re: [DISCUSS] New Maven Core API for 4.x

[Tibor Digana]

Hi Guillaume,

I think it was in 2013 when I had IIRC chat with Jason and Kristian
Rosenvold that the model and Project is risky from the concurrency point of
view.
I found the setters implemented with ArrayList as thread unsafe, and I
proposed introducing Service classes with accessing the data member and not
to make setters public.
Having public getters would lead to immutable objects but having the
services would lead to miscellaneous design patterns in the code internals.
Kristain convinced me that we did not have a concurrency issue, so we did
nothing about it. Bad luck!

T

On Mon, Mar 28, 2022 at 7:30 PM Guillaume Nodet  wrote:

> What I have in mind is that plugins that use the new api would receive the
> immutable model, while plugins that use the old (3.x) api would receive a
> model that would wrap the immutable one. However, I think mutating the
> model or the maven project should be done via services provided by the
> maven api. That will allow controlling concurrent access, interception,
> logging, etc...
> For example, adding a source directory in the new api is done using the
> ProjectManager, which I think should be the place where the project is
> mutated:
>
>
> https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/services/ProjectManager.java
> I assume the number of plugins that mutate the project is small.  I think
> the best way would be to provide atomic apis for mutating the parts that
> need to be so that maven can have tighter control, but we can always
> provide an api to replace the Project or the Model with a new copy if
> needed so that any plugin can have the possibility to mutate those.
> Does that make sense?
>
> Guillaume
>
> Le lun. 28 mars 2022 à 13:47, Matt Benson  a écrit :
>
> > So in the new API, what kind of component would receive a mutable model
> if
> > not a plugin? I.e., what would be the correct mechanism for enhancing the
> > project model at runtime?
> >
> > Matt
> >
> > On Mon, Mar 28, 2022, 4:33 AM Guillaume Nodet  wrote:
> >
> > > Hi everyone,
> > >
> > > Last week, I worked on a fully immutable maven model. The results are
> > > available at [1].  The modifications required in modello were a bit too
> > > complicated, so I ended up using the modello models, but generating the
> > > models, readers and writers using velocity templates. The templates are
> > > actually way easier to modify than the modello generators, as you can
> see
> > > in the template generating the model [2] or the reader [3].  This also
> > > allows generating mergers and transformers.
> > > This also allows getting rid completely of plexus-utils dependency in
> the
> > > API.
> > >
> > > This all looks quite nice to me, however those changes are definitely
> > > incompatible, which means plugins will just break at runtime or compile
> > > time if they try to instantiate or modify objects from the model. If
> > > there's a consensus on trying to move forward with an immutable model,
> I
> > > can investigate generating this immutable model into a separate new
> > package
> > > and only use it for the new API, and rewrite the mutable model by
> > wrapping
> > > the immutable one. This would allow a smoother integration / migration.
> > >
> > > Feedback welcomed !
> > >
> > > Cheers,
> > > Guillaume Nodet
> > >
> > > [1] https://github.com/gnodet/maven/tree/m-api-immutable
> > > [2]
> > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-model/src/main/mdo/model.vm
> > > [3]
> > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
> > >
> > > Le lun. 14 mars 2022 à 08:59, Guillaume Nodet  a
> > écrit
> > > :
> > >
> > > > Hi everyone,
> > > >
> > > > As Michael hinted at this new API in the "[DISCUSS] Radical Fast
> > Forward
> > > > to 3.5.4" thread, I'd like to start the discussion around it.
> > > >
> > > > Over the past weeks, I've worked on an experimental API for Maven
> 4.x.
> > > > The goals are multiple :
> > > >   * fix some problems with designs that do not work well with
> > > > multithreading
> > > >   * offer a way to finally get rid of deprecated code
> > > >   * offer a complete API (which would deprecate m-artifact-transfer,
> > > > m-dependency-tree)
> > > >   * offer an homogeneous and a bit more modern API
> > > >   * completely hide the maven-resolver, so that it can finally
> upgrade
> > to
> > > > a v2 with the package renamed without too much disturbance
> > > >
> > > > The goal would be to extract the models and API in a separate project
> > > with
> > > > a much lower release cycle, as those rarely change, but are currently
> > > > released with each version of maven.
> > > >
> > > > The current API can be seen at [1].  Note that the plugins API has
> also
> > > > been included within the new API and the plugin tools have been
> updated
> > > so
> > > > that the maven-plugin-plugin supports both v3 api and the new v4 api.
> > 

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

[Tibor Digana]

Hi Delany, thx for trying it out and the feedback.
T

On Thu, Mar 31, 2022 at 4:43 PM Delany  wrote:

> Thanks. Tests run fine and I tried out the
> maven-surefire-junit5-tree-reporter
> Delany
>
> On Thu, 31 Mar 2022 at 16:22, Slawomir Jaranowski 
> wrote:
>
> > Hi Delany,
> >
> > Site is staged:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> >
> > czw., 31 mar 2022 o 15:50 Delany 
> napisał(a):
> >
> > > Hi Tibor,
> > >
> > > Does the site get staged as well, or do I have to build it myself?
> > >
> > > Thanks,
> > > Delany
> > >
> > > On Thu, 31 Mar 2022 at 14:35, Tibor Digana 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > We solved 111 issues:
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12344613
> > > >
> > > > 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-1731/
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-1731/org/apache/maven/surefire/surefire/3.0.0-M6/surefire-3.0.0-M6-source-release.zip
> > > >
> > > > Source release checksum(s):
> > > > surefire-3.0.0-M6-source-release.zip   sha512:
> > > >
> > > >
> > >
> >
> 2ad963a52445100438c68ecc2d2eb3c3e2191a33494b255969d9ec37f1a418012b8cd71567201a87839f10a47a01d6b304a625a53d90237637755b06234f4bc7
> > > >
> > > > 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
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>

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

[Tibor Digana]

Hi,

We solved 111 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12344613

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-1731/
https://repository.apache.org/content/repositories/maven-1731/org/apache/maven/surefire/surefire/3.0.0-M6/surefire-3.0.0-M6-source-release.zip

Source release checksum(s):
surefire-3.0.0-M6-source-release.zip   sha512:
2ad963a52445100438c68ecc2d2eb3c3e2191a33494b255969d9ec37f1a418012b8cd71567201a87839f10a47a01d6b304a625a53d90237637755b06234f4bc7

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: issues with the user property "maven.test.failure.ignore" and new proposals

[Tibor Digana]

. SUCCESS [
13.878 s]
[INFO] Maven Core . SUCCESS [01:19
min]
[INFO] Maven SLF4J Simple Provider  SUCCESS [
 3.678 s]
[INFO] Maven Embedder . SUCCESS [
15.397 s]
[INFO] Maven Compat ... SUCCESS [
53.385 s]
[INFO] Apache Maven Distribution .. SUCCESS [
27.397 s]
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time:  05:11 min
[INFO] Finished at: 2022-03-23T01:15:10+01:00
[INFO]


2. case
*$ mvn verify -nsu -Dmaven.test.failure.ignore*

[INFO] ---
[INFO]  T E S T S
[INFO] ---
Unrecognized option: -FFFO
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]

[INFO] Reactor Summary for Apache Maven 3.8.6-SNAPSHOT:
[INFO]
[INFO] Apache Maven ... SUCCESS [
18.186 s]
[INFO] Maven Model  FAILURE [
12.388 s]
[INFO] Maven Artifact . SKIPPED
...   ...   ...
[INFO] Apache Maven Distribution .. SKIPPED
[INFO]

[INFO] BUILD FAILURE
[INFO]



On Tue, Mar 22, 2022 at 11:44 AM Olivier Lamy  wrote:

> On Tue, 22 Mar 2022 at 14:40, Tibor Digana  wrote:
>
> > Sorry for late reply.
> >
> > I have created a demo project
> > https://github.com/Tibor17/maven.test.failure.ignore/  which simulates
> > OOM.
> >
> > According to the definition of the parameter "maven.failure.test.ignore"
> > the failures (also errors) should be ignored during testing.
> > The word "during" is important because the time when it was a failure
> > before JVM startup it was not a test failure - it is MOJO failure. The
> > author who wrote this config param knew this difference.
> > This perfectly fits JVM illegal arguments like -Xxxx.
> > But I have investigated OOM for the same reason with one JVM. My
> suspicion
> > was not confirmed, see the next...
> > If there are two JVMs, we are breaking the JVM during testing. It is a
> very
> > unlikely situation that the JVM argument would not fail in JVM1 but it
> > would fail in JVM2 later. It may happen only if the user
> > uses @surefire.forkCount@ interpolation but it is again very unlikely
> and
> > the users use it in current working directory configuration.
> >
> > I understand Olivier's PR but I have one objection to the code branching
> in
> > the class *SurefireHelper*. It is based on 3 levels but I have to
> disagree
> > due to there still should be 2 levels as before:
> > 1. ignored failures (my change is only here - yellow - only added
> throwing
> > exception)
> > 2. processes failures
> >
> > and so, I have created a PR
> > https://github.com/apache/maven-surefire/pull/496
> > Pls have a look into it, thx.
> > This diff looks very simple:
> >
> > if ( reportParameters.isTestFailureIgnore() )
> > {
> > String errorMessage = createErrorMessage( reportParameters,
> > result, firstForkException );
> >
> > if ( firstForkException instanceof SurefireBooterForkException )
> > {
> > throw new MojoExecutionException( errorMessage,
> firstForkException
> > );
> >
> > }
> >
> > log.error( errorMessage );
> > }
> > else
> > {
> > throwException( reportParameters, result, firstForkException );
> > }
> >
> >
> >
> > *$ mvn test*
> >
> > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> > 2.445 s <<< FAILURE! - in org.apache.maven.OOMTest
> > [ERROR] org.apache.maven.OOMTest.test  Time elapsed: 2.063 s  <<< ERROR!
> > java.lang.OutOfMemoryError: Java heap space
> > at org.apache.maven.OOMTest.test(OOMTest.java:15)
> > [INFO]
> > [INFO] Results:
> > [INFO]
> > [ERROR] Errors:
> > [ERROR]   OOMTest.test:15 » OutOfMemory Java heap space
> > [INFO]
> > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> > [INFO

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Tibor Digana]

n ERROR can be printed too.
> > > Similar with INFO, means that WARN and ERROR would be printed as well.
> > >
> > > The real decision making in the plugin is a bit more complicated, see
> the
> > > pull request https://github.com/apache/maven-surefire/pull/478
> > > After I have replied to this email, I would verify the behavior of the
> > > plugin simulating OOM.
> > >
> > >
> > > T
> > >
> > >
> > > On Fri, Mar 18, 2022 at 5:42 AM Christoph Läubrich <
> m...@laeubi-soft.de>
> > > wrote:
> > >
> > >> No I think more about
> > >>
> > >> if (severity == "WARN") {
> > >> log.warn("There is something wrong");
> > >> } else if (severity == "ERROR") {
> > >> throw new MojoFailureException("...") {
> > >> } else {
> > >> throw new MojoExecutionException("...") {
> > >> }
> > >>
> > >> That way the plugin can handle any error/failure/... in a way that the
> > >> user can "downgrade" a certain problem if desired.
> > >>
> > >>
> > >> Am 18.03.22 um 00:06 schrieb Tibor Digana:
> > >>> @Christoph
> > >>> FATAL ,   WARN ,   ERROR
> > >>> They are log levels?
> > >>> The plugin does not control the log level after caught exception in
> > Maven
> > >>> core. The Maven Core does!
> > >>> I think it's time to make a demo.
> > >>>
> > >>> On Thu, Mar 17, 2022 at 6:21 AM Christoph Läubrich <
> > m...@laeubi-soft.de>
> > >>> wrote:
> > >>>
> > >>>> Hi Tibor,
> > >>>>
> > >>>> it shouldn't be to hard to guess another property like
> > >>>>
> > >>>> maven.test.jvmcrash=FATAL
> > >>>> maven.test.failure=WARN
> > >>>> maven.test.error=ERROR
> > >>>>
> > >>>> :-)
> > >>>>
> > >>>> Am 16.03.22 um 12:25 schrieb Tibor Digana:
> > >>>>> Hi Christoph,
> > >>>>>
> > >>>>> Such a granularity with error/failure might be also an additional
> > >>>>> requirement but still you miss the third option to JVM error which
> is
> > >>>>> different from test error/failure - they don;t have the same
> meaning.
> > >>>>>
> > >>>>> T
> > >>>>>
> > >>>>>
> > >>>>> On Mon, Mar 14, 2022 at 10:57 AM Christoph Läubrich <
> > >> m...@laeubi-soft.de
> > >>>>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Just wondering but maybe it would be better to configure the
> > severity
> > >>>>>> instead of a true/false, something like:
> > >>>>>>
> > >>>>>> maven.test.failure=WARN
> > >>>>>> maven.test.error=ERROR
> > >>>>>>
> > >>>>>> would only warn about failing tests but thrw exception if starting
> > the
> > >>>>>> test fails?
> > >>>>>>
> > >>>>>> Am 14.03.22 um 10:52 schrieb Tibor Digana:
> > >>>>>>> Romain, it is not a bug.
> > >>>>>>> Don't consider this as a bug. It was a feature request for change
> > by
> > >>>>>>> Olivier, and not a bug.
> > >>>>>>> I closed both issues years ago but not because of ignorance but
> > >> because
> > >>>>>> the
> > >>>>>>> appearance of the exceptional behavior is a wrong compromise and
> > >> which
> > >>>>>> does
> > >>>>>>> not help anyone and even it makes the situation worse because
> > >> typically
> > >>>>>>> other group of users would fire a new Jira tickets. You would not
> > be
> > >>>> able
> > >>>>>>> to satisfy two contradictory parties which have completely
> > different
> > >>>>>>> opinions, and so we use to introduce new params and this way we
> > >> satisfy
> > >>>>>>> both parties, they may combine the params as they wish, and
> > e

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Tibor Digana]

@Christoph
FATAL ,   WARN ,   ERROR
They are log levels?
The plugin does not control the log level after caught exception in Maven
core. The Maven Core does!
I think it's time to make a demo.

On Thu, Mar 17, 2022 at 6:21 AM Christoph Läubrich 
wrote:

> Hi Tibor,
>
> it shouldn't be to hard to guess another property like
>
> maven.test.jvmcrash=FATAL
> maven.test.failure=WARN
> maven.test.error=ERROR
>
> :-)
>
> Am 16.03.22 um 12:25 schrieb Tibor Digana:
> > Hi Christoph,
> >
> > Such a granularity with error/failure might be also an additional
> > requirement but still you miss the third option to JVM error which is
> > different from test error/failure - they don;t have the same meaning.
> >
> > T
> >
> >
> > On Mon, Mar 14, 2022 at 10:57 AM Christoph Läubrich  >
> > wrote:
> >
> >> Just wondering but maybe it would be better to configure the severity
> >> instead of a true/false, something like:
> >>
> >> maven.test.failure=WARN
> >> maven.test.error=ERROR
> >>
> >> would only warn about failing tests but thrw exception if starting the
> >> test fails?
> >>
> >> Am 14.03.22 um 10:52 schrieb Tibor Digana:
> >>> Romain, it is not a bug.
> >>> Don't consider this as a bug. It was a feature request for change by
> >>> Olivier, and not a bug.
> >>> I closed both issues years ago but not because of ignorance but because
> >> the
> >>> appearance of the exceptional behavior is a wrong compromise and which
> >> does
> >>> not help anyone and even it makes the situation worse because typically
> >>> other group of users would fire a new Jira tickets. You would not be
> able
> >>> to satisfy two contradictory parties which have completely different
> >>> opinions, and so we use to introduce new params and this way we satisfy
> >>> both parties, they may combine the params as they wish, and everybody
> >> would
> >>> be happy and nobody would claim. Many technical solutions might exist,
> >> e.g.
> >>> param=boolean|string or new param=boolean, whatever.
> >>>
> >>> The truth is that this problem with (java --add-reads ...) happened in
> >> our
> >>> ASF environment on Java 8 which in good configuration would not happen
> >> and
> >>> should not.
> >>> It is not right way that we abuse "maven.test.failure.ignore" which
> would
> >>> tell us "Hey, you have illegal configuration in your build system and
> it
> >>> would not work by JDK design", it is not the goal of the plugin to tell
> >> you
> >>> that you have configured the build wrong because it won't and the same
> >>> configuration of the plugin (not the build)  says "ignore the error".
> >>> Yesterday I discussed this problem with Herve and we independently
> >> observed
> >>> equal opinions and that's not everything because we understood that the
> >>> purpose of the config parameter is to not throw MOJO exception which is
> >>> right, but the exceptional behavior should have an exact new param for
> >> the
> >>> exact use case.
> >>> SPI for this parameter is too much because no user would implement it
> >> for a
> >>> trivial parameter;; the SPI is used to be implemented by frameworks or
> >>> systems or application servers but this is not our case.
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Mar 14, 2022 at 9:11 AM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >>> wrote:
> >>>
> >>>> +1
> >>>> if it is to investigate a CI issue, it is generally easy to add debug
> >>>> insights (by code or agent) so a SPI sounds like the sanest for the
> >> plugin
> >>>> to me.
> >>>>
> >>>> 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: issues with the user property "maven.test.failure.ignore" and new proposals

[Tibor Digana]

Hi Slawomir,

Your second second example  -DargLine=-Xxx  is used in an integration test
in order to force producing exceptions, but IMHO it wants to simulate two
different situations.

In such cases the JVM:

1. fails on JVM startup because of low RAM
(fails the JVM on --add-reads or illegal VM parameter -Xxx and the user
wants to fail the build due to he considers this as a config error)
2. fails on OOM during the test - another CI process concurrently consumes
RAM too and randomly some processes reach OOM
(OOM during the tests - should not fail the build with
-Dmaven.test.failure.ignore=true)

We are not able to distinguish between JVM and ForkedBooter startup errors
due to the ForkedBooter does not notify the plugin with an event "I am
alive".

Currently this config parameter has this feature description in Javadoc:
*Set this to "true" to ignore a failure during testing. Its use is NOT
RECOMMENDED, but quite convenient on occasion.*

So, we have two options to fix it.
1. implement one more config param, or make a string from boolean in the
current one, or
2. distinguish between JVM and ForkedBooter startup by implementing a new
event HELLO, and use SurefireBooterForkException with some
marker forkStarted:boolean.

exit(1) is our custom error code, so we know that the ForkedBooter has
started and the build should not fail because you have
used -Dmaven.test.failure.ignore=true.

Personally, I would vote for impl #2.

Any thoughts?
Tibor














On Mon, Mar 14, 2022 at 6:18 PM Slawomir Jaranowski 
wrote:

> pon., 14 mar 2022 o 10:52 Tibor Digana 
> napisał(a):
>
> > Romain, it is not a bug.
> > Don't consider this as a bug. It was a feature request for change by
> > Olivier, and not a bug.
> > I closed both issues years ago but not because of ignorance but because
> the
> > appearance of the exceptional behavior is a wrong compromise and which
> does
> > not help anyone and even it makes the situation worse because typically
> > other group of users would fire a new Jira tickets. You would not be able
> > to satisfy two contradictory parties which have completely different
> > opinions, and so we use to introduce new params and this way we satisfy
> > both parties, they may combine the params as they wish, and everybody
> would
> > be happy and nobody would claim. Many technical solutions might exist,
> e.g.
> > param=boolean|string or new param=boolean, whatever.
> >
> > The truth is that this problem with (java --add-reads ...) happened in
> our
> > ASF environment on Java 8 which in good configuration would not happen
> and
> > should not.
> > It is not right way that we abuse "maven.test.failure.ignore" which would
> > tell us "Hey, you have illegal configuration in your build system and it
> > would not work by JDK design", it is not the goal of the plugin to tell
> you
> > that you have configured the build wrong because it won't and the same
> > configuration of the plugin (not the build)  says "ignore the error".
> >
>
>  So what is the difference:
>
> mvn test -Dmaven.test.failure.ignore=true
> -Dsurefire.rerunFailingTestsCount=notanumber
>
> mvn test -Dmaven.test.failure.ignore=true -DargLine=-Xxx
>
> for both I have illegal configuration in my build system, but one brak
> Maven build and one does not ...
>
>
> Yesterday I discussed this problem with Herve and we independently observed
> > equal opinions and that's not everything because we understood that the
> > purpose of the config parameter is to not throw MOJO exception which is
> > right, but the exceptional behavior should have an exact new param for
> the
> > exact use case.
> > SPI for this parameter is too much because no user would implement it
> for a
> > trivial parameter;; the SPI is used to be implemented by frameworks or
> > systems or application servers but this is not our case.
> >
> >
> >
> >
> > On Mon, Mar 14, 2022 at 9:11 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > +1
> > > if it is to investigate a CI issue, it is generally easy to add debug
> > > insights (by code or agent) so a SPI sounds like the sanest for the
> > plugin
> > > to me.
> > >
> > > 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://ww

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Tibor Digana]

Hi Christoph,

Such a granularity with error/failure might be also an additional
requirement but still you miss the third option to JVM error which is
different from test error/failure - they don;t have the same meaning.

T


On Mon, Mar 14, 2022 at 10:57 AM Christoph Läubrich 
wrote:

> Just wondering but maybe it would be better to configure the severity
> instead of a true/false, something like:
>
> maven.test.failure=WARN
> maven.test.error=ERROR
>
> would only warn about failing tests but thrw exception if starting the
> test fails?
>
> Am 14.03.22 um 10:52 schrieb Tibor Digana:
> > Romain, it is not a bug.
> > Don't consider this as a bug. It was a feature request for change by
> > Olivier, and not a bug.
> > I closed both issues years ago but not because of ignorance but because
> the
> > appearance of the exceptional behavior is a wrong compromise and which
> does
> > not help anyone and even it makes the situation worse because typically
> > other group of users would fire a new Jira tickets. You would not be able
> > to satisfy two contradictory parties which have completely different
> > opinions, and so we use to introduce new params and this way we satisfy
> > both parties, they may combine the params as they wish, and everybody
> would
> > be happy and nobody would claim. Many technical solutions might exist,
> e.g.
> > param=boolean|string or new param=boolean, whatever.
> >
> > The truth is that this problem with (java --add-reads ...) happened in
> our
> > ASF environment on Java 8 which in good configuration would not happen
> and
> > should not.
> > It is not right way that we abuse "maven.test.failure.ignore" which would
> > tell us "Hey, you have illegal configuration in your build system and it
> > would not work by JDK design", it is not the goal of the plugin to tell
> you
> > that you have configured the build wrong because it won't and the same
> > configuration of the plugin (not the build)  says "ignore the error".
> > Yesterday I discussed this problem with Herve and we independently
> observed
> > equal opinions and that's not everything because we understood that the
> > purpose of the config parameter is to not throw MOJO exception which is
> > right, but the exceptional behavior should have an exact new param for
> the
> > exact use case.
> > SPI for this parameter is too much because no user would implement it
> for a
> > trivial parameter;; the SPI is used to be implemented by frameworks or
> > systems or application servers but this is not our case.
> >
> >
> >
> >
> > On Mon, Mar 14, 2022 at 9:11 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> +1
> >> if it is to investigate a CI issue, it is generally easy to add debug
> >> insights (by code or agent) so a SPI sounds like the sanest for the
> plugin
> >> to me.
> >>
> >> 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 lun. 14 mars 2022 à 09:08, Guillaume Nodet  a
> écrit
> >> :
> >>
> >>> If that's not currently possible, maybe a SPI should be provided so
> that
> >>> people can use plug in extensions to analyze the test result and
> override
> >>> it if necessary (transforming an error into a warning, storing results
> >> in a
> >>> way which is easier to use by other tools later...) ?
> >>>
> >>> Guillaume
> >>>
> >>> Le lun. 14 mars 2022 à 07:43, Christoph Läubrich 
> a
> >>> écrit :
> >>>
> >>>> I also agree that the test at least should run, we use this property
> to
> >>>> run the test and produce result and later on have a buildstep that
> >>>> analyze the results (and probably fail the build job).
> >>>>
> >>>> As it is not recommend, I wonder what is the recommended way to
> archive
> >>>> something similar?
> >>>>
> >>>> Am 14.03.22 um 06:29 schrieb Olivier Lamy:
> >>>>> On Mon, 14 Mar 2022 at 11:55, Tibor Digana 
> >>>> wrote:

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Tibor Digana]

Romain, it is not a bug.
Don't consider this as a bug. It was a feature request for change by
Olivier, and not a bug.
I closed both issues years ago but not because of ignorance but because the
appearance of the exceptional behavior is a wrong compromise and which does
not help anyone and even it makes the situation worse because typically
other group of users would fire a new Jira tickets. You would not be able
to satisfy two contradictory parties which have completely different
opinions, and so we use to introduce new params and this way we satisfy
both parties, they may combine the params as they wish, and everybody would
be happy and nobody would claim. Many technical solutions might exist, e.g.
param=boolean|string or new param=boolean, whatever.

The truth is that this problem with (java --add-reads ...) happened in our
ASF environment on Java 8 which in good configuration would not happen and
should not.
It is not right way that we abuse "maven.test.failure.ignore" which would
tell us "Hey, you have illegal configuration in your build system and it
would not work by JDK design", it is not the goal of the plugin to tell you
that you have configured the build wrong because it won't and the same
configuration of the plugin (not the build)  says "ignore the error".
Yesterday I discussed this problem with Herve and we independently observed
equal opinions and that's not everything because we understood that the
purpose of the config parameter is to not throw MOJO exception which is
right, but the exceptional behavior should have an exact new param for the
exact use case.
SPI for this parameter is too much because no user would implement it for a
trivial parameter;; the SPI is used to be implemented by frameworks or
systems or application servers but this is not our case.




On Mon, Mar 14, 2022 at 9:11 AM Romain Manni-Bucau 
wrote:

> +1
> if it is to investigate a CI issue, it is generally easy to add debug
> insights (by code or agent) so a SPI sounds like the sanest for the plugin
> to me.
>
> 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 lun. 14 mars 2022 à 09:08, Guillaume Nodet  a écrit
> :
>
> > If that's not currently possible, maybe a SPI should be provided so that
> > people can use plug in extensions to analyze the test result and override
> > it if necessary (transforming an error into a warning, storing results
> in a
> > way which is easier to use by other tools later...) ?
> >
> > Guillaume
> >
> > Le lun. 14 mars 2022 à 07:43, Christoph Läubrich  a
> > écrit :
> >
> > > I also agree that the test at least should run, we use this property to
> > > run the test and produce result and later on have a buildstep that
> > > analyze the results (and probably fail the build job).
> > >
> > > As it is not recommend, I wonder what is the recommended way to archive
> > > something similar?
> > >
> > > Am 14.03.22 um 06:29 schrieb Olivier Lamy:
> > > > On Mon, 14 Mar 2022 at 11:55, Tibor Digana 
> > > wrote:
> > > >
> > > >> In case of the user property *maven.test.failure.ignore* the MOJO
> must
> > > not
> > > >> throw any exception which is interpreted by the Maven Core as BUILD
> > > >> SUCCESS.
> > > >>
> > > >
> > > > This is a very simple reduction of the problem description.
> > > > The documentation here
> > > >
> > >
> >
> https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#testFailureIgnore
> > > > says
> > > > "Set this to "true" to ignore a failure during testing. Its use is
> NOT
> > > > RECOMMENDED, but quite convenient on occasion"
> > > >
> > > > Personally, I understand this to ignore failures in junit results BUT
> > at
> > > > least I want the tests to run.
> > > > I guess this is how our users use this feature (feature we do not
> > > recommend
> > > > by the way...)
> > > > And this is perfectly explained here
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/SUREFIRE-1426?focusedCommentId=16188077=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16188077
> > > > there is a difference between ignoring som

issues with the user property "maven.test.failure.ignore" and new proposals

[Tibor Digana]

In case of the user property *maven.test.failure.ignore* the MOJO must not
throw any exception which is interpreted by the Maven Core as BUILD SUCCESS.

We have received an internal requirement to change the behavior of the user
property *maven.test.failure.ignore* so that the behavior will have one
exception.

Suppose that you have JDK 1.8 but you use:
/jre/java --add-reads ...
The outcome is JVM exit with an error message.
I agree with Herve who also says that  *maven.test.failure.ignore* should
not allow the MOJO to throw the exception. It is not a typical JVM
segmentation fault or another JVM crash where we cannot do anything about
it, and where the entire build would crash in the command line which
of course means that the build cannot normally be interpreted as BUILD
SUCCESS. So we are still on the same level of failures related to the test
purposes.

On the other hand, Olivier has reopened the issues SUREFIRE-1426 and
SUREFIRE-1681 where the exceptional behavior of the feature is expected.
This is exactly the reason why I closed these tickets several years ago and
my proposal was to not to have any exceptions in the feature behavior and
the proposal was to introduce a new user property for exact use cases.
The next idea, which comes from two developers, would provide us with the
same non exceptional and exact behavior of the user property
*maven.test.failure.ignore* but it would also provide us with new user
property in the case with fine grade control of the build errors, e.g.
*maven.test.jvm.error.ignore*.


I would like to open the discussion on this topic. You're welcome!


Cheers
Tibor

The build status in Maven 3.x and MOJO exceptions in Maven Plugin API 3.x

[Tibor Digana]

Hello Maven developers,

I want to inform you about some compliance issues between the Javadoc of
Maven Plugin API and the Maven Core 3.x behavior. I am only a messenger
providing the facts and I would like the community to post the opinions and
finally a concrete fix(es).

The Maven 3 reports with info log in case of MOJO throws Mojo exception
[INFO] BUILD FAILURE

The Maven 2 reports with error log in case of MOJO throws Mojo exception:
[ERROR] BUILD ERROR
[ERROR] BUILD FAILURE

Maven 3 is not compliant with the Javadoc in Maven Plugin API 3.8.4 which
says the following:

[1] Javadoc in MojoExecutionException:
"An exception occurring during the execution of a plugin (such as a
compilation failure).
Throwing this exception causes a "BUILD FAILURE" message to be displayed."

[2] Javadoc in MojoFailureException:
"An exception occurring during the execution of a plugin.
Throwing this exception causes a "BUILD ERROR" message to be displayed."

For me the wording in the API matters.
Personally, I agree with the name of the class MojoFailureException which
contains "Failure" and the wording of the build status correctly
corresponds to "BUILD FAILURE".
If this wording relation exists, it looks like it is an intended rule, but
the other exception MojoExecutionException does not match this rule because
no such BUILD EXECUTION exists of course.

Regarding the OOP inheritance current diagram looks like this:
MojoExecutionException extends AbstractMojoExecutionException
MojoFailureException extends AbstractMojoExecutionException

For me, a fix in the class inheritance could be compliant with "BUILD
FAILURE"  if the MojoExecutionException was a type of MojoFailureException,
and a certain inheritance diagram with more sub-exceptions and one
super-exception. Just my proposal:
MojoExecutionException extends MojoFailureException.

Perhaps the Javadoc should be fixed, perhaps the inheritance or the build
status, log level, not sure, just opening the questions for the audience.

[1]:
https://maven.apache.org/ref/3.8.4/maven-plugin-api/apidocs/org/apache/maven/plugin/MojoExecutionException.html


[2]:
https://maven.apache.org/ref/3.8.4/maven-plugin-api/apidocs/org/apache/maven/plugin/MojoFailureException.html


Cheers
Tibor

Re: [VOTE] Release Apache Maven version 3.8.5

[Tibor Digana]

+1

T

On Sat, Mar 5, 2022 at 5:47 PM Michael Osipov  wrote:

> Hi,
>
> We solved 27 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12351105
>
> There are still hundreds of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1724/
>
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/
>
> Source release checksums:
> apache-maven-3.8.5-src.zip sha512:
>
> 7edb6864834a81c11cf9d22a8110abc3f5f96360bdbc4bc33ec0c98dc389dd9fc71465253a87729dbe7b8a011b2ec38afa0e011172657c3a97ef96fb6f40292b
> apache-maven-3.8.5-src.tar.gz sha512:
>
> 1aa1b2dcba794b7e4cbc8e2ff9baf64283fb3883ae93efff26fe259578504b60a8b68404a074f4741922e462fa696cbbe71f9d74e4e6316ed0e389d25667
>
> Binary release checksums:
> apache-maven-3.8.5-bin.zip sha512:
>
> f9f838b4adaf23db0204a6cafa52bf1125bd2d649fd676843fd05e82866b596ec19c4f3de60d5e3ff17f10a63d96c141311ff9bc2bfa816eade7a5cbff2bd925
> apache-maven-3.8.5-bin.tar.gz sha512:
>
> 89ab8ece99292476447ef6a6800d9842bbb60787b9b8a45c103aa61d2f205a971d8c3ddfb8b03e514455b4173602bd015e82958c0b3ddc1728a57126f773c743
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/292
>
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open until 2021-03-13T12: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 Apache Maven Parent POMs version 35

[Tibor Digana]

+1
T

Dňa ne 27. 2. 2022, 19:12 Hervé BOUTEMY  napísal(a):

> Hi,
>
> We solved 18 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12346694=Text
>
> Changes since the last release:
>
> https://github.com/apache/maven-parent/compare/maven-parent-34...maven-parent-35#diff
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1718/
>
> https://repository.apache.org/content/repositories/maven-1718/org/apache/maven/maven-parent/35/maven-parent-35-source-release.zip
>
> Source release checksum(s):
> maven-parent-35-source-release.zip sha512:
> 877a797a4092cca61642943c0f9bc8dd3da76bf5596907cfde21aa66c1fc1cb81258ac84818ec223b075a258f3cc5acbc92669a6b9e1c6ce83758be213941705
>
> Staging site:
> https://maven.apache.org/pom-archives/maven-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: Review of used reports for Maven project sites.

[Tibor Digana]

We have tried that on GitHub Actions and it was not terribly slow.
It was only useless to force every build configuration to run the
maven site.
Notice that the GH Actions are quite fast and if you employ only one
special run for "mvn site" with a deployment to a web container or gh_pages
then it would be the same as checking the logs or test reports because we
would check the particular HTMLs (not all.).

On Thu, Feb 24, 2022 at 9:47 PM Tamás Cservenák  wrote:

> Building everything for each commit is insane.
>
> Also, I find a release mgr that does NOT check is site building beforehand
> release as sloppy.
>
> Hence, building everything on each commit just to suit sloppy release mgrs
> is insane IMHO.
>
> My 5 cents.
>
> T
>
> On Thu, Feb 24, 2022 at 9:30 PM Olivier Lamy  wrote:
>
> > Sounds good.
> >  But who has never released something and having javadoc failing in the
> > middle of the release or the site generation failing once tag done and
> > artifacts staged… I find this a pain 
> >
> > Maybe only testing javadoc works at least ?
> >
> > Btw I agree some reports could be removed
> >
> > On Fri, 25 Feb 2022 at 6:24 am,  wrote:
> >
> > > and reporting profile was done for this:
> > > - without reporting profile, just light site generation
> > > - with reporting profile, full documentation site
> > >
> > > disabling reporting profile for CI should do the job
> > >
> > > - Mail original -
> > > De: "herve boutemy" 
> > > À: "Maven Developers List" 
> > > Envoyé: Jeudi 24 Février 2022 21:21:45
> > > Objet: Re: Review of used reports for Maven project sites.
> > >
> > > done on GH and Jenkins, then on each commit?
> > > we're heating oceans for nothing
> > >
> > > IMHO, we need to differentiate CI vs release documentation: CI should
> be
> > > much lighter than release
> > >
> > > - Mail original -
> > > De: "Slawomir Jaranowski" 
> > > À: "Maven Developers List" 
> > > Envoyé: Jeudi 24 Février 2022 20:53:49
> > > Objet: Re: Review of used reports for Maven project sites.
> > >
> > > Yes is done after release but also on jenkins for plugins and on GH
> > builds
> > >
> > > czw., 24 lut 2022 o 20:43  napisał(a):
> > >
> > > > full site building with reports enabled (through reporting profile)
> is
> > > > just done after release, isn't it?
> > > >
> > > > - Mail original -
> > > > De: "Slawomir Jaranowski" 
> > > > À: "Maven Developers List" 
> > > > Envoyé: Jeudi 24 Février 2022 20:24:56
> > > > Objet: Review of used reports for Maven project sites.
> > > >
> > > > Hi,
> > > >
> > > > Building the Maven site takes a long time for our projects.
> > > >
> > > > Before releasing the next version of maven-parent, I have a proposal
> to
> > > > review used Maven site reports.
> > > >
> > > > So
> > > >
> > > >  - without reporting profile, standard
> > maven-project-info-reports-plugin
> > > -
> > > > build very quick - no problems
> > > >
> > > > - with reporting profile:
> > > >   - surefire   -  require test phase - can have influence on build
> time
> > > >   - checkstyle
> > > >   - pmd
> > > >   - jxr - needed by other reports
> > > >   - taglist
> > > >   - javadoc - require generate-sources
> > > >
> > > > - for plugins and extensions additional invoker report is added.
> > > >
> > > > I starting to think what of benefit we have, who is looking at
> reports
> > > > like: surefire, checkstyle, pmd, taglist
> > > > Maybe they are redundant - tests, checkstyle verification simply must
> > > pass
> > > >
> > > > --
> > > > Sławomir Jaranowski
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Re: Review of used reports for Maven project sites.

[Tibor Digana]

There is such a situation where the contributor changes the site, we vote
for his PR on GH but we lately find out that the site is broken in some
way. If I could see the site deployed to gh_pages which is a Git branch and
visualized on GH then the contributor would fix it much better.

Of course building the site with all the combinations of Maven & JDK would
be an overhead. One run is enough.
T

On Thu, Feb 24, 2022 at 8:25 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> Building the Maven site takes a long time for our projects.
>
> Before releasing the next version of maven-parent, I have a proposal to
> review used Maven site reports.
>
> So
>
>  - without reporting profile, standard maven-project-info-reports-plugin -
> build very quick - no problems
>
> - with reporting profile:
>   - surefire   -  require test phase - can have influence on build time
>   - checkstyle
>   - pmd
>   - jxr - needed by other reports
>   - taglist
>   - javadoc - require generate-sources
>
> - for plugins and extensions additional invoker report is added.
>
> I starting to think what of benefit we have, who is looking at reports
> like: surefire, checkstyle, pmd, taglist
> Maybe they are redundant - tests, checkstyle verification simply must pass
>
> --
> Sławomir Jaranowski
>

Re: [VOTE] Release Apache Maven Doxia Sitetools version 2.0.0-M2

[Tibor Digana]

+1
build .. ok
checksum .. ok
T

On Thu, Feb 17, 2022 at 3:03 PM Michael Osipov  wrote:

> Hi,
>
> We solved 9 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320=12351319
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1716
>
> https://repository.apache.org/content/repositories/maven-1716/org/apache/maven/doxia/doxia-sitetools/2.0.0-M2/doxia-sitetools-2.0.0-M2-source-release.zip
>
> Source release checksum(s):
> doxia-sitetools-2.0.0-M2-source-release.zip
> sha512:
>
> 551886d539ffccc977ea606a4fab621ceac075a297d286e9637f48badd662710b68019d36a20517193c46aa7c76282267275e069e9b8ddd635a6e7019d584f3f
>
> Staging site:
>
> https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-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 Parent POM version 25

[Tibor Digana]

+1


On Thu, Feb 17, 2022 at 11:17 PM Hervé BOUTEMY 
wrote:

> Hi,
>
> We solved 10 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12350295=Text
>
> https://github.com/apache/maven-apache-parent/compare/apache-24...apache-25
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheapache-1022/
>
> https://repository.apache.org/content/repositories/orgapacheapache-1022/org/apache/apache/25/apache-25-source-release.zip
>
> Source release checksum(s):
> apache-25-source-release.zip sha512:
> 18c3964f4684031739dfd246f9cafca19661937d27b1ab4514ad88c983984e6a6b056ea968a6c0ccdeeacd4540a82dd6631428cb64a4eb75fcaa6c0b11ec1517
>
> 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 Indexer 6.1.1

[Tibor Digana]

+1

On Mon, Feb 14, 2022 at 11:48 AM Tamás Cservenák 
wrote:

> Howdy,
>
> We solved many issues (6.1.0 canceled release + 6.1.1 are both assigned to
> 6.1.1 version):
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317523=12351333
>
> There are still some issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINDEXER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-1715/
>
> Source release and SHA512 checksum:
>
> https://repository.apache.org/content/repositories/maven-1715/org/apache/maven/indexer/maven-indexer/6.1.1/maven-indexer-6.1.1-source-release.zip
>
> a9bc67895f1a76b5bf7c3bd4270ecc97de477ac4b05945bc15d59d71ccac9699b8b56f9216a29bc7c63a1c838fcd2aa05ae9681753d6d69a5594fdd0961e5196
>
> Staging site:
> https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [VOTE] Maven Compiler Plugin 3.10.0

[Tibor Digana]

+1
Build .. ok

Dňa pi 11. 2. 2022, 10:37 Olivier Lamy  napísal(a):

> Hi,
> I'd like to release Apache Maven Compiler Plugin 3.10.0
>
> 7 issues fixed
> https://issues.apache.org/jira/projects/MCOMPILER/versions/12351256
>
> draft github release notes (sadly only for people with write access as it's
> a draft:() :
>
> https://github.com/apache/maven-compiler-plugin/releases/tag/untagged-afb69321207f90da84d2
>
>
> staging repo
> https://repository.apache.org/content/repositories/maven-1710/
> artifacts here
>
> https://repository.apache.org/content/repositories/maven-1710/org/apache/maven/plugins/maven-compiler-plugin/3.10.0/
>
> staging site
> https://maven.apache.org/plugins-archives/maven-compiler-plugin-LATEST/
>
> Vote open for 72H
>
> cheers
> --
> Olivier
>

Re: [VOTE] Release Apache Maven Reporting Exec version 1.6.0

[Tibor Digana]

+1
build .. ok
sha .. ok

On Thu, Feb 10, 2022 at 9:25 AM Michael Osipov  wrote:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12348417
>
> 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-reporting-exec
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1708/
>
> https://repository.apache.org/content/repositories/maven-1708/org/apache/maven/reporting/maven-reporting-exec/1.6.0/maven-reporting-exec-1.6.0-source-release.zip
>
> Source release checksum(s):
> maven-reporting-exec-1.6.0-source-release.zip
> sha512:
>
> f7ee1ccc57e8c61e5c2badd856937ce463f7b7063656b31d247c5175d1c17bf565208d5a7ef45bd87d8aca6842309b4ab2b41211bb612a8e59ce512526723245
>
> 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 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 Indexer 6.1.0

[Tibor Digana]

+1
build .. ok
sha .. ok

On Fri, Feb 11, 2022 at 11:28 AM Tamás Cservenák 
wrote:

> Howdy,
>
> We solved many issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317523=12342225
>
> There are still a handful of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINDEXER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-1712/
>
> Source release and checksum:
>
> https://repository.apache.org/content/repositories/maven-1712/org/apache/maven/indexer/maven-indexer/6.1.0/maven-indexer-6.1.0-source-release.zip
> SHA512:
>
> 3c07febb84eba22cbf4b529cbd35fa1929a5ca59e5aab757cb6b199691dd36b3514ecf59c47ffac2a8cb01bea40af8e3367e4affc7bb4907197dff2cf2ac99da
>
> Staging site:
> https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [VOTE] Release Maven Indexer 6.1.0

[Tibor Digana]

Tamas, do you also have empty pages?
https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/maven-indexer-examples/indexer-examples-basic/index.html
https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/maven-indexer-examples/indexer-examples-spring/index.html


On Fri, Feb 11, 2022 at 11:28 AM Tamás Cservenák 
wrote:

> Howdy,
>
> We solved many issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317523=12342225
>
> There are still a handful of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINDEXER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-1712/
>
> Source release and checksum:
>
> https://repository.apache.org/content/repositories/maven-1712/org/apache/maven/indexer/maven-indexer/6.1.0/maven-indexer-6.1.0-source-release.zip
> SHA512:
>
> 3c07febb84eba22cbf4b529cbd35fa1929a5ca59e5aab757cb6b199691dd36b3514ecf59c47ffac2a8cb01bea40af8e3367e4affc7bb4907197dff2cf2ac99da
>
> Staging site:
> https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: Upcoming release of maven-dependency-plugin

[Tibor Digana]

Hi Falco, do not keep it in your mind, file a Jira ticket. If you post a PR
in progress, it would be worth to give a feedback in advance. Somebody may
guide you in the right direction rather sooner than later. T

Dňa št 10. 2. 2022, 11:45 Falko Modler  napísal(a):

> TBH, I haven't created an issue yet. I wanted to create a working draft
> first and play around with it to see whether it meets my needs.
>
> I might be able to finish it on Sunday.
>
> Cheers,
>
> Falko
>
> Am 10.02.2022 um 09:40 schrieb Slawomir Jaranowski:
> > Hi Falko
> >
> > Which issue are you working on?
> > How much time do you need to finish your work?
> >
> > czw., 10 lut 2022 o 01:07 Falko Modler  napisał(a):
> >
> >> Hi Slawomir,
> >>
> >> a few weeks ago I started working on extending the "properties" goal to
> >> create a version property per dependency.
> >>
> >> This would be very useful for projects like Quarkus that have a big BOM
> >> and would like to reuse versions from that BOM for various things in
> >> integration tests etc.
> >>
> >> It would be nice to have more time to finish that, but I wouldn't call
> >> this "critical".
> >>
> >> Cheers,
> >>
> >> Falko
> >>
> >> Am 09.02.2022 um 23:50 schrieb Slawomir Jaranowski:
> >>> Hi,
> >>>
> >>> There are 17 issues resolved
> >>>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12340588
> >>> Some of them are critical.
> >>>
> >>> Do we have plans to resolve more issues in the near future?
> >>>
> >>> Last release was about 7 months ago.
> >>>
> >>> If there are no objections I can take care of it next week.
> >>>
> >>
> >> -
> >> 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 Doxia Sitetools version 2.0.0-M1

[Tibor Digana]

Create a Jira ticket or PR for moving from Mvn 2.2.1 to 3.0.
That would be the way but not to stop this release only because the version
2.2.1 is old and ugly. The build works and M1 should be verified in
practice.
T

On Tue, Feb 1, 2022 at 10:54 PM Guillaume Nodet  wrote:

> -1
>
> Would it be possible to at least get rid of direct (and transitive if
> possible) dependencies on maven 2.x artifacts ? Especially those that do
> not exist anymore... I can raise a PR tomorrow if that's ok.
>
> ➜  maven-doxia-sitetools git:(master) mvnd dependency:tree  | grep
>  org.apache.maven\:
> [doxia-integration-tools] [INFO] +-
> org.apache.maven:maven-artifact:jar:2.2.1:compile
> [doxia-integration-tools] [INFO] +-
> org.apache.maven:maven-artifact-manager:jar:2.2.1:provided
> [doxia-integration-tools] [INFO] |  +-
> org.apache.maven:maven-repository-metadata:jar:2.2.1:provided
> [doxia-integration-tools] [INFO] +-
> org.apache.maven:maven-model:jar:2.2.1:compile
> [doxia-integration-tools] [INFO] +-
> org.apache.maven:maven-project:jar:2.2.1:provided
> [doxia-integration-tools] [INFO] |  +-
> org.apache.maven:maven-settings:jar:2.2.1:provided
> [doxia-integration-tools] [INFO] |  +-
> org.apache.maven:maven-profile:jar:2.2.1:provided
> [doxia-integration-tools] [INFO] |  \-
> org.apache.maven:maven-plugin-registry:jar:2.2.1:provided
> [doxia-integration-tools] [INFO] +-
> org.apache.maven:maven-plugin-api:jar:2.2.1:compile
> [doxia-integration-tools] [INFO]+-
> org.apache.maven:maven-core:jar:2.0:test
> [doxia-integration-tools] [INFO]|  +-
> org.apache.maven:maven-plugin-parameter-documenter:jar:2.0:test
> [doxia-integration-tools] [INFO]|  +-
> org.apache.maven:maven-error-diagnostics:jar:2.0:test
> [doxia-integration-tools] [INFO]|  +-
> org.apache.maven:maven-plugin-descriptor:jar:2.0:test
> [doxia-integration-tools] [INFO]|  +-
> org.apache.maven:maven-monitor:jar:2.0:test
> [doxia-site-renderer] [INFO] +-
> org.apache.maven:maven-artifact:jar:2.2.1:compile
>
> Le mar. 1 févr. 2022 à 21:40, Michael Osipov  a
> écrit :
>
> > Hi,
> >
> > We solved 6 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320=12351216
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1703
> >
> >
> https://repository.apache.org/content/repositories/maven-1703/org/apache/maven/doxia/doxia-sitetools/2.0.0-M1/doxia-sitetools-2.0.0-M1-source-release.zip
> >
> > Source release checksum(s):
> > doxia-sitetools-2.0.0-M1-source-release.zip
> > sha512:
> >
> >
> 3f7f4f8406b02afe589880c76540612af0ae633c4960a3b25f5c14454a821ab5f20a3dbae47223f93d26b6ee32f7baccd4111e0699bae6d16ce862813be36af5
> >
> > Staging site:
> >
> >
> https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-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
> >
> >
>
> --
> 
> Guillaume Nodet
>

Re: [VOTE] Release Apache Maven Doxia Sitetools version 2.0.0-M1

[Tibor Digana]

+1
build ... ok

On Tue, Feb 1, 2022 at 9:40 PM Michael Osipov  wrote:

> Hi,
>
> We solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320=12351216
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1703
>
> https://repository.apache.org/content/repositories/maven-1703/org/apache/maven/doxia/doxia-sitetools/2.0.0-M1/doxia-sitetools-2.0.0-M1-source-release.zip
>
> Source release checksum(s):
> doxia-sitetools-2.0.0-M1-source-release.zip
> sha512:
>
> 3f7f4f8406b02afe589880c76540612af0ae633c4960a3b25f5c14454a821ab5f20a3dbae47223f93d26b6ee32f7baccd4111e0699bae6d16ce862813be36af5
>
> Staging site:
>
> https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-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 Reporting Impl version 3.1.0

[Tibor Digana]

+1
sha ... ok
build ... ok


On Sat, Feb 5, 2022 at 10:42 PM Michael Osipov  wrote:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12341015
>
> 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-reporting-impl
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1706/
>
> https://repository.apache.org/content/repositories/maven-1706/org/apache/maven/reporting/maven-reporting-impl/3.1.0/maven-reporting-impl-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-reporting-impl-3.1.0-source-release.zip
> sha512:
>
> 8f7012a05db0486e41eb62ac423fce6a65b75e525ec11a20b6279c5f7280191d039ca9ad48f424d86ee55e436fb848c91fea401d4e9f931a754180a9a919ac76
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-reporting-impl-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]

Hi Xeno,
The openjdk would close such a PR which has no attention. I am keeping it
open if it is not necessary to close it, and I am doing it because I
respect the time the contributor has spent on it and I want to give him a
chance to continue or open a discussion. Yesterday I closed one old PR
because Maven 3.0.5 is obsolete which is proven on our pages, it was
necessary to close it. <- corner case!!!

IMHO, the rules for people should be written very slowly, they should be
verified in practice step by step. For sure, if I have to write them, I
would rather start with one border/corner case and not many cases.

The rule "wait 3 days" would imply that the people would absent from
discussions and it would be legal, the quality would go down.
So we have to decide whether we need to have features regardless of
quality, or we want to have features and quality.

Cheers
Tibor

On Fri, Feb 4, 2022 at 12:57 PM Xeno Amess  wrote:

> things in openjdk is if a pr cannot gain interest from any already-in
> members, although it might be a great pr, it is automatically-closed.
>
> > There cannot be a rule "No review" -> "wait 3 days" -> "accept" because
> this is the thing everybody would utilize to involve a trojan horse.
>
> yep, at least one apache-committer's review is needed I think.
>
> And apache-committer is hard to become, as I myself even not being one.
>
> Tibor Digana  于2022年2月4日周五 19:46写道：
>
> > Slawomir, we have a fundamental problem.
> > You want to accept PR. But I say that the purpose of PR is not to accept
> it
> > because the ASFshould be always critical and therefore I think the rules
> > cannot be written in terms "When to accept the PR".
> > There should be rules "When not to accept the PR" because we should be
> > critical to the PRs - that's the purpose of the existence of
> pull-requests.
> > If there is no review, no comment, most probably the ASF developers
> should
> > be announced, and/or it means that the business feature presented in the
> PR
> > is not needed.
> >
> > The ASF is responsible for the changes, not the contributor.
> > It is no real situation to search the contributor on the plant and ask
> > her/him to repair the fix which will cause a new bug in the future - we
> are
> > responsible, the contributor is not.
> > So we should not wait for at least one approval.
> > We should be critical to the PRs, and if there is one -1 it means that
> the
> > PR should be open as a work in progress or it should be closed.
> >
> > There cannot be a rule "No review" -> "wait 3 days" -> "accept" because
> > this is the thing everybody would utilize to involve a trojan horse.
> >
> > T
> >
> >
> >
> > On Fri, Feb 4, 2022 at 12:12 PM Slawomir Jaranowski <
> > s.jaranow...@gmail.com>
> > wrote:
> >
> > > Hi,
> > > Example value as 3 days or other values are to discuss and can be an
> > agreed
> > > value. Now such values are not important ... it will be the last item
> to
> > > confirm.
> > >
> > > I only want to show how the process can look.
> > >
> > > Currently we only have sentence that we use "Commit then Review" policy
> > > without more details
> > >
> > > pt., 4 lut 2022 o 11:58 Xeno Amess  napisał(a):
> > >
> > > > Yes, reviewing prs is time consuming, though usually worth it.
> > > > 3 days does not seem enough for normal pr reviews I think.
> > > > If a maintainer disagrees with this and they do think they can review
> > > every
> > > > prs inside the 3 days limit, then I will be glad to show him why he
> > > can't,
> > > > just tell me what repos he maintains.
> > > > I do have the ability (and experience) in creating 100+ positively
> > > > meaningful prs per day.
> > > >
> > > >
> > > > Tibor Digana  于2022年2月4日周五 18:00写道：
> > > >
> > > > > 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
> &

Re: Commit Review Policy

[Tibor Digana]

Slawomir, we have a fundamental problem.
You want to accept PR. But I say that the purpose of PR is not to accept it
because the ASFshould be always critical and therefore I think the rules
cannot be written in terms "When to accept the PR".
There should be rules "When not to accept the PR" because we should be
critical to the PRs - that's the purpose of the existence of pull-requests.
If there is no review, no comment, most probably the ASF developers should
be announced, and/or it means that the business feature presented in the PR
is not needed.

The ASF is responsible for the changes, not the contributor.
It is no real situation to search the contributor on the plant and ask
her/him to repair the fix which will cause a new bug in the future - we are
responsible, the contributor is not.
So we should not wait for at least one approval.
We should be critical to the PRs, and if there is one -1 it means that the
PR should be open as a work in progress or it should be closed.

There cannot be a rule "No review" -> "wait 3 days" -> "accept" because
this is the thing everybody would utilize to involve a trojan horse.

T



On Fri, Feb 4, 2022 at 12:12 PM Slawomir Jaranowski 
wrote:

> Hi,
> Example value as 3 days or other values are to discuss and can be an agreed
> value. Now such values are not important ... it will be the last item to
> confirm.
>
> I only want to show how the process can look.
>
> Currently we only have sentence that we use "Commit then Review" policy
> without more details
>
> pt., 4 lut 2022 o 11:58 Xeno Amess  napisał(a):
>
> > Yes, reviewing prs is time consuming, though usually worth it.
> > 3 days does not seem enough for normal pr reviews I think.
> > If a maintainer disagrees with this and they do think they can review
> every
> > prs inside the 3 days limit, then I will be glad to show him why he
> can't,
> > just tell me what repos he maintains.
> > I do have the ability (and experience) in creating 100+ positively
> > meaningful prs per day.
> >
> >
> > Tibor Digana  于2022年2月4日周五 18:00写道：
> >
> > > 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, s

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
> > >
> >
>

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: [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=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: [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=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: 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: 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]

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: 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: 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: 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: 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]

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]

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]

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
>> > > (currently Alpha) JUnit5 

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
> >
> > 1,
>

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]

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: [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=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: [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.0292
> - 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
> > > doing the link betwe

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]

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.0291
> + 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 am
> >> building

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: [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: [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 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=12346845=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] 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: 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] 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=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: [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=12349726=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 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=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 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=12348086=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=12330781=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: 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
> > > > operate

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=12344365=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: [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=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: 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 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=12344185=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: 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: 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 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: [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=12348079=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: [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=12348358=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: 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: 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
> > > > >
> > > >
> > > >
> > > > Le me

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: [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=12350032=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: 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: [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 

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=12350003=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: 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 

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=12344858=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: [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=Text=12317922=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
>
>