Re: Problem with an Maven Build

[Tibor Digana]

Obviously, the reporting is not the only one sectipn of pom where you use
the latest version of this plugin. See your logs and the goal=test of the
plugin.
T

Dňa št 5. 5. 2022, 16:14 Nelligan, Steven M 
napísal(a):

>
> This is the only reference I have to "surefire" in my POM file.
> ...snip...
> 
> 
> 
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.9
> 
> ${jdk-source.version}
> 
> 
> 
> org.apache.maven.plugins
> maven-surefire-report-plugin
> 2.15
> 
> ...snip...
>
> I am assuming that some other dependency is pulling in
> maven-surefire-plugin.
>
> I have also tried to comment out  ...  and I still
> get the error.
>
> STEVEN M NELLIGAN
>
>
> -Original Message-
> From: Antoine Mottier 
> Sent: Thursday, May 5, 2022 9:00 AM
> To: Maven Users List 
> Subject: Re: Problem with an Maven Build
>
> Starting with version 3.0.0-M6 maven-surefire-plugin requires Java 8 or
> higher. As you are running it using Java 7 this explains your issue.
>
> You can either get back to version 3.0.0-M5 or upgrade to a newer version
> of Java.
>
> Regards,
> --
> Antoine Mottier
>
> "Nelligan, Steven M"  a écrit :
>
> > Please any assistance would be appreciated
> >
> > Building a maven project is getting the following error(s)  I have not
> > changed anything in the project, so I assume something changed in the
> > repositories
> > How can I get this project built?
> >
> > INFORMATION FOLLOWS:
> >
> > __
> > 
> > I am running maven version 3.6.3:
> >C:\dev\projects\muleextcharge>mvn -version
> > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> > Maven home: C:\Program Files\apache-maven-3.6.3\bin\..
> > Java version: 1.7.0_80, vendor: Oracle Corporation, runtime:
> > C:\Program Files\Java\jdk1.7.0_80\jre
> > Default locale: en_US, platform encoding: Cp1252
> > OS name: "windows 8.1", version: "6.3", arch: "amd64",
> > family: "windows"
> >
> > __
> >  While building I get the following error (if
> > I run maven with dependency:tree, surefire does NOT show in the tree)
> >   C:\dev\projects\muleextcharge>mvn -P vDev2 clean install -U
> > -Dmaven.test.skip=true
> >   [INFO] Scanning for projects...
> >   [INFO]
> >   [INFO] -< edu.uiuc.fs:muleextcharge
> > >--
> >   [INFO] Building Mule Muleextcharge Application 1.0.0
> >   [INFO] [ mule
> > ]
> >   Downloading from java.net-Public:
> >
> https://urldefense.com/v3/__https://maven.java.net/content/groups/public/org/apache/maven/plugins/maven-resources-plugin/maven-metadata.xml__;!!DZ3fjg!_ga88ihhLeSlWaW2vzU5ZbFjYMb664Wo9VZ01XjN_Hf9M5yIYlv1BUs_RmLQHljx3sXbektttY998yI15I6mvK5Sor5R$
> >   Downloading from central:
> >
> https://urldefense.com/v3/__https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/maven-metadata.xml__;!!DZ3fjg!_ga88ihhLeSlWaW2vzU5ZbFjYMb664Wo9VZ01XjN_Hf9M5yIYlv1BUs_RmLQHljx3sXbektttY998yI15I6mvFfzy85k$
> >   Downloaded from central:
> > https://urldefense.com/v3/__https://repo.maven.apache.org/maven2/org/a
> > pache/maven/plugins/maven-resources-plugin/maven-metadata.xml__;!!DZ3f
> > jg!_ga88ihhLeSlWaW2vzU5ZbFjYMb664Wo9VZ01XjN_Hf9M5yIYlv1BUs_RmLQHljx3sX
> > bektttY998yI15I6mvFfzy85k$  (874 B at 1.6
> > kB/s)
> >   Downloading from java.net-Public:
> >
> https://urldefense.com/v3/__https://maven.java.net/content/groups/public/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml__;!!DZ3fjg!_ga88ihhLeSlWaW2vzU5ZbFjYMb664Wo9VZ01XjN_Hf9M5yIYlv1BUs_RmLQHljx3sXbektttY998yI15I6mvPpcbd1G$
> >   Downloading from central:
> >
> https://urldefense.com/v3/__https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml__;!!DZ3fjg!_ga88ihhLeSlWaW2vzU5ZbFjYMb664Wo9VZ01XjN_Hf9M5yIYlv1BUs_RmLQHljx3sXbektttY998yI15I6mvKT-QjwK$
> >   Downloaded from central:
> > https://urldefense.com/v3/__https://repo.maven.apache.org/maven2/org/a
> > pache/maven/plugins/maven-surefire-plugin/maven-metadata.xml__;!!DZ3fj
> > g!_ga88ihhLeSlWaW2vzU5ZbFjYMb664Wo9VZ01XjN_Hf9M5yIYlv1BUs_RmLQHljx3sXb
> > ektttY998yI15I6mvKT-QjwK$  (1.9 kB at 25
> > kB/s)
> >   Downloading from central:
> >
> https://urldefense.com/v3/__https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-deploy-plugin/maven-metadata.xml__;!!DZ3fjg!_ga88ihhLeSlWaW2vzU5ZbFjYMb664Wo9VZ01XjN_Hf9M5yIYlv1BUs_RmLQHljx3sXbektttY998yI15I6mvOlEQUtO$
> >   Downloading from java.net-Public:
> >
> 

Re: Problem with an Maven Build

[Tibor Digana]

It should not be any issue if you switch to JDK8 and add maven sniffer
plugin along with compiler 1.7.
T

Dňa št 5. 5. 2022, 16:00 Antoine Mottier 
napísal(a):

> Starting with version 3.0.0-M6 maven-surefire-plugin requires Java 8
> or higher. As you are running it using Java 7 this explains your issue.
>
> You can either get back to version 3.0.0-M5 or upgrade to a newer
> version of Java.
>
> Regards,
> --
> Antoine Mottier
>
> "Nelligan, Steven M"  a écrit :
>
> > Please any assistance would be appreciated
> >
> > Building a maven project is getting the following error(s)
> >  I have not changed anything in the project, so I assume something
> > changed in the repositories
> > How can I get this project built?
> >
> > INFORMATION FOLLOWS:
> >
> >
> __
> > I am running maven version 3.6.3:
> >C:\dev\projects\muleextcharge>mvn -version
> > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> > Maven home: C:\Program Files\apache-maven-3.6.3\bin\..
> > Java version: 1.7.0_80, vendor: Oracle Corporation, runtime:
> > C:\Program Files\Java\jdk1.7.0_80\jre
> > Default locale: en_US, platform encoding: Cp1252
> > OS name: "windows 8.1", version: "6.3", arch: "amd64",
> > family: "windows"
> >
> >
> __
> > While building I get the following error (if I run maven with
> > dependency:tree, surefire does NOT show in the tree)
> >   C:\dev\projects\muleextcharge>mvn -P vDev2 clean install -U
> > -Dmaven.test.skip=true
> >   [INFO] Scanning for projects...
> >   [INFO]
> >   [INFO] -< edu.uiuc.fs:muleextcharge
> > >--
> >   [INFO] Building Mule Muleextcharge Application 1.0.0
> >   [INFO] [ mule
> > ]
> >   Downloading from java.net-Public:
> >
> https://maven.java.net/content/groups/public/org/apache/maven/plugins/maven-resources-plugin/maven-metadata.xml
> >   Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/maven-metadata.xml
> >   Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/maven-metadata.xml
> (874 B at 1.6
> > kB/s)
> >   Downloading from java.net-Public:
> >
> https://maven.java.net/content/groups/public/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml
> >   Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml
> >   Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml
> (1.9 kB at 25
> > kB/s)
> >   Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-deploy-plugin/maven-metadata.xml
> >   Downloading from java.net-Public:
> >
> https://maven.java.net/content/groups/public/org/apache/maven/plugins/maven-deploy-plugin/maven-metadata.xml
> >   Downloaded from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-deploy-plugin/maven-metadata.xml
> (783 B at 14
> > kB/s)
> >   [INFO]
> >   [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
> muleextcharge ---
> >   [INFO] Deleting C:\dev\projects\muleextcharge\target
> >   [INFO]
> >   [INFO] --- maven-mule-plugin:1.9:attach-test-resources
> > (default-attach-test-resources) @ muleextcharge ---
> >   [INFO] attaching test resource
> C:\dev\projects\muleextcharge\src\main\app
> >   [INFO]
> >   [INFO] --- maven-resources-plugin:3.2.0:resources
> > (default-resources) @ muleextcharge ---
> >   [INFO] Using 'Cp1252' encoding to copy filtered resources.
> >   [INFO] Using 'Cp1252' encoding to copy filtered properties files.
> >   [INFO] Copying 0 resource
> >   [INFO]
> >   [INFO] --- maven-mule-plugin:1.9:filter-resources
> > (default-filter-resources) @ muleextcharge ---
> >   [INFO]
> >   [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> > muleextcharge ---
> >   [INFO] Nothing to compile - all classes are up to date
> >   [INFO]
> >   [INFO] --- maven-resources-plugin:3.2.0:testResources
> > (default-testResources) @ muleextcharge ---
> >   [INFO] Not copying test resources
> >   [INFO]
> >   [INFO] --- maven-compiler-plugin:3.1:testCompile
> > (default-testCompile) @ muleextcharge ---
> >   [INFO] Not compiling test sources
> >   [INFO]
> >   [INFO] --- maven-surefire-plugin:3.0.0-M6:test (default-test) @
> > muleextcharge ---
> >   [WARNING] Error injecting:
> org.apache.maven.plugin.surefire.SurefirePlugin
> >   

[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: Can't get Surefire to run any JUnit 5 tests

[Tibor Digana]

David, for you the most important value is to see the POM of the IT.
I guess you have the dependencies, configuration with the  framework
we have in the IT.
We have one successful test which is the test behind the suite, we have
verified what test and suite and provider run.

T

On Mon, Mar 21, 2022 at 12:52 AM KARR, DAVID  wrote:

> I think I'll have to take your word for it.  I don’t know anything about
> your build or runtime architecture to comment.  I only found one change
> that looked like an actual business logic change, relating to adding the
> wildcard filter to the TestListResolver, but I don't know what that means.
> I'll be glad to test it when it's put into a released version.
>
> Is there any thought as to when this will go into a full release, instead
> of M releases?
>
> > -Original Message-
> > From: Tibor Digana 
> > Sent: Sunday, March 20, 2022 4:32 PM
> > To: Maven Users List 
> > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> >
> > The principles in junit providers are +/- the same, or they should be.
> > So it was easy to find the difference and make the fix!
> >
> > T
> >
> > On Mon, Mar 21, 2022 at 12:25 AM Tibor Digana 
> > wrote:
> >
> > > Hey David,
> > >
> > > Here is the PR.
> > > You can see the integration test of documentation with the principles.
> > > Pls find it and let me know you like it, feel free to put +1 in your
> > comment.
> > > https://urldefense.com/v3/__https://github.com/apache/maven-surefire/p
> > > ull/494__;!!BhdT!lFqcUUy0111TgmVTkjtCGYx0nVsQnYDTocJ9YXlK-lioUt5rbtuGB
> > > _V1sLb284E5LAqrLQkEGXLu3FQAemKi$ As I said in JIRA, the combination of
> > > JUnit4 and JUnit5 is not the problem. The problem is that we
> > > implemented the JUnit5 Surefire Provider with a bug. We always operate
> > > with TestListResolver the same way in all surefire providers but in
> > > this one. It was our fault, and not the principals are the same in
> > > providers and so there is no difference regarding the principles.
> > > That's the reason why I showed you the example with JUnit4 because I
> > > had some suspicions in the code and it was confirmed by running the
> > > tests and debugging the code.
> > >
> > > Cheers
> > > Tibor
> > >
> > >
> > > On Sun, Mar 20, 2022 at 8:23 PM KARR, DAVID  wrote:
> > >
> > >> Here's my ticket:
> > https://urldefense.com/v3/__https://issues.apache.org/jira/browse/SUREFI
> > RE-2040__;!!BhdT!lFqcUUy0111TgmVTkjtCGYx0nVsQnYDTocJ9YXlK-
> > lioUt5rbtuGB_V1sLb284E5LAqrLQkEGXLu3BaYyUTU$  .
> > >>
> > >> > -Original Message-
> > >> > From: Tibor Digana 
> > >> > Sent: Sunday, March 20, 2022 12:03 PM
> > >> > To: Maven Users List 
> > >> > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> > >> >
> > >> > Hello David,
> > >> >
> > >> > I have an internal fix, zou won't be able to have it today. :-) But
> > >> > if you have created the Jira ticket for us, we would make sure we
> > >> > are on the right way.
> > >> >
> > >> > This is my suite class with JUnit5, just a principle (there might
> > >> > be more children classes of course), and I use the command *mvn
> > >> > test -
> > >> > Dtest=MyTestSuite* I hope I am on the right track.
> > >> >
> > >> > package pkg;
> > >> >
> > >> > import org.junit.platform.suite.api.SelectClasses;
> > >> > import org.junit.platform.suite.api.Suite;
> > >> >
> > >> > @Suite
> > >> > @SelectClasses(BDSHelperTest.class)
> > >> > public class MyTestSuite {
> > >> > }
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Sun, Mar 20, 2022 at 6:25 PM KARR, DAVID  wrote:
> > >> >
> > >> > > > -Original Message-
> > >> > > > From: Tibor Digana 
> > >> > > > Sent: Sunday, March 20, 2022 6:42 AM
> > >> > > > To: Maven Users List 
> > >> > > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> > >> > > >
> > >> > > > There was the same question maybe one week ago.
> > >> > > > I have created an example with JUnit4, see the next, and used
> > >> &g

Re: Can't get Surefire to run any JUnit 5 tests

[Tibor Digana]

The principles in junit providers are +/- the same, or they should be. So
it was easy to find the difference and make the fix!

T

On Mon, Mar 21, 2022 at 12:25 AM Tibor Digana 
wrote:

> Hey David,
>
> Here is the PR.
> You can see the integration test of documentation with the principles. Pls
> find it and let me know you like it, feel free to put +1 in your comment.
> https://github.com/apache/maven-surefire/pull/494
> As I said in JIRA, the combination of JUnit4 and JUnit5 is not the
> problem. The problem is that we implemented the JUnit5 Surefire Provider
> with a bug. We always operate with TestListResolver the same way in all
> surefire providers but in this one. It was our fault, and not the
> principals are the same in providers and so there is no difference
> regarding the principles. That's the reason why I showed you the example
> with JUnit4 because I had some suspicions in the code and it was confirmed
> by running the tests and debugging the code.
>
> Cheers
> Tibor
>
>
> On Sun, Mar 20, 2022 at 8:23 PM KARR, DAVID  wrote:
>
>> Here's my ticket: https://issues.apache.org/jira/browse/SUREFIRE-2040 .
>>
>> > -Original Message-
>> > From: Tibor Digana 
>> > Sent: Sunday, March 20, 2022 12:03 PM
>> > To: Maven Users List 
>> > Subject: Re: Can't get Surefire to run any JUnit 5 tests
>> >
>> > Hello David,
>> >
>> > I have an internal fix, zou won't be able to have it today. :-) But if
>> > you have created the Jira ticket for us, we would make sure we are on
>> > the right way.
>> >
>> > This is my suite class with JUnit5, just a principle (there might be
>> > more children classes of course), and I use the command *mvn test -
>> > Dtest=MyTestSuite* I hope I am on the right track.
>> >
>> > package pkg;
>> >
>> > import org.junit.platform.suite.api.SelectClasses;
>> > import org.junit.platform.suite.api.Suite;
>> >
>> > @Suite
>> > @SelectClasses(BDSHelperTest.class)
>> > public class MyTestSuite {
>> > }
>> >
>> >
>> >
>> >
>> >
>> > On Sun, Mar 20, 2022 at 6:25 PM KARR, DAVID  wrote:
>> >
>> > > > -Original Message-
>> > > > From: Tibor Digana 
>> > > > Sent: Sunday, March 20, 2022 6:42 AM
>> > > > To: Maven Users List 
>> > > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
>> > > >
>> > > > There was the same question maybe one week ago.
>> > > > I have created an example with JUnit4, see the next, and used the
>> > > > configuration parameter ComponentTestSuite where the
>> > > > command naturally works:
>> > > >
>> > > > mvn -Dtest=ComponentTestSuite test
>> > > >
>> > > > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
>> > elapsed:
>> > > > 0.14 s - in pkg.ComponentTestSuite
>> > > >
>> > > > After my fix this should work in JUnit5 provider. I have pushed a
>> > > > test project with JUnit5 Suite, activate it via profile "suite", see
>> > > >
>> https://urldefense.com/v3/__https://github.com/Tibor17/junit5-mockit
>> > > > o-
>> > > > examples/commit/c87038b8154ae908ff50bd84e19776dfbddbe779__;!!BhdT!i5
>> > > > Qv7K
>> > > > rfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBuQ2Td7B4-
>> > > > _p53T9zXVk_Dp0MniLHv6riNYEbn9UVw$
>> > > >
>> > > > If there is a Jira ticket pls let me know and I will open a PR on
>> > > > our GH.
>> > >
>> > > Thanks for the variations, I only care about the solution that moves
>> > > forward with Junit5.
>> > >
>> > > You refer to a fix.  Is that something you've put into version
>> > > 3.0.0-M6-SNAPSHOT that I would need for this to work?  I am attempting
>> > > to get that version, but I'm having trouble configuring my
>> > > settings.xml to get this to retrieve from the public repo. We engineer
>> > > things so that all artifacts are retrieved from our internal artifact
>> > > repository, which mirrors the public one.  If I need to, I will
>> > > continue trying to figure that out.
>> > >
>> > > I have a feeling you're saying that with Junit5, you were unable to
>> > > get to the point where you could specify a single test, being a test
>> > > suite, on the

Re: Can't get Surefire to run any JUnit 5 tests

[Tibor Digana]

Hey David,

Here is the PR.
You can see the integration test of documentation with the principles. Pls
find it and let me know you like it, feel free to put +1 in your comment.
https://github.com/apache/maven-surefire/pull/494
As I said in JIRA, the combination of JUnit4 and JUnit5 is not the problem.
The problem is that we implemented the JUnit5 Surefire Provider with a bug.
We always operate with TestListResolver the same way in all surefire
providers but in this one. It was our fault, and not the principals are the
same in providers and so there is no difference regarding the principles.
That's the reason why I showed you the example with JUnit4 because I had
some suspicions in the code and it was confirmed by running the tests and
debugging the code.

Cheers
Tibor


On Sun, Mar 20, 2022 at 8:23 PM KARR, DAVID  wrote:

> Here's my ticket: https://issues.apache.org/jira/browse/SUREFIRE-2040 .
>
> > -Original Message-
> > From: Tibor Digana 
> > Sent: Sunday, March 20, 2022 12:03 PM
> > To: Maven Users List 
> > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> >
> > Hello David,
> >
> > I have an internal fix, zou won't be able to have it today. :-) But if
> > you have created the Jira ticket for us, we would make sure we are on
> > the right way.
> >
> > This is my suite class with JUnit5, just a principle (there might be
> > more children classes of course), and I use the command *mvn test -
> > Dtest=MyTestSuite* I hope I am on the right track.
> >
> > package pkg;
> >
> > import org.junit.platform.suite.api.SelectClasses;
> > import org.junit.platform.suite.api.Suite;
> >
> > @Suite
> > @SelectClasses(BDSHelperTest.class)
> > public class MyTestSuite {
> > }
> >
> >
> >
> >
> >
> > On Sun, Mar 20, 2022 at 6:25 PM KARR, DAVID  wrote:
> >
> > > > -Original Message-
> > > > From: Tibor Digana 
> > > > Sent: Sunday, March 20, 2022 6:42 AM
> > > > To: Maven Users List 
> > > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> > > >
> > > > There was the same question maybe one week ago.
> > > > I have created an example with JUnit4, see the next, and used the
> > > > configuration parameter ComponentTestSuite where the
> > > > command naturally works:
> > > >
> > > > mvn -Dtest=ComponentTestSuite test
> > > >
> > > > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
> > elapsed:
> > > > 0.14 s - in pkg.ComponentTestSuite
> > > >
> > > > After my fix this should work in JUnit5 provider. I have pushed a
> > > > test project with JUnit5 Suite, activate it via profile "suite", see
> > > > https://urldefense.com/v3/__https://github.com/Tibor17/junit5-mockit
> > > > o-
> > > > examples/commit/c87038b8154ae908ff50bd84e19776dfbddbe779__;!!BhdT!i5
> > > > Qv7K
> > > > rfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBuQ2Td7B4-
> > > > _p53T9zXVk_Dp0MniLHv6riNYEbn9UVw$
> > > >
> > > > If there is a Jira ticket pls let me know and I will open a PR on
> > > > our GH.
> > >
> > > Thanks for the variations, I only care about the solution that moves
> > > forward with Junit5.
> > >
> > > You refer to a fix.  Is that something you've put into version
> > > 3.0.0-M6-SNAPSHOT that I would need for this to work?  I am attempting
> > > to get that version, but I'm having trouble configuring my
> > > settings.xml to get this to retrieve from the public repo. We engineer
> > > things so that all artifacts are retrieved from our internal artifact
> > > repository, which mirrors the public one.  If I need to, I will
> > > continue trying to figure that out.
> > >
> > > I have a feeling you're saying that with Junit5, you were unable to
> > > get to the point where you could specify a single test, being a test
> > > suite, on the command line, which I believe is why you asked if there
> > > is a JIRA ticket for this.  If you confirm that, I will create that
> > ticket.
> > >
> > > I see what you're doing with profiles.  For what we're trying to do
> > > here, I can see that this could at least be a functional 1-1
> > > replacement for specifying a single test on the command line, but I'd
> > > prefer not having to change how we do this, if possible.
> > >
> > > > On Sun, Mar 20, 2022 at 1:46 AM David Karr
> > > > 
> > > >

Re: Can't get Surefire to run any JUnit 5 tests

[Tibor Digana]

Thx David, I will ping you with a pull request on Github soon.
Cheers
Tibor

On Sun, Mar 20, 2022 at 8:23 PM KARR, DAVID  wrote:

> Here's my ticket: https://issues.apache.org/jira/browse/SUREFIRE-2040 .
>
> > -Original Message-
> > From: Tibor Digana 
> > Sent: Sunday, March 20, 2022 12:03 PM
> > To: Maven Users List 
> > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> >
> > Hello David,
> >
> > I have an internal fix, zou won't be able to have it today. :-) But if
> > you have created the Jira ticket for us, we would make sure we are on
> > the right way.
> >
> > This is my suite class with JUnit5, just a principle (there might be
> > more children classes of course), and I use the command *mvn test -
> > Dtest=MyTestSuite* I hope I am on the right track.
> >
> > package pkg;
> >
> > import org.junit.platform.suite.api.SelectClasses;
> > import org.junit.platform.suite.api.Suite;
> >
> > @Suite
> > @SelectClasses(BDSHelperTest.class)
> > public class MyTestSuite {
> > }
> >
> >
> >
> >
> >
> > On Sun, Mar 20, 2022 at 6:25 PM KARR, DAVID  wrote:
> >
> > > > -Original Message-
> > > > From: Tibor Digana 
> > > > Sent: Sunday, March 20, 2022 6:42 AM
> > > > To: Maven Users List 
> > > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> > > >
> > > > There was the same question maybe one week ago.
> > > > I have created an example with JUnit4, see the next, and used the
> > > > configuration parameter ComponentTestSuite where the
> > > > command naturally works:
> > > >
> > > > mvn -Dtest=ComponentTestSuite test
> > > >
> > > > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
> > elapsed:
> > > > 0.14 s - in pkg.ComponentTestSuite
> > > >
> > > > After my fix this should work in JUnit5 provider. I have pushed a
> > > > test project with JUnit5 Suite, activate it via profile "suite", see
> > > > https://urldefense.com/v3/__https://github.com/Tibor17/junit5-mockit
> > > > o-
> > > > examples/commit/c87038b8154ae908ff50bd84e19776dfbddbe779__;!!BhdT!i5
> > > > Qv7K
> > > > rfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBuQ2Td7B4-
> > > > _p53T9zXVk_Dp0MniLHv6riNYEbn9UVw$
> > > >
> > > > If there is a Jira ticket pls let me know and I will open a PR on
> > > > our GH.
> > >
> > > Thanks for the variations, I only care about the solution that moves
> > > forward with Junit5.
> > >
> > > You refer to a fix.  Is that something you've put into version
> > > 3.0.0-M6-SNAPSHOT that I would need for this to work?  I am attempting
> > > to get that version, but I'm having trouble configuring my
> > > settings.xml to get this to retrieve from the public repo. We engineer
> > > things so that all artifacts are retrieved from our internal artifact
> > > repository, which mirrors the public one.  If I need to, I will
> > > continue trying to figure that out.
> > >
> > > I have a feeling you're saying that with Junit5, you were unable to
> > > get to the point where you could specify a single test, being a test
> > > suite, on the command line, which I believe is why you asked if there
> > > is a JIRA ticket for this.  If you confirm that, I will create that
> > ticket.
> > >
> > > I see what you're doing with profiles.  For what we're trying to do
> > > here, I can see that this could at least be a functional 1-1
> > > replacement for specifying a single test on the command line, but I'd
> > > prefer not having to change how we do this, if possible.
> > >
> > > > On Sun, Mar 20, 2022 at 1:46 AM David Karr
> > > > 
> > > > wrote:
> > > >
> > > > > On Sat, Mar 19, 2022 at 5:06 PM Tibor Digana
> > > > > 
> > > > > wrote:
> > > > >
> > > > > > My advice is not to listen to everyone but rather understand how
> > > > > > things work.
> > > > > > Open this link in your browser
> > > > > > https://urldefense.com/v3/__https://repo1.maven.org/maven2/org/j
> > > > > > unit
> > > > > > /platform/__;!!BhdT!i5Qv7KrfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBu
> > > > > > Q2Td 7B4-_p53T9zXVk_Dp0MniLHv6riNYCbWzIuY$
> > > >

Re: Can't get Surefire to run any JUnit 5 tests

[Tibor Digana]

Hello David,

I have an internal fix, zou won't be able to have it today. :-)
But if you have created the Jira ticket for us, we would make sure we are
on the right way.

This is my suite class with JUnit5, just a principle (there might be more
children classes of course), and I use the command
*mvn test -Dtest=MyTestSuite*
I hope I am on the right track.

package pkg;

import org.junit.platform.suite.api.SelectClasses;
import org.junit.platform.suite.api.Suite;

@Suite
@SelectClasses(BDSHelperTest.class)
public class MyTestSuite {
}





On Sun, Mar 20, 2022 at 6:25 PM KARR, DAVID  wrote:

> > -Original Message-
> > From: Tibor Digana 
> > Sent: Sunday, March 20, 2022 6:42 AM
> > To: Maven Users List 
> > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> >
> > There was the same question maybe one week ago.
> > I have created an example with JUnit4, see the next, and used the
> > configuration parameter ComponentTestSuite where the
> > command naturally works:
> >
> > mvn -Dtest=ComponentTestSuite test
> >
> > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> > 0.14 s - in pkg.ComponentTestSuite
> >
> > After my fix this should work in JUnit5 provider. I have pushed a test
> > project with JUnit5 Suite, activate it via profile "suite", see
> > https://urldefense.com/v3/__https://github.com/Tibor17/junit5-mockito-
> > examples/commit/c87038b8154ae908ff50bd84e19776dfbddbe779__;!!BhdT!i5Qv7K
> > rfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBuQ2Td7B4-
> > _p53T9zXVk_Dp0MniLHv6riNYEbn9UVw$
> >
> > If there is a Jira ticket pls let me know and I will open a PR on our
> > GH.
>
> Thanks for the variations, I only care about the solution that moves
> forward with Junit5.
>
> You refer to a fix.  Is that something you've put into version
> 3.0.0-M6-SNAPSHOT that I would need for this to work?  I am attempting to
> get that version, but I'm having trouble configuring my settings.xml to get
> this to retrieve from the public repo. We engineer things so that all
> artifacts are retrieved from our internal artifact repository, which
> mirrors the public one.  If I need to, I will continue trying to figure
> that out.
>
> I have a feeling you're saying that with Junit5, you were unable to get to
> the point where you could specify a single test, being a test suite, on the
> command line, which I believe is why you asked if there is a JIRA ticket
> for this.  If you confirm that, I will create that ticket.
>
> I see what you're doing with profiles.  For what we're trying to do here,
> I can see that this could at least be a functional 1-1 replacement for
> specifying a single test on the command line, but I'd prefer not having to
> change how we do this, if possible.
>
> > On Sun, Mar 20, 2022 at 1:46 AM David Karr 
> > wrote:
> >
> > > On Sat, Mar 19, 2022 at 5:06 PM Tibor Digana 
> > > wrote:
> > >
> > > > My advice is not to listen to everyone but rather understand how
> > > > things work.
> > > > Open this link in your browser
> > > > https://urldefense.com/v3/__https://repo1.maven.org/maven2/org/junit
> > > > /platform/__;!!BhdT!i5Qv7KrfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBuQ2Td
> > > > 7B4-_p53T9zXVk_Dp0MniLHv6riNYCbWzIuY$
> > > > It is groupId of some JUnit5 artifacts.
> > > > Do you see junit-platform-suite-api?
> > > > Scroll up and you will see junit-platform-suite. What's that? It's
> > > > the
> > > impl
> > > > of the api.
> > > > So, now you know what you miss in the dependencies.
> > > >
> > > > This way just discover the entire hierarchy in
> > > > https://urldefense.com/v3/__https://repo1.maven.org/maven2/org/junit
> > > > /__;!!BhdT!i5Qv7KrfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBuQ2Td7B4-
> > _p53T9zXVk_Dp0MniLHv6riNYGRYa8RR$  and the POMs and their dependencies
> > and transitive dependencies.
> > > > Then you would understand most of the typical troubles.
> > > > No magic, the trick is to read the content of the repo and the
> > > > content of POMs.
> > > >
> > > > I always have to do this when I am helping the users. All the time.
> > > > The job starts with this if it is a simple problem. Always the same,
> > > > all the time.
> > > >
> > >
> > > Ok, I appreciate that. However, perhaps I didn't emphasize the correct
> > > thing in my last response. Fixing the compile error was simple to do.
> > > The last problem I have is the problem with running a comp

Re: Can't get Surefire to run any JUnit 5 tests

[Tibor Digana]

There was the same question maybe one week ago.
I have created an example with JUnit4, see the next, and used the
configuration parameter ComponentTestSuite where the command
naturally works:

mvn -Dtest=ComponentTestSuite test

[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.14
s - in pkg.ComponentTestSuite

After my fix this should work in JUnit5 provider. I have pushed a test
project with JUnit5 Suite, activate it via profile "suite", see
https://github.com/Tibor17/junit5-mockito-examples/commit/c87038b8154ae908ff50bd84e19776dfbddbe779

If there is a Jira ticket pls let me know and I will open a PR on our GH.

This is the example with JUnit4:

http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0
  org.apache.maven
  junit4-test-suite
  1.0-SNAPSHOT

1.8
UTF-8
  
  
  
  junit
  junit
  4.13.2
  test
  
  
  
 
   
 org.apache.maven.plugins
 maven-compiler-plugin
 3.10.1
   
   
  org.apache.maven.plugins
   maven-surefire-plugin
   3.0.0-M5
   
   ComponentTestSuite
   
   
 
   




package pkg;

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(Suite.class)
@SuiteClasses(MyTest.class)
public class ComponentTestSuite {
}



package pkg;

import org.junit.Test;

public class MyTest {
@Test
public void test() {}
}



On Sun, Mar 20, 2022 at 1:46 AM David Karr 
wrote:

> On Sat, Mar 19, 2022 at 5:06 PM Tibor Digana 
> wrote:
>
> > My advice is not to listen to everyone but rather understand how things
> > work.
> > Open this link in your browser
> > https://repo1.maven.org/maven2/org/junit/platform/
> > It is groupId of some JUnit5 artifacts.
> > Do you see junit-platform-suite-api?
> > Scroll up and you will see junit-platform-suite. What's that? It's the
> impl
> > of the api.
> > So, now you know what you miss in the dependencies.
> >
> > This way just discover the entire hierarchy in
> > https://repo1.maven.org/maven2/org/junit/ and the POMs and their
> > dependencies and transitive dependencies.
> > Then you would understand most of the typical troubles.
> > No magic, the trick is to read the content of the repo and the content of
> > POMs.
> >
> > I always have to do this when I am helping the users. All the time.
> > The job starts with this if it is a simple problem. Always the same, all
> > the time.
> >
>
> Ok, I appreciate that. However, perhaps I didn't emphasize the correct
> thing in my last response. Fixing the compile error was simple to do.  The
> last problem I have is the problem with running a component test suite from
> the command line. This is actually the first problem I was made aware of
> when I first started examining this entire functional area.
>
>
> > T
> >
> >
> >
> >
> > On Sat, Mar 19, 2022 at 10:57 PM KARR, DAVID  wrote:
> >
> > > This is progress.  I at least now see both Junit 5 and Junit 4 tests
> > > running successfully.
> > >
> > > I have a couple of related questions, one of which is likely entirely
> > > Junit-related, but which you might have run into, and the other is more
> > on
> > > Surefire.
> > >
> > > We also have some test suites, which is where we base our "component"
> and
> > > "integration" tests, neither of which run as unit tests.  I'm focusing
> in
> > > the component tests first, but I think whatever we do to fix the
> > component
> > > tests will be the same for the integration tests.
> > >
> > > With the dependencies you specified, that results in compile errors for
> > > missing classes in "org.junit.platform.suite.api.*".  That is in the
> > > "junit-platform-suite-api" dependency.  It's simple enough to include
> > that
> > > dependency, and that resolves that compile error.  I assume that's the
> > best
> > > resolution for that?
> > >
> > > Finally, the issue that is actually one of the first trouble spots we
> > > noticed, which is being able to execute test suites from the mvn
> command
> > > line.
> > >
> > > With Junit4, we would execute our component tests with just this:
> > >
> > > mvn -Dtest=Co

Re: Can't get Surefire to run any JUnit 5 tests

[Tibor Digana]

My advice is not to listen to everyone but rather understand how things
work.
Open this link in your browser
https://repo1.maven.org/maven2/org/junit/platform/
It is groupId of some JUnit5 artifacts.
Do you see junit-platform-suite-api?
Scroll up and you will see junit-platform-suite. What's that? It's the impl
of the api.
So, now you know what you miss in the dependencies.

This way just discover the entire hierarchy in
https://repo1.maven.org/maven2/org/junit/ and the POMs and their
dependencies and transitive dependencies.
Then you would understand most of the typical troubles.
No magic, the trick is to read the content of the repo and the content of
POMs.

I always have to do this when I am helping the users. All the time.
The job starts with this if it is a simple problem. Always the same, all
the time.

T




On Sat, Mar 19, 2022 at 10:57 PM KARR, DAVID  wrote:

> This is progress.  I at least now see both Junit 5 and Junit 4 tests
> running successfully.
>
> I have a couple of related questions, one of which is likely entirely
> Junit-related, but which you might have run into, and the other is more on
> Surefire.
>
> We also have some test suites, which is where we base our "component" and
> "integration" tests, neither of which run as unit tests.  I'm focusing in
> the component tests first, but I think whatever we do to fix the component
> tests will be the same for the integration tests.
>
> With the dependencies you specified, that results in compile errors for
> missing classes in "org.junit.platform.suite.api.*".  That is in the
> "junit-platform-suite-api" dependency.  It's simple enough to include that
> dependency, and that resolves that compile error.  I assume that's the best
> resolution for that?
>
> Finally, the issue that is actually one of the first trouble spots we
> noticed, which is being able to execute test suites from the mvn command
> line.
>
> With Junit4, we would execute our component tests with just this:
>
> mvn -Dtest=ComponentTestSuite test
>
> With these new frameworks, this fails with "No tests were executed". I've
> tried numerous variations of this.
>
> The minimal class I have is this:
>
> import org.junit.platform.suite.api.SelectClasses;
> import org.junit.platform.suite.api.Suite;
>
> @Suite
> @SelectClasses(NoteResourceCT.class)
> public class ComponentTestSuite {
> }
>
> I have heard some mentions of "Tags" in Junit5 and "groups" in Surefire.
> I have experimented with those, but I still haven't gotten anything to work.
>
> > -Original Message-
> > From: Tibor Digana 
> > Sent: Saturday, March 19, 2022 1:55 PM
> > To: Maven Users List 
> > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> >
> > No problem, pls see the project again, there is an update.
> > T
> >
> > On Sat, Mar 19, 2022 at 9:32 PM KARR, DAVID  wrote:
> >
> > > One thing that I see I neglected to mention in this post, but which I
> > > did mention in the SO posting I linked to, is that I have both Junit5
> > > and
> > > Junit4 tests in scope.  I believe that is at least one element that
> > > makes this more complicated.
> > >
> > > > -Original Message-
> > > > From: Tibor Digana 
> > > > Sent: Saturday, March 19, 2022 1:27 PM
> > > > To: Maven Users List 
> > > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> > > >
> > > > I have created a project which proves that it works with Surefire
> > > > 3.0.0- M5, JUnit Jupiter 5.8.2 and Mockito Extension. Please do not
> > > > use JUnit4 and Vintage in this case. It is not necessary to use a
> > > > dependency inside of the plugin. Use a dependency in the project
> > POM. Follow it on Github:
> > > > https://urldefense.com/v3/__https://github.com/Tibor17/junit5-mockit
> > > > o-
> > > > examples__;!!BhdT!lvmbYgzuQOyWUX5ZylkdmfaU3sXf2apqjJSFSSrxKI8axKgcOo
> > > > SucV
> > > > scEb7A3q4WNmPmuxJZAl1LWz6LutPn$
> > > >
> > > > [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @
> > > > why-is- surefire-not-executing-my-junit5-tests --- [INFO] [INFO]
> > > > ---
> > > > 
> > > > [INFO]  T E S T S
> > > > [INFO] ---
> > > > [INFO] Running pkg.BDSHelperTest
> > > > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
> > elapsed:
> > 

Re: Can't get Surefire to run any JUnit 5 tests

[Tibor Digana]

No, pls do not use the snapshot, there is no reason.
The project works as follows:

http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xmlns:Xlint="http://www.w3.org/2001/XMLSchema;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

com.stackoverflow
why-is-surefire-not-executing-my-junit5-tests
1.0-SNAPSHOT


1.8
UTF-8



org.mockito
mockito-junit-jupiter
4.4.0
test


junit
junit
4.13.2
test





org.apache.maven.plugins
maven-compiler-plugin
3.10.1


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






On Sat, Mar 19, 2022 at 9:52 PM Dan Tran  wrote:

> the latest snapshot is at repository.apache.org/content/groups/snapshots
>
> or use 3.0.0-M4 instead
>
> -D
>
> On Sat, Mar 19, 2022 at 1:32 PM KARR, DAVID  wrote:
>
> > One thing that I see I neglected to mention in this post, but which I did
> > mention in the SO posting I linked to, is that I have both Junit5 and
> > Junit4 tests in scope.  I believe that is at least one element that makes
> > this more complicated.
> >
> > > -Original Message-
> > > From: Tibor Digana 
> > > Sent: Saturday, March 19, 2022 1:27 PM
> > > To: Maven Users List 
> > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> > >
> > > I have created a project which proves that it works with Surefire
> 3.0.0-
> > > M5, JUnit Jupiter 5.8.2 and Mockito Extension. Please do not use JUnit4
> > > and Vintage in this case. It is not necessary to use a dependency
> inside
> > > of the plugin. Use a dependency in the project POM. Follow it on
> Github:
> > > https://urldefense.com/v3/__https://github.com/Tibor17/junit5-mockito-
> > >
> examples__;!!BhdT!lvmbYgzuQOyWUX5ZylkdmfaU3sXf2apqjJSFSSrxKI8axKgcOoSucV
> > > scEb7A3q4WNmPmuxJZAl1LWz6LutPn$
> > >
> > > [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @ why-is-
> > > surefire-not-executing-my-junit5-tests --- [INFO] [INFO]
> ---
> > > 
> > > [INFO]  T E S T S
> > > [INFO] ---
> > > [INFO] Running pkg.BDSHelperTest
> > > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> > > 0.396 s - in pkg.BDSHelperTest
> > > [INFO]
> > > [INFO] Results:
> > > [INFO]
> > > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO]
> > >
> 
> > > [INFO] BUILD SUCCESS
> > > [INFO]
> > >
> 
> > > [INFO] Total time:  6.417 s
> > > [INFO] Finished at: 2022-03-19T21:15:10+01:00 [INFO]
> > >
> 
> > >
> > >
> > > The XML test report:
> > > 
> > >
> > >
> > > Cheers
> > > Tibor
> > >
> > >
> > > On Sat, Mar 19, 2022 at 6:53 AM David Karr  >
> > > wrote:
> > >
> > > > I, along with two other people on my team, have spent days and days
> > > > now trying to figure out why we cannot get Surefire to execute JUnit
> 5
> > > tests.
> > > > We've all been working independently, so we don't all take the same
> > > > path, but it didn't really matter, as all three of us are pretty much
> > > > stuck at the same point.  We can execute JUnit 5 tests in Eclipse,
> but
> > > > Surefire just refuses to have anything to do with JUnit 5 tests.
> > > > We've all read numerous threads and posts on how to do it, and it
> just
> > > does not work.
> > > >
> > > > Most recently, I posted this question with some details of what I had
> > > > done so far:
> > > >
> > > >
> https://urldefense.com/v3/__https://stackoverflow.com/questions/715310
> > > >
> 01/why-is-surefire-not-executing-my-junit5-tests__;!!BhdT!lvmbYgzuQOyW
> > > >
> UX5ZylkdmfaU3sXf2apqjJSFSSrxKI8axKgcOoSucVscEb7A3q4WNmPmuxJZAl1LW5tYnJ
> > > > oJ$
> > > > .
> > > >
> > > > I have no idea whether the problems lie in JUnit 5, or in Surefire,
> or
> > > > some combination.  I wish I could get some debug output that told me
> > > SOMETHING.
> > > > It just does not run JUnit 5 tests.
> > > >
> >
>

Re: Can't get Surefire to run any JUnit 5 tests

[Tibor Digana]

No problem, pls see the project again, there is an update.
T

On Sat, Mar 19, 2022 at 9:32 PM KARR, DAVID  wrote:

> One thing that I see I neglected to mention in this post, but which I did
> mention in the SO posting I linked to, is that I have both Junit5 and
> Junit4 tests in scope.  I believe that is at least one element that makes
> this more complicated.
>
> > -Original Message-
> > From: Tibor Digana 
> > Sent: Saturday, March 19, 2022 1:27 PM
> > To: Maven Users List 
> > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> >
> > I have created a project which proves that it works with Surefire 3.0.0-
> > M5, JUnit Jupiter 5.8.2 and Mockito Extension. Please do not use JUnit4
> > and Vintage in this case. It is not necessary to use a dependency inside
> > of the plugin. Use a dependency in the project POM. Follow it on Github:
> > https://urldefense.com/v3/__https://github.com/Tibor17/junit5-mockito-
> > examples__;!!BhdT!lvmbYgzuQOyWUX5ZylkdmfaU3sXf2apqjJSFSSrxKI8axKgcOoSucV
> > scEb7A3q4WNmPmuxJZAl1LWz6LutPn$
> >
> > [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @ why-is-
> > surefire-not-executing-my-junit5-tests --- [INFO] [INFO] ---
> > 
> > [INFO]  T E S T S
> > [INFO] ---
> > [INFO] Running pkg.BDSHelperTest
> > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> > 0.396 s - in pkg.BDSHelperTest
> > [INFO]
> > [INFO] Results:
> > [INFO]
> > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO]
> > 
> > [INFO] BUILD SUCCESS
> > [INFO]
> > 
> > [INFO] Total time:  6.417 s
> > [INFO] Finished at: 2022-03-19T21:15:10+01:00 [INFO]
> > 
> >
> >
> > The XML test report:
> > 
> >
> >
> > Cheers
> > Tibor
> >
> >
> > On Sat, Mar 19, 2022 at 6:53 AM David Karr 
> > wrote:
> >
> > > I, along with two other people on my team, have spent days and days
> > > now trying to figure out why we cannot get Surefire to execute JUnit 5
> > tests.
> > > We've all been working independently, so we don't all take the same
> > > path, but it didn't really matter, as all three of us are pretty much
> > > stuck at the same point.  We can execute JUnit 5 tests in Eclipse, but
> > > Surefire just refuses to have anything to do with JUnit 5 tests.
> > > We've all read numerous threads and posts on how to do it, and it just
> > does not work.
> > >
> > > Most recently, I posted this question with some details of what I had
> > > done so far:
> > >
> > > https://urldefense.com/v3/__https://stackoverflow.com/questions/715310
> > > 01/why-is-surefire-not-executing-my-junit5-tests__;!!BhdT!lvmbYgzuQOyW
> > > UX5ZylkdmfaU3sXf2apqjJSFSSrxKI8axKgcOoSucVscEb7A3q4WNmPmuxJZAl1LW5tYnJ
> > > oJ$
> > > .
> > >
> > > I have no idea whether the problems lie in JUnit 5, or in Surefire, or
> > > some combination.  I wish I could get some debug output that told me
> > SOMETHING.
> > > It just does not run JUnit 5 tests.
> > >
>

Re: Can't get Surefire to run any JUnit 5 tests

[Tibor Digana]

I have created a project which proves that it works with Surefire 3.0.0-M5,
JUnit Jupiter 5.8.2 and Mockito Extension. Please do not use JUnit4 and
Vintage in this case. It is not necessary to use a dependency inside of the
plugin. Use a dependency in the project POM. Follow it on Github:
https://github.com/Tibor17/junit5-mockito-examples

[INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @
why-is-surefire-not-executing-my-junit5-tests ---
[INFO]
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running pkg.BDSHelperTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.396 s - in pkg.BDSHelperTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time:  6.417 s
[INFO] Finished at: 2022-03-19T21:15:10+01:00
[INFO]



The XML test report:



Cheers
Tibor


On Sat, Mar 19, 2022 at 6:53 AM David Karr 
wrote:

> I, along with two other people on my team, have spent days and days now
> trying to figure out why we cannot get Surefire to execute JUnit 5 tests.
> We've all been working independently, so we don't all take the same path,
> but it didn't really matter, as all three of us are pretty much stuck at
> the same point.  We can execute JUnit 5 tests in Eclipse, but Surefire just
> refuses to have anything to do with JUnit 5 tests.  We've all read numerous
> threads and posts on how to do it, and it just does not work.
>
> Most recently, I posted this question with some details of what I had done
> so far:
>
> https://stackoverflow.com/questions/71531001/why-is-surefire-not-executing-my-junit5-tests
> .
>
> I have no idea whether the problems lie in JUnit 5, or in Surefire, or some
> combination.  I wish I could get some debug output that told me SOMETHING.
> It just does not run JUnit 5 tests.
>

Re: Run all tests (also in dependent modules), fail build at end

[Tibor Digana]

(FIXED TYPO)
Hi Alexander,

I have realized that we can move straight ahead with the following.
Basically your expectations are to shift the concrete phase execution of
the build lifecycle to the end of the build.
I can imagine a "generic" Extension and you would configure the Extension
so that the "test" phase *or* the "verify" phase to the end of the build.

If you rephrase the question of this email and send it to the
d...@maven.apache.org, you may receive an answer with an existing solution.
I guess you are not the first person who has this requirement.

Cheers
Tibor



On Tue, Feb 15, 2022 at 11:06 AM Tibor Digana 
wrote:

> Hi Alexander,
>
> I have realized that we can move straight ahead with the following.
> Basically your expectations are to shift the concrete phase execution of
> the build lifecycle to the end of the build.
> I can imagine a "generic" Extension and you would configure the Extension
> so that the "test" phase of the "verify" phase to the end of the build.
>
> If you rephrase the question of this email and send it to the
> d...@maven.apache.org, you may receive an answer with an existing solution.
> I guess you are not the first person who has this requirement.
>
> Cheers
> Tibor
>
>
> On Tue, Feb 15, 2022 at 5:12 AM Alexander Kriegisch <
> alexan...@kriegisch.name> wrote:
>
>> Hi Tibor.
>>
>> I waited for a week in order to see other developers want to contribute
>> to the general discussion you asked to have before making any design
>> decisions the Surefire team might regret later. Did you get the input
>> your were looking for from somewhere off-list, or have you had enough
>> time to decide how you want to handle this? I am not sure I can
>> contribute more than I already have by explaining the potential
>> user/business value in other parts of this thread.
>>
>> Kind regards
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>>
>>
>> Tibor Digana schrieb am 07.02.2022 23:16 (GMT +07:00):
>>
>> > I can imaging to utilize afterSessionEnd()
>> >
>> https://maven.apache.org/ref/3.8.4/maven-core/apidocs/index.html?org/apache/maven/AbstractMavenLifecycleParticipant.html
>> > Maybe this is the way to do it in a clear way via Maven Extensions, see
>> >
>> https://maven.apache.org/ref/3.8.4/maven-core/apidocs/index.html?org/apache/maven/eventspy/AbstractEventSpy.html
>> > https://maven.apache.org/studies/extension-demo/
>> >
>> > and execute the Project's Mojo as if the Mojo was executed in a
>> traditional
>> > way.
>> >
>> > T
>> >
>> > On Sat, Feb 5, 2022 at 5:27 AM Alexander Kriegisch <
>> alexan...@kriegisch.name>
>> > wrote:
>> >
>> >> I know that this probably is a classic question, because there
>> suggested
>> >> answers on Stack Overflow (and maybe also somewhere here in this
>> mailing
>> >> list), but I did not found anything satisfying the following criteria:
>> >>
>> >>   1. Run all Surefire tests, if compilation succeeds, also those of
>> >>  dependent modules, even if there are tests with failurer or
>> errors.
>> >>  (We leave Failsafe out of the picture for now for simplicity's
>> >>  sake, but basically the same would apply to Failsafe tests for
>> >>  modules which can be compiled and packaged, despite failing
>> >>  Surefire tests.)
>> >>
>> >>   2. Fail the multi-module build in the end for all modules with
>> failing
>> >>  tests.
>> >>
>> >> I know there is '-fae', but it skips modules depending on ones with
>> test
>> >> failures.
>> >>
>> >> I know there is '-fn', but it falsely makes the whole build pass.
>> >>
>> >> I know that the Maven build lifecycle is based on module dependencies
>> >> and that dependent modules usually should not be built, if a dependency
>> >> fails to build. But OTOH, the same build would pass with '-DskipTests',
>> >> and the requirement that artifacts be compiled and packaged and
>> >> dependent modules built, because those artifacts can in fact be
>> compiled
>> >> and packaged, makes practical sense. Basically, the user wants test
>> >> failures reported correctly, but still make sure that as many tests as
>> >> possible are being run.
>> >>
>> >> Is there any way to achieve that?
>> >> --
>> >> Alexander Kriegisch
>> >> https://scrum-master.de
>> >>
>> >> -
>> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> >> For additional commands, e-mail: users-h...@maven.apache.org
>> >>
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Re: Run all tests (also in dependent modules), fail build at end

[Tibor Digana]

Hi Alexander,

I have realized that we can move straight ahead with the following.
Basically your expectations are to shift the concrete phase execution of
the build lifecycle to the end of the build.
I can imagine a "generic" Extension and you would configure the Extension
so that the "test" phase of the "verify" phase to the end of the build.

If you rephrase the question of this email and send it to the
d...@maven.apache.org, you may receive an answer with an existing solution.
I guess you are not the first person who has this requirement.

Cheers
Tibor


On Tue, Feb 15, 2022 at 5:12 AM Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> Hi Tibor.
>
> I waited for a week in order to see other developers want to contribute
> to the general discussion you asked to have before making any design
> decisions the Surefire team might regret later. Did you get the input
> your were looking for from somewhere off-list, or have you had enough
> time to decide how you want to handle this? I am not sure I can
> contribute more than I already have by explaining the potential
> user/business value in other parts of this thread.
>
> Kind regards
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Tibor Digana schrieb am 07.02.2022 23:16 (GMT +07:00):
>
> > I can imaging to utilize afterSessionEnd()
> >
> https://maven.apache.org/ref/3.8.4/maven-core/apidocs/index.html?org/apache/maven/AbstractMavenLifecycleParticipant.html
> > Maybe this is the way to do it in a clear way via Maven Extensions, see
> >
> https://maven.apache.org/ref/3.8.4/maven-core/apidocs/index.html?org/apache/maven/eventspy/AbstractEventSpy.html
> > https://maven.apache.org/studies/extension-demo/
> >
> > and execute the Project's Mojo as if the Mojo was executed in a
> traditional
> > way.
> >
> > T
> >
> > On Sat, Feb 5, 2022 at 5:27 AM Alexander Kriegisch <
> alexan...@kriegisch.name>
> > wrote:
> >
> >> I know that this probably is a classic question, because there suggested
> >> answers on Stack Overflow (and maybe also somewhere here in this mailing
> >> list), but I did not found anything satisfying the following criteria:
> >>
> >>   1. Run all Surefire tests, if compilation succeeds, also those of
> >>  dependent modules, even if there are tests with failurer or errors.
> >>  (We leave Failsafe out of the picture for now for simplicity's
> >>  sake, but basically the same would apply to Failsafe tests for
> >>  modules which can be compiled and packaged, despite failing
> >>  Surefire tests.)
> >>
> >>   2. Fail the multi-module build in the end for all modules with failing
> >>  tests.
> >>
> >> I know there is '-fae', but it skips modules depending on ones with test
> >> failures.
> >>
> >> I know there is '-fn', but it falsely makes the whole build pass.
> >>
> >> I know that the Maven build lifecycle is based on module dependencies
> >> and that dependent modules usually should not be built, if a dependency
> >> fails to build. But OTOH, the same build would pass with '-DskipTests',
> >> and the requirement that artifacts be compiled and packaged and
> >> dependent modules built, because those artifacts can in fact be compiled
> >> and packaged, makes practical sense. Basically, the user wants test
> >> failures reported correctly, but still make sure that as many tests as
> >> possible are being run.
> >>
> >> Is there any way to achieve that?
> >> --
> >> Alexander Kriegisch
> >> https://scrum-master.de
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Run all tests (also in dependent modules), fail build at end

[Tibor Digana]

Hi Alexander,

Unfortunately nobody has replied to me, either in the ML.
I guess the Extension API may really solve your issue.

We need to have some prototype which can be developed apart of the Surefire
project.
I guess the prototype should confirm the whole idea.
After we are fine with the result, we can contribute to Surefire.
We can do the same in Surefire directly in a PR.

Currently I am trying to catch up with the promises in the roadmap of M6
and so I am not idle.

The way would be to ask individual contributors and committers to
participate.

Cheers
Tibor17




On Tue, Feb 15, 2022 at 5:12 AM Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> Hi Tibor.
>
> I waited for a week in order to see other developers want to contribute
> to the general discussion you asked to have before making any design
> decisions the Surefire team might regret later. Did you get the input
> your were looking for from somewhere off-list, or have you had enough
> time to decide how you want to handle this? I am not sure I can
> contribute more than I already have by explaining the potential
> user/business value in other parts of this thread.
>
> Kind regards
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Tibor Digana schrieb am 07.02.2022 23:16 (GMT +07:00):
>
> > I can imaging to utilize afterSessionEnd()
> >
> https://maven.apache.org/ref/3.8.4/maven-core/apidocs/index.html?org/apache/maven/AbstractMavenLifecycleParticipant.html
> > Maybe this is the way to do it in a clear way via Maven Extensions, see
> >
> https://maven.apache.org/ref/3.8.4/maven-core/apidocs/index.html?org/apache/maven/eventspy/AbstractEventSpy.html
> > https://maven.apache.org/studies/extension-demo/
> >
> > and execute the Project's Mojo as if the Mojo was executed in a
> traditional
> > way.
> >
> > T
> >
> > On Sat, Feb 5, 2022 at 5:27 AM Alexander Kriegisch <
> alexan...@kriegisch.name>
> > wrote:
> >
> >> I know that this probably is a classic question, because there suggested
> >> answers on Stack Overflow (and maybe also somewhere here in this mailing
> >> list), but I did not found anything satisfying the following criteria:
> >>
> >>   1. Run all Surefire tests, if compilation succeeds, also those of
> >>  dependent modules, even if there are tests with failurer or errors.
> >>  (We leave Failsafe out of the picture for now for simplicity's
> >>  sake, but basically the same would apply to Failsafe tests for
> >>  modules which can be compiled and packaged, despite failing
> >>  Surefire tests.)
> >>
> >>   2. Fail the multi-module build in the end for all modules with failing
> >>  tests.
> >>
> >> I know there is '-fae', but it skips modules depending on ones with test
> >> failures.
> >>
> >> I know there is '-fn', but it falsely makes the whole build pass.
> >>
> >> I know that the Maven build lifecycle is based on module dependencies
> >> and that dependent modules usually should not be built, if a dependency
> >> fails to build. But OTOH, the same build would pass with '-DskipTests',
> >> and the requirement that artifacts be compiled and packaged and
> >> dependent modules built, because those artifacts can in fact be compiled
> >> and packaged, makes practical sense. Basically, the user wants test
> >> failures reported correctly, but still make sure that as many tests as
> >> possible are being run.
> >>
> >> Is there any way to achieve that?
> >> --
> >> Alexander Kriegisch
> >> https://scrum-master.de
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Run all tests (also in dependent modules), fail build at end

[Tibor Digana]

I can imaging to utilize afterSessionEnd()
https://maven.apache.org/ref/3.8.4/maven-core/apidocs/index.html?org/apache/maven/AbstractMavenLifecycleParticipant.html
Maybe this is the way to do it in a clear way via Maven Extensions, see
https://maven.apache.org/ref/3.8.4/maven-core/apidocs/index.html?org/apache/maven/eventspy/AbstractEventSpy.html
https://maven.apache.org/studies/extension-demo/

and execute the Project's Mojo as if the Mojo was executed in a traditional
way.

T

On Sat, Feb 5, 2022 at 5:27 AM Alexander Kriegisch 
wrote:

> I know that this probably is a classic question, because there suggested
> answers on Stack Overflow (and maybe also somewhere here in this mailing
> list), but I did not found anything satisfying the following criteria:
>
>   1. Run all Surefire tests, if compilation succeeds, also those of
>  dependent modules, even if there are tests with failurer or errors.
>  (We leave Failsafe out of the picture for now for simplicity's
>  sake, but basically the same would apply to Failsafe tests for
>  modules which can be compiled and packaged, despite failing
>  Surefire tests.)
>
>   2. Fail the multi-module build in the end for all modules with failing
>  tests.
>
> I know there is '-fae', but it skips modules depending on ones with test
> failures.
>
> I know there is '-fn', but it falsely makes the whole build pass.
>
> I know that the Maven build lifecycle is based on module dependencies
> and that dependent modules usually should not be built, if a dependency
> fails to build. But OTOH, the same build would pass with '-DskipTests',
> and the requirement that artifacts be compiled and packaged and
> dependent modules built, because those artifacts can in fact be compiled
> and packaged, makes practical sense. Basically, the user wants test
> failures reported correctly, but still make sure that as many tests as
> possible are being run.
>
> Is there any way to achieve that?
> --
> Alexander Kriegisch
> https://scrum-master.de
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Run all tests (also in dependent modules), fail build at end

[Tibor Digana]

This is the implementation in maven-deploy-plugin
https://github.com/apache/maven-deploy-plugin/blob/36a2030c8851e21cd1e0bec01c3cea4dc6055a48/src/main/java/org/apache/maven/plugins/deploy/DeployMojo.java#L180

It is caching the objects of ProjectDeployerRequest and called via
maven-artifact.
I can imaging Failsafe verification done in a similar way.
Surefire and Failsafe are very complex, so it would be quite a lot of work.

Maven should have some Event based mechanism regarding the whole build
where the plugin should be able to bind for later execution. I don't think
it has this native mechanism. Then could implement it other way than in the
Deploy plugin.

Cheers
Tibor



On Sat, Feb 5, 2022 at 5:27 AM Alexander Kriegisch 
wrote:

> I know that this probably is a classic question, because there suggested
> answers on Stack Overflow (and maybe also somewhere here in this mailing
> list), but I did not found anything satisfying the following criteria:
>
>   1. Run all Surefire tests, if compilation succeeds, also those of
>  dependent modules, even if there are tests with failurer or errors.
>  (We leave Failsafe out of the picture for now for simplicity's
>  sake, but basically the same would apply to Failsafe tests for
>  modules which can be compiled and packaged, despite failing
>  Surefire tests.)
>
>   2. Fail the multi-module build in the end for all modules with failing
>  tests.
>
> I know there is '-fae', but it skips modules depending on ones with test
> failures.
>
> I know there is '-fn', but it falsely makes the whole build pass.
>
> I know that the Maven build lifecycle is based on module dependencies
> and that dependent modules usually should not be built, if a dependency
> fails to build. But OTOH, the same build would pass with '-DskipTests',
> and the requirement that artifacts be compiled and packaged and
> dependent modules built, because those artifacts can in fact be compiled
> and packaged, makes practical sense. Basically, the user wants test
> failures reported correctly, but still make sure that as many tests as
> possible are being run.
>
> Is there any way to achieve that?
> --
> Alexander Kriegisch
> https://scrum-master.de
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Run all tests (also in dependent modules), fail build at end

[Tibor Digana]

The good way is to discuss the principle xxxAtEnd first and then implement
it properly. Implementing a hack would persist the hack forever and that is
the reality, the practice shows us that it is hapenning.

Dňa ne 6. 2. 2022, 20:02 Lasse Lindqvist 
napísal(a):

> In case you are ready to make you own plugin, it is relatively easy.
>
>
> https://github.com/apache/maven-surefire/tree/master/surefire-report-parser/src/main/java/org/apache/maven/plugins/surefire/report
> contains the code on how the test report is parsed. I could not find proper
> XSD schema for the structure, maybe it does not exist, since I could not
> find any references to such a thing.
> The writing happens for example here
>
> https://github.com/apache/maven-surefire/blob/b9b2381a3dba6574bb69bd91d45fe0edea29c779/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java#L418
>
> So, you can just run the tests with -DtestFailureIgnore=true, and the make
> your plugin run at the end of the build, parse the result and fail the
> build if needed.
>
> Any test publishers in CI systems such as the Jenkins Junit plugin will
> find all the test reports generated and are able to publish them.
>
> Also in Jenkins you can also easily fail the build using the Junit plugin,
> see https://stackoverflow.com/a/57481054. In that case you don't even need
> a custom plugin. So be sure to check what kind of functions the CI system
> you use provides here.
>
>
> su 6. helmik. 2022 klo 14.08 Tibor Digana (tibordig...@apache.org)
> kirjoitti:
>
> > Alexander, all I wanted to say is to discuss the xxxAtEnd as a Maven
> > pattern.
> > Is it what we really want to have in Maven?
> > Last time we discussed it we said that it was a workaround.
> > It should not be a problem to implement in Surefire but it might be an
> > internal issue and we should avoid it. So let's discuss this pattern in
> > general on the ML apart of the target in a concrete plugin.
> >
> > On Sun, Feb 6, 2022 at 7:46 AM Alexander Kriegisch <
> > alexan...@kriegisch.name>
> > wrote:
> >
> > > Actually, I am not sure I want to compare with Install and Deploy
> > > plugin, but because you were mentioning them: 'installAtEnd' and
> > > 'deployAtEnd' are blessings IMO, and they are cornerstones of my work,
> > > because they help to avoid half-installed and - even worse -
> > > half-deployed multi-module projects which would lead to inconsistencies
> > > in repositories and might be hard to rectify in remote repositories,
> > > "burning" release numbers unnecessarily.
> > >
> > > Back to the topic at hand: Having a way to run all tests for a
> > > multi-module project which would build and package perfectly fine when
> > > skipping tests, i.e. not either forcing testing to stop for dependent
> > > projects (skipping tests there) or making the build falsely report
> > > success in the end, is a perfectly valid use case. Who would not like
> to
> > > have that? Creating a report for all failing tests without cheating the
> > > build result to be successful would simply be useful.
> > >
> > > --
> > > Alexander Kriegisch
> > > https://scrum-master.de
> > >
> > >
> > > Tibor Digana schrieb am 06.02.2022 01:45 (GMT +07:00):
> > >
> > > > It is basically the same feature known in the maven-deploy-plugin
> > > >
> > >
> >
> https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd
> > > >
> > > > Not sure if the command
> > > > mvn deploy -DdeployAtEnd
> > > > would fail to deploy dependent modules if the first module fails.
> > > >
> > > > We discussed this feature some time and we said that these features
> > > > xxxAtEnd are a hack.
> > > > The question is regarding Maven 4 and Maven 5.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Feb 5, 2022 at 5:27 AM Alexander Kriegisch <
> > > alexan...@kriegisch.name>
> > > > wrote:
> > > >
> > > >> I know that this probably is a classic question, because there
> > suggested
> > > >> answers on Stack Overflow (and maybe also somewhere here in this
> > mailing
> > > >> list), but I did not found anything satisfying the following
> criteria:
> > > >>
> > > >>   1. Run all Surefire tests, if compilation succeeds, also those of
> > > >>  d

Re: Run all tests (also in dependent modules), fail build at end

[Tibor Digana]

Alexander, all I wanted to say is to discuss the xxxAtEnd as a Maven
pattern.
Is it what we really want to have in Maven?
Last time we discussed it we said that it was a workaround.
It should not be a problem to implement in Surefire but it might be an
internal issue and we should avoid it. So let's discuss this pattern in
general on the ML apart of the target in a concrete plugin.

On Sun, Feb 6, 2022 at 7:46 AM Alexander Kriegisch 
wrote:

> Actually, I am not sure I want to compare with Install and Deploy
> plugin, but because you were mentioning them: 'installAtEnd' and
> 'deployAtEnd' are blessings IMO, and they are cornerstones of my work,
> because they help to avoid half-installed and - even worse -
> half-deployed multi-module projects which would lead to inconsistencies
> in repositories and might be hard to rectify in remote repositories,
> "burning" release numbers unnecessarily.
>
> Back to the topic at hand: Having a way to run all tests for a
> multi-module project which would build and package perfectly fine when
> skipping tests, i.e. not either forcing testing to stop for dependent
> projects (skipping tests there) or making the build falsely report
> success in the end, is a perfectly valid use case. Who would not like to
> have that? Creating a report for all failing tests without cheating the
> build result to be successful would simply be useful.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Tibor Digana schrieb am 06.02.2022 01:45 (GMT +07:00):
>
> > It is basically the same feature known in the maven-deploy-plugin
> >
> https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd
> >
> > Not sure if the command
> > mvn deploy -DdeployAtEnd
> > would fail to deploy dependent modules if the first module fails.
> >
> > We discussed this feature some time and we said that these features
> > xxxAtEnd are a hack.
> > The question is regarding Maven 4 and Maven 5.
> >
> >
> >
> >
> >
> > On Sat, Feb 5, 2022 at 5:27 AM Alexander Kriegisch <
> alexan...@kriegisch.name>
> > wrote:
> >
> >> I know that this probably is a classic question, because there suggested
> >> answers on Stack Overflow (and maybe also somewhere here in this mailing
> >> list), but I did not found anything satisfying the following criteria:
> >>
> >>   1. Run all Surefire tests, if compilation succeeds, also those of
> >>  dependent modules, even if there are tests with failurer or errors.
> >>  (We leave Failsafe out of the picture for now for simplicity's
> >>  sake, but basically the same would apply to Failsafe tests for
> >>  modules which can be compiled and packaged, despite failing
> >>  Surefire tests.)
> >>
> >>   2. Fail the multi-module build in the end for all modules with failing
> >>  tests.
> >>
> >> I know there is '-fae', but it skips modules depending on ones with test
> >> failures.
> >>
> >> I know there is '-fn', but it falsely makes the whole build pass.
> >>
> >> I know that the Maven build lifecycle is based on module dependencies
> >> and that dependent modules usually should not be built, if a dependency
> >> fails to build. But OTOH, the same build would pass with '-DskipTests',
> >> and the requirement that artifacts be compiled and packaged and
> >> dependent modules built, because those artifacts can in fact be compiled
> >> and packaged, makes practical sense. Basically, the user wants test
> >> failures reported correctly, but still make sure that as many tests as
> >> possible are being run.
> >>
> >> Is there any way to achieve that?
> >> --
> >> Alexander Kriegisch
> >> https://scrum-master.de
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Run all tests (also in dependent modules), fail build at end

[Tibor Digana]

It is basically the same feature known in the maven-deploy-plugin
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd

Not sure if the command
mvn deploy -DdeployAtEnd
would fail to deploy dependent modules if the first module fails.

We discussed this feature some time and we said that these features
xxxAtEnd are a hack.
The question is regarding Maven 4 and Maven 5.





On Sat, Feb 5, 2022 at 5:27 AM Alexander Kriegisch 
wrote:

> I know that this probably is a classic question, because there suggested
> answers on Stack Overflow (and maybe also somewhere here in this mailing
> list), but I did not found anything satisfying the following criteria:
>
>   1. Run all Surefire tests, if compilation succeeds, also those of
>  dependent modules, even if there are tests with failurer or errors.
>  (We leave Failsafe out of the picture for now for simplicity's
>  sake, but basically the same would apply to Failsafe tests for
>  modules which can be compiled and packaged, despite failing
>  Surefire tests.)
>
>   2. Fail the multi-module build in the end for all modules with failing
>  tests.
>
> I know there is '-fae', but it skips modules depending on ones with test
> failures.
>
> I know there is '-fn', but it falsely makes the whole build pass.
>
> I know that the Maven build lifecycle is based on module dependencies
> and that dependent modules usually should not be built, if a dependency
> fails to build. But OTOH, the same build would pass with '-DskipTests',
> and the requirement that artifacts be compiled and packaged and
> dependent modules built, because those artifacts can in fact be compiled
> and packaged, makes practical sense. Basically, the user wants test
> failures reported correctly, but still make sure that as many tests as
> possible are being run.
>
> Is there any way to achieve that?
> --
> Alexander Kriegisch
> https://scrum-master.de
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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: surefire process checker

[Tibor Digana]

It is disabled by default, see
http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#enableProcessChecker
For more info see
https://maven.apache.org/surefire/maven-surefire-plugin/examples/shutdown.html
We wrote the reasons why the parameter is disabled. Basically the Java GC
prolonged some periods, and so this feature cannot be guaranteed by the
plugin. You have to find the best option in the config since we cannot make
the best fit for your platform.
T

On Wed, Jul 14, 2021 at 1:22 PM Delany  wrote:

> hi. Is this issue considered "resolved" or just "closed"? I can't tell by
> the discussion.
> https://issues.apache.org/jira/browse/SUREFIRE-1631
>
> I'd like to enable it without having issues in Windows.
> Thanks,
> Delany
>

Re: Sharing Test Dependencies

[Tibor Digana]

Bernd,

If you have two modules
1. Provider API
2. Provider Impl XYZ, ABC

and if you write the tests against the API, you can call them integration
tests, deploy the JAR to the customer and feel free. It would be just like
ordinal module with src/main/java.
T

On Sun, Jul 4, 2021 at 10:27 PM Bernd Eckenfels 
wrote:

> We have one case in commons, there rhe -test JAR of VFS can be used by
> Providers to test their implementation. I did that for my custom provider,
> but it is a bit ugly. I think that’s mostly due to relying on some src
> files and also the JUnit setup when I remember correctly. But it did work,
> even when it’s not what maven project normally do. The test suite could be
> its own module, but it would probably not make it much nicer to run in that
> case, don’t know.
>
> I would not expect Test jars to play nicely with application servers, OSGi
> bundles or JPMS for that matter. Only with shared classpath junit
> “deployment”
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ____
> Von: Tibor Digana 
> Gesendet: Sunday, July 4, 2021 10:19:45 PM
> An: Maven Users List 
> Betreff: Re: Sharing Test Dependencies
>
> I did not have time to read it all but I have to say that even the first
> point is bad.
> Many people want to share test JAR as they initially think it is a good
> idea. And then the problems would come.
>
> sharing stubs? This domain/project may not fit to other domain/project, and
> it creates dangerous cohesion.
> sharing testing utility classes? Maybe, it depends. It must be universal
> and independent of the project's domain. Do it in a separate Git project.
> sharing JUnit superclasses? The inheritance must be domain/business
> independent. It must be only a technical class. Do it in a separate Git
> project.
>
> T
>
>
>
> On Thu, Jul 1, 2021 at 7:15 PM Brandon Mintern 
> wrote:
>
> > Hello all,
> >
> > I'm running up against an issue that I'm sure has come up countless
> times.
> > How can we share test dependencies in a principled way? I would like to
> > configure our projects such that:
> >
> >1. For a project *P*, its tests are associated with the project, so
> that
> >`mvn install` from the project directory *p/* fails when P's tests
> fail.
> >2. Some of P's testing functionality (e.g., stubs, testing utility
> >classes, JUnit superclasses) are packaged for use in the tests of
> other
> >projects* D* that depend on P.
> >3. P's shared testing functionality has dependencies on P. For
> example,
> >P defines a repository interface R, and its tests define and use an
> > RStub
> >that implements R. We want to package RStub for use by D's tests.
> >4. When D declares a scope:test dependency on P's testing
> functionality,
> >automatically pull in the transitive dependencies of that testing
> >functionality.
> >5. Avoid cycles in the Maven dependency graph.
> >
> > Some things I've tried so far:
> >
> >- Create test-jars for P. This fails on #2 and #4:
> >- The test-jars include all of P's test classes instead of just the
> >   testing functionality that needs to be shared for use by D's tests.
> >   - All transitive dependencies of P's test-jar must be manually
> >   specified with scope:test in the D's POM.
> >- Extract the stubs to an independent "P - Stubs" project, which P's
> >tests depend on.
> >   - p-stubs depends on P.
> >   - Stubs, testing utilities, etc. go in p-stubs/src/main/.
> >   - P depends on p-stubs with scope:test.
> >   - D depends on p-stubs with scope:test.
> >   - This fails on #5: it causes a cycle in the dependency graph
> since P
> >   depends on p-stubs (scope:test) and p-stubs depends on P. See
> >   https://stackoverflow.com/questions/10174542
> >- Create an independent "P - Tests" project, with P's stubs and tests.
> >   - p-tests depends on P.
> >   - Stubs, testing utilities, etc. go in p-tests/src/main/.
> >   - P's tests go in p-tests/src/test/.
> >   - D depends on p-tests with scope:test.
> >   - This almost works but fails on #1: P's build succeeds when its
> >   tests fail.
> >   - This approach also seems to be fighting Maven and IDE tooling.
> For
> >   example, NetBeans will automatically create p/src/test even
> > though we never
> >   intend to put anything there.
> >
> > My searches so far have not turned up any complete solutions to this
> > problem. The maven-jar-plugin documentation has a 

Re: Sharing Test Dependencies

[Tibor Digana]

You can easily solve this.
Just create (N+1) module which contains test classes.
The N+1 module should inherit from the module N having normal sources.
The trick is to build module N, and then N+1.

On Fri, Jul 9, 2021 at 1:13 AM Brandon Mintern  wrote:

> Tibor,
>
> Thanks for your thoughts. Would it be worthwhile for me to construct and
> share a minimal concrete example to motivate this discussion? It's not
> clear to me that you're open to the possibility that I'm describing a
> reasonable use case here.
>
> On Thu, Jul 8, 2021 at 4:06 PM Tibor Digana 
> wrote:
>
> > The tests are dedicated to the module sources and not to the other
> > module/s.
> > They were not designed to be inherited and it is logical because unit
> tests
> > have to test a small unit code where the unit is a method, class or a
> > module.
> > Integration tests are used to test the whole application which is a bunch
> > of compiled and packaged modules but these tests also do not need to be
> > shared. It's enough if a separate module is called IT and it is built at
> > last in the CI process.
> >
> > On Fri, Jul 9, 2021 at 12:41 AM Andy Feldman 
> > wrote:
> >
> > > On Thu, Jul 1, 2021 at 12:15 PM Brandon Mintern 
> > > wrote:
> > >
> > > > Maybe one of these—or a better alternative—is already possible? I
> feel
> > > like
> > > > I must be missing something. Is something wrong with the way I'm
> > > > structuring my projects? Does Maven already provide a way to achieve
> > this
> > > > out-of-the-box? Is there a plugin that provides something like the
> > > "stubs"
> > > > functionality?
> > > >
> > >
> > > There was some discussion of this issue on this list a year ago as
> well:
> > >
> > >
> >
> https://lists.apache.org/thread.html/r6bfcf85aa7fd2b9a02a3f2513b9e10f1141b9102fda2bfc533d02379%40%3Cusers.maven.apache.org%3E
> > >
> > > The conclusion was also that there's no great way to accomplish this. I
> > > think one good way to fix this issue would be to have Maven resolve
> > > test-scoped dependencies transitively when you depend on test-jars, but
> > > perhaps there's a good reason why that's not practical or not a good
> > idea.
> > >
> > > --
> > > Andy Feldman
> > >
> >
>

Re: Sharing Test Dependencies

[Tibor Digana]

No, it cannot be based on one use case. It must be based on a theory and
generic and representative principles.

On Fri, Jul 9, 2021 at 1:13 AM Brandon Mintern  wrote:

> Tibor,
>
> Thanks for your thoughts. Would it be worthwhile for me to construct and
> share a minimal concrete example to motivate this discussion? It's not
> clear to me that you're open to the possibility that I'm describing a
> reasonable use case here.
>
> On Thu, Jul 8, 2021 at 4:06 PM Tibor Digana 
> wrote:
>
> > The tests are dedicated to the module sources and not to the other
> > module/s.
> > They were not designed to be inherited and it is logical because unit
> tests
> > have to test a small unit code where the unit is a method, class or a
> > module.
> > Integration tests are used to test the whole application which is a bunch
> > of compiled and packaged modules but these tests also do not need to be
> > shared. It's enough if a separate module is called IT and it is built at
> > last in the CI process.
> >
> > On Fri, Jul 9, 2021 at 12:41 AM Andy Feldman 
> > wrote:
> >
> > > On Thu, Jul 1, 2021 at 12:15 PM Brandon Mintern 
> > > wrote:
> > >
> > > > Maybe one of these—or a better alternative—is already possible? I
> feel
> > > like
> > > > I must be missing something. Is something wrong with the way I'm
> > > > structuring my projects? Does Maven already provide a way to achieve
> > this
> > > > out-of-the-box? Is there a plugin that provides something like the
> > > "stubs"
> > > > functionality?
> > > >
> > >
> > > There was some discussion of this issue on this list a year ago as
> well:
> > >
> > >
> >
> https://lists.apache.org/thread.html/r6bfcf85aa7fd2b9a02a3f2513b9e10f1141b9102fda2bfc533d02379%40%3Cusers.maven.apache.org%3E
> > >
> > > The conclusion was also that there's no great way to accomplish this. I
> > > think one good way to fix this issue would be to have Maven resolve
> > > test-scoped dependencies transitively when you depend on test-jars, but
> > > perhaps there's a good reason why that's not practical or not a good
> > idea.
> > >
> > > --
> > > Andy Feldman
> > >
> >
>

Re: Sharing Test Dependencies

[Tibor Digana]

The tests are dedicated to the module sources and not to the other module/s.
They were not designed to be inherited and it is logical because unit tests
have to test a small unit code where the unit is a method, class or a
module.
Integration tests are used to test the whole application which is a bunch
of compiled and packaged modules but these tests also do not need to be
shared. It's enough if a separate module is called IT and it is built at
last in the CI process.

On Fri, Jul 9, 2021 at 12:41 AM Andy Feldman  wrote:

> On Thu, Jul 1, 2021 at 12:15 PM Brandon Mintern 
> wrote:
>
> > Maybe one of these—or a better alternative—is already possible? I feel
> like
> > I must be missing something. Is something wrong with the way I'm
> > structuring my projects? Does Maven already provide a way to achieve this
> > out-of-the-box? Is there a plugin that provides something like the
> "stubs"
> > functionality?
> >
>
> There was some discussion of this issue on this list a year ago as well:
>
> https://lists.apache.org/thread.html/r6bfcf85aa7fd2b9a02a3f2513b9e10f1141b9102fda2bfc533d02379%40%3Cusers.maven.apache.org%3E
>
> The conclusion was also that there's no great way to accomplish this. I
> think one good way to fix this issue would be to have Maven resolve
> test-scoped dependencies transitively when you depend on test-jars, but
> perhaps there's a good reason why that's not practical or not a good idea.
>
> --
> Andy Feldman
>

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: Sharing Test Dependencies

[Tibor Digana]

I did not have time to read it all but I have to say that even the first
point is bad.
Many people want to share test JAR as they initially think it is a good
idea. And then the problems would come.

sharing stubs? This domain/project may not fit to other domain/project, and
it creates dangerous cohesion.
sharing testing utility classes? Maybe, it depends. It must be universal
and independent of the project's domain. Do it in a separate Git project.
sharing JUnit superclasses? The inheritance must be domain/business
independent. It must be only a technical class. Do it in a separate Git
project.

T



On Thu, Jul 1, 2021 at 7:15 PM Brandon Mintern  wrote:

> Hello all,
>
> I'm running up against an issue that I'm sure has come up countless times.
> How can we share test dependencies in a principled way? I would like to
> configure our projects such that:
>
>1. For a project *P*, its tests are associated with the project, so that
>`mvn install` from the project directory *p/* fails when P's tests fail.
>2. Some of P's testing functionality (e.g., stubs, testing utility
>classes, JUnit superclasses) are packaged for use in the tests of other
>projects* D* that depend on P.
>3. P's shared testing functionality has dependencies on P. For example,
>P defines a repository interface R, and its tests define and use an
> RStub
>that implements R. We want to package RStub for use by D's tests.
>4. When D declares a scope:test dependency on P's testing functionality,
>automatically pull in the transitive dependencies of that testing
>functionality.
>5. Avoid cycles in the Maven dependency graph.
>
> Some things I've tried so far:
>
>- Create test-jars for P. This fails on #2 and #4:
>- The test-jars include all of P's test classes instead of just the
>   testing functionality that needs to be shared for use by D's tests.
>   - All transitive dependencies of P's test-jar must be manually
>   specified with scope:test in the D's POM.
>- Extract the stubs to an independent "P - Stubs" project, which P's
>tests depend on.
>   - p-stubs depends on P.
>   - Stubs, testing utilities, etc. go in p-stubs/src/main/.
>   - P depends on p-stubs with scope:test.
>   - D depends on p-stubs with scope:test.
>   - This fails on #5: it causes a cycle in the dependency graph since P
>   depends on p-stubs (scope:test) and p-stubs depends on P. See
>   https://stackoverflow.com/questions/10174542
>- Create an independent "P - Tests" project, with P's stubs and tests.
>   - p-tests depends on P.
>   - Stubs, testing utilities, etc. go in p-tests/src/main/.
>   - P's tests go in p-tests/src/test/.
>   - D depends on p-tests with scope:test.
>   - This almost works but fails on #1: P's build succeeds when its
>   tests fail.
>   - This approach also seems to be fighting Maven and IDE tooling. For
>   example, NetBeans will automatically create p/src/test even
> though we never
>   intend to put anything there.
>
> My searches so far have not turned up any complete solutions to this
> problem. The maven-jar-plugin documentation has a section
> <
> https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html#The_preferred_way
> >
> that touches on this issue:
>
> The preferred way
>
> In order to let Maven resolve all test-scoped transitive dependencies you
> should create a separate project.
>
>
>1. 
>2.groupId
>3. artifactId-tests
>4. version
>5.   ...
>6. 
>
>
>- Move the sources files from src/test/java you want to share from the
>original project to the src/main/java of this project. The same type of
>movement counts for the resources as well of course.
>- Move the required test-scoped dependencies and from the original
>project to this project and remove the scope (i.e. changing it to the
>compile-scope). And yes, that means that the junit dependency (or any
>other testing framework dependency) gets the default scope too. You'll
>probably need to add some project specific dependencies as well to let
> it
>all compile again.
>
> Now you have your reusable *test-classes* and you can refer to it as you're
> used to...
>
> This is along the lines of the "P - Stubs" approach I suggested above, but
> it unfortunately cannot work since the stubs themselves depend on P (fails
> on #3 above).
>
> Is there a satisfying way to solve this problem? It seems to me like any
> one of the following changes would resolve the issue.
>
>- Allow P to depend on a separate project p-stubs with scope:test, even
>though p-stubs depends on P (instead of calling it a dependency cycle).
>This means that the build order would be a bit awkward: P (compile) →
>p-stubs (compile) → P (test).
>- Allow P to indicate that its tests are in another project p-tests.
>That way, `mvn install` in p/ would continue to 

Re: Making surefire fail on 0 tests run

[Tibor Digana]

Our users should read the documentations.
Let's start with the list of Maven Plugins where you can select the one you
need.
https://maven.apache.org/plugins/index.html
Then you click on a plugin named "surefire"
https://maven.apache.org/surefire/maven-surefire-plugin/
and then navigate to the section "Goals" on the web page of the particular
plugin. (every plugin has this section)
https://maven.apache.org/surefire/maven-surefire-plugin/plugin-info.html
and then choose the goal. In this case it is "test" (see "surefire:test")
and then read the list of parameters:
https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html
and there one can find the parameter "failIfNoTests".

This is basically the way how to work with the documentation of plugins in
Maven for users.



On Thu, Jun 3, 2021 at 10:02 AM Niels Basjes  wrote:

> Thanks!
>
> On Wed, 2 Jun 2021, 21:49 Lasse Lindqvist, 
> wrote:
>
> > Hi. failIfNoTests property should achieve this. (
> >
> >
> https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#failIfNoTests
> > Since version 2.4)
> >
> > ke 2. kesäk. 2021 klo 22.44 Niels Basjes (ni...@basjes.nl) kirjoitti:
> >
> > > Hi,
> > >
> > > I've had over the last few years several times when a simple mistake I
> > made
> > > in the pom.xml caused the surefire (or junit at hand) to run 0 tests.
> > > Add since 0 were run also 0 failed and 0 failed means all tests passed.
> > >
> > > What I'm looking for is to let surefire fail if 0 tests were run (If I
> > did
> > > not do 'skipTests').
> > >
> > > Is there a clean way to configure that or is this something I should
> > > propose a change for in surefire itself?
> > >
> > > --
> > > Best regards / Met vriendelijke groeten,
> > >
> > > Niels Basjes
> > >
> >
>

Re: Why does Maven Shade relocate modify unrelated classes?

[Tibor Digana]

Where is the ticket in Jira?
Last time I meant when Romain improved the plugin a lot. Maybe before you
created the ticket.
T

On Sun, May 16, 2021 at 1:01 PM Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> Sorry Tibor, I am not sure which "last time" you are talking about. I
> think, last time I interacted with anyone concerning Maven Shade on Jira
> was by commenting on an old, existing ticket, getting zero help and then
> fixing the problem myself, trying return something to the community by
> means of an utterly ignored pull request. Hence, I thought I try a
> channel other than Jira and a simple question istead of a PR this time.
> It seems to me, whichever way I choose, it is considered to be wrong.
> What would you have me do? Open a Jira issue, sending a link to the OSS
> project I am working on and which reproduces the mentioned behaviour?
> Maybe a screenshot of me "diffing" the two JARs before and after
> relocation? I am willing to provide any kind of information which makes
> someone engange in investigating and finally answering my question. Just
> kindly let me know how to do it right this time.
>
>
> Tibor Digana schrieb am 16.05.2021 17:16 (GMT +07:00):
>
> > These Apache developers work with Jira based on objective materials
> > attached to Jira, like a reproducible project provided by you on Github
> or
> > a provided POM.
> > Then they will take care especially regarding the maven-shade-plugin they
> > want to improve this plugin, and there was a big effort given to this
> > plugin last time, so I am sure they want to handle the bugs in Jira
> again.
> > T
> >
> > On Sun, May 16, 2021 at 4:41 AM Alexander Kriegisch <
> > alexan...@kriegisch.name> wrote:
> >
> >> When running Maven Shade with relocation, it works nicely. When
> >> comparing JARs before and after relocation, I was surprised to see that
> >> Shade not just modifies the relocated classes and classes referencing
> >> them, but also a bunch of IMO completely unrelated classes. In my case I
> >> am transforming an uber JAR containing ASM, and I selectively relocate
> >> the ASM classes, intending to leave all others untouched. I know that
> >> ASM classes are referred to by some of the other classes, but by no
> >> means as many as are being modified. The byte code is slightly
> >> different, probably still does the same thing, but it makes comparisons
> >> and sanity checks or automatic verification steps harder than necessary.
> >> BTW, the same Shade execution also relocates the sources and really only
> >> changes source files referencing ASM, just like I would have expected.
> >>
> >> Looking forward to your insights
> >> --
> >> Alexander Kriegisch
> >> https://scrum-master.de
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Why does Maven Shade relocate modify unrelated classes?

[Tibor Digana]

These Apache developers work with Jira based on objective materials
attached to Jira, like a reproducible project provided by you on Github or
a provided POM.
Then they will take care especially regarding the maven-shade-plugin they
want to improve this plugin, and there was a big effort given to this
plugin last time, so I am sure they want to handle the bugs in Jira again.
T

On Sun, May 16, 2021 at 4:41 AM Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> When running Maven Shade with relocation, it works nicely. When
> comparing JARs before and after relocation, I was surprised to see that
> Shade not just modifies the relocated classes and classes referencing
> them, but also a bunch of IMO completely unrelated classes. In my case I
> am transforming an uber JAR containing ASM, and I selectively relocate
> the ASM classes, intending to leave all others untouched. I know that
> ASM classes are referred to by some of the other classes, but by no
> means as many as are being modified. The byte code is slightly
> different, probably still does the same thing, but it makes comparisons
> and sanity checks or automatic verification steps harder than necessary.
> BTW, the same Shade execution also relocates the sources and really only
> changes source files referencing ASM, just like I would have expected.
>
> Looking forward to your insights
> --
> Alexander Kriegisch
> https://scrum-master.de
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Plugin execution order in same phase + profiles

[Tibor Digana]

If two plugins with the same phase appear in the build section of one POM,
then their order matters.
If they split in build and a profile, then the order is not guaranteed
because there are no in one XML section and so the order cannot be
determined.
This might be possible in Maven 5. Let's ask such a question regarding
Maven 5 in our mailing list.
We are developing a new approach in Maven 5 and every problem may help us
to make a better design.

Cheers
Tibor

On Fri, May 7, 2021 at 1:15 AM Alexander Kriegisch 
wrote:

> I notices an unexpected thing about plugin execution order: If I have
> several plugins running in the same phase, normally they are executed in
> the lexical order in which they appear in the POM. But there is a case
> in which this can change. Schematically, it looks like this:
>
> 
>   
> 
>   
> 
>   
> 
>   
> 
>
> 
>   
> 
>   
> 
>
> My expectation was that the execution order in phase X would be plugin
> A, then B. This is true sometimes, depending on which build other
> profiles are active. I mean completely unrelated profiles defined in
> other Maven modules. In my specific case, without specifying any other
> profiles (P is auto-activated bases on non-existence of a file), the
> order was B, A. If I manually activated any other profile or
> de-activated a profile which otherwise would be active automatically,
> the order changed to A, B.
>
> In my case, I had the option of moving plugin B to a later phase, which
> settled the issue for me, but that is not always possible.
>
> Can anybody enlighten me on what is happening here and if this behaviour
> is documented anywhere? Or is this just the "read the freakin' source
> code, pal" kind of detail?
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: [maven-failsafe-plugin] run suites in parallel using maven failsafe

[Tibor Digana]

This is the page where we describe the parallel execution for JUnit4
Maven Surefire Plugin – Fork Options and Parallel Test Execution
(apache.org)
<https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html>


and the source of this page can be found in
maven-surefire/fork-options-and-parallel-execution.apt.vm at master ·
apache/maven-surefire (github.com)
<https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/site/apt/examples/fork-options-and-parallel-execution.apt.vm>


T


On Tue, Apr 13, 2021 at 9:27 PM V. Mark Lehky  wrote:

> I will not be able to look at this today, but I will hopefully get
> back to this within the next week.
>
> If I get this working, I definitely will be able to contribute back.
> Can you suggest where would be the best place to add docs about this?
>
> On Tue, 13 Apr 2021 at 00:40, Tibor Digana  wrote:
> >
> > Hi,
> >
> > threadCountSuites is related to JUnit4 Suite, see this:
> > https://github.com/junit-team/junit4/wiki/Aggregating-tests-in-suites
> >
> > threadCountClasses is related to the typical classes, see this example:
> > https://github.com/junit-team/junit4/wiki/Assertions
> >
> > Parallel packages do not exist, but you can make the same if you write a
> > Suite of Suites, example:
> > SuiteMainTest has (SuiteATest, SuiteBTest) where SuiteATest has
> > SomeStoryTest, AnotherStoryTest and SuiteBTest has DifferentStoryTest,
> > OtherStoryTest
> > and use this configuration parallel=suites, threadCountSuites=2,
> > test=SuiteMainTest.
> > This would work as you want to.
> >
> > It would nice to write an example in our documentation. If you want to
> > participate in the open source, you can open a pullrequest in GitHub.
> >
> >
> > Cheers
> > Tibor
> >
> > On Mon, Apr 12, 2021 at 8:48 PM V. Mark Lehky 
> wrote:
> >
> > > I am trying to run my tests in parallel, and I have a use-case
> > > different from all others that I have been able to find.
> > >
> > > My tests are laid out pretty straight-forward, something like the
> > > following:
> > >
> > > src/test/java/
> > > +-features.areaA
> > > | +-SomeStory.java
> > > | +-AnotherStory.java
> > > | ...
> > > +-features.areaB
> > > | +-DifferentStory.java
> > > | +-OtherStory.java
> > > | ...
> > > ...
> > >
> > > The tests are written using serenity-bdd, which is a wrapper for
> > > selenium, and the test manager is junit4.
> > >
> > > Each "area" represents some discreet area of the application under
> > > test. Tests within one area cannot run in parallel as they would
> > > clobber the data they are using. However, tests between different
> > > areas can certainly run in parallel as there are no collisions.
> > >
> > > I tried to configure my maven-failsafe-plugin according to the
> > > documentation (
> > >
> https://maven.apache.org/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html
> > > ).
> > > Using parallel=suites and any one of threadCount=4,
> > > threadCountSuites=4, or useUnlimitedThreads=true, results in only one
> > > test being run at a time.
> > >
> > > Is my understanding of "suites" wrong in the context of Failsafe
> > > plugin? Is it possible to parallelize tests so that entire packages
> > > are fed into VM threads one at a time, but classes within one package
> > > run sequentially?
> > >
> > > ty
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: directed acyclic graph of the build

[Tibor Digana]

DAG of the POM.
I am using IntelliJ IDEA for such things but you can also use
maven-dependency-plugin which prints the dependencies in the console.

On Tue, Apr 13, 2021 at 1:26 PM Delany  wrote:

> Hi
>
> How can I get a DAG of the build?
> I want to see how projects are being scheduled in a multithreaded build.
>
> Thanks,
> Delany
>

Re: [maven-failsafe-plugin] run suites in parallel using maven failsafe

[Tibor Digana]

There are 3 suites in my example, so set threadCountSuites=3.

On Tue, Apr 13, 2021 at 9:39 AM Tibor Digana  wrote:

> Hi,
>
> threadCountSuites is related to JUnit4 Suite, see this:
> https://github.com/junit-team/junit4/wiki/Aggregating-tests-in-suites
>
> threadCountClasses is related to the typical classes, see this example:
> https://github.com/junit-team/junit4/wiki/Assertions
>
> Parallel packages do not exist, but you can make the same if you write a
> Suite of Suites, example:
> SuiteMainTest has (SuiteATest, SuiteBTest) where SuiteATest has
> SomeStoryTest, AnotherStoryTest and SuiteBTest has DifferentStoryTest,
> OtherStoryTest
> and use this configuration parallel=suites, threadCountSuites=2,
> test=SuiteMainTest.
> This would work as you want to.
>
> It would nice to write an example in our documentation. If you want to
> participate in the open source, you can open a pullrequest in GitHub.
>
>
> Cheers
> Tibor
>
> On Mon, Apr 12, 2021 at 8:48 PM V. Mark Lehky 
> wrote:
>
>> I am trying to run my tests in parallel, and I have a use-case
>> different from all others that I have been able to find.
>>
>> My tests are laid out pretty straight-forward, something like the
>> following:
>>
>> src/test/java/
>> +-features.areaA
>> | +-SomeStory.java
>> | +-AnotherStory.java
>> | ...
>> +-features.areaB
>> | +-DifferentStory.java
>> | +-OtherStory.java
>> | ...
>> ...
>>
>> The tests are written using serenity-bdd, which is a wrapper for
>> selenium, and the test manager is junit4.
>>
>> Each "area" represents some discreet area of the application under
>> test. Tests within one area cannot run in parallel as they would
>> clobber the data they are using. However, tests between different
>> areas can certainly run in parallel as there are no collisions.
>>
>> I tried to configure my maven-failsafe-plugin according to the
>> documentation (
>> https://maven.apache.org/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html
>> ).
>> Using parallel=suites and any one of threadCount=4,
>> threadCountSuites=4, or useUnlimitedThreads=true, results in only one
>> test being run at a time.
>>
>> Is my understanding of "suites" wrong in the context of Failsafe
>> plugin? Is it possible to parallelize tests so that entire packages
>> are fed into VM threads one at a time, but classes within one package
>> run sequentially?
>>
>> ty
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Re: [maven-failsafe-plugin] run suites in parallel using maven failsafe

[Tibor Digana]

Hi,

threadCountSuites is related to JUnit4 Suite, see this:
https://github.com/junit-team/junit4/wiki/Aggregating-tests-in-suites

threadCountClasses is related to the typical classes, see this example:
https://github.com/junit-team/junit4/wiki/Assertions

Parallel packages do not exist, but you can make the same if you write a
Suite of Suites, example:
SuiteMainTest has (SuiteATest, SuiteBTest) where SuiteATest has
SomeStoryTest, AnotherStoryTest and SuiteBTest has DifferentStoryTest,
OtherStoryTest
and use this configuration parallel=suites, threadCountSuites=2,
test=SuiteMainTest.
This would work as you want to.

It would nice to write an example in our documentation. If you want to
participate in the open source, you can open a pullrequest in GitHub.


Cheers
Tibor

On Mon, Apr 12, 2021 at 8:48 PM V. Mark Lehky  wrote:

> I am trying to run my tests in parallel, and I have a use-case
> different from all others that I have been able to find.
>
> My tests are laid out pretty straight-forward, something like the
> following:
>
> src/test/java/
> +-features.areaA
> | +-SomeStory.java
> | +-AnotherStory.java
> | ...
> +-features.areaB
> | +-DifferentStory.java
> | +-OtherStory.java
> | ...
> ...
>
> The tests are written using serenity-bdd, which is a wrapper for
> selenium, and the test manager is junit4.
>
> Each "area" represents some discreet area of the application under
> test. Tests within one area cannot run in parallel as they would
> clobber the data they are using. However, tests between different
> areas can certainly run in parallel as there are no collisions.
>
> I tried to configure my maven-failsafe-plugin according to the
> documentation (
> https://maven.apache.org/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html
> ).
> Using parallel=suites and any one of threadCount=4,
> threadCountSuites=4, or useUnlimitedThreads=true, results in only one
> test being run at a time.
>
> Is my understanding of "suites" wrong in the context of Failsafe
> plugin? Is it possible to parallelize tests so that entire packages
> are fed into VM threads one at a time, but classes within one package
> run sequentially?
>
> ty
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Core plugins, milestone versions

[Tibor Digana]

Milestone means "work in progress" and if you are continuously breaking
backwards compatibility, you can do it in multiple milestones. It does not
make sense to release multiple release versions because it's risky for
users. This email has convinced me to publish a pull request with changes
mandatory for a milestone and everybody is welcome to participate.
Cheers
Tibor

On Tue, Mar 30, 2021 at 8:03 PM Benjamin Marwell 
wrote:

> Hi Antoine,
>
> That's probably a typical YMMV question.
> From my experience with surefire, I'd say rather stick with the 2.x
> versions as long as you don't need an explicit feature of the 3.x Milestone
> version.
> If something doesn't work or is missing, open up a ticket or ask on this
> list.
>
> If you find a milestone version good enough, just post it here and ask for
> a release. We did that with the jpackage plugin and might do this with
> others as well.
>
> - Ben
>
>
> On Tue, 30 Mar 2021, 18:39 Antoine Mottier, 
> wrote:
>
> > Hello,
> >
> > While looking at https://maven.apache.org/plugins/index.html I
> > realized that many core plugin versions are actually milestone version
> > (e.g. deploy: 3.0.0-M1).
> >
> > It seems that some of them are release quite a long time ago (e.g.
> > deploy: 2018-09-23). I was wondering what is the recommendation:
> > should I use the latest version even if it is a milestone version? Or
> > should I use the latest "stable" version (e.g. 2.8.2 for deploy plugin)?
> >
> > Thanks.
> >
> > --
> > Antoine Mottier
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Maven superpom, JUnit 5 and Spring

[Tibor Digana]

shortly, the Maven 3.7.0 had the Jira issue, and I think resolved it, with
bumped versions of default plugins to the most recent ones.
We stopped 3.7.0 and we are developing 4.0.0 now.
T

On Sun, Mar 7, 2021 at 10:58 PM Greg Chabala  wrote:

> You're taking the discussion to a place about building something flexible,
> but the initial question from a user was 'Why is the Super POM pulling in
> an old version of maven-surefire-plugin by default?'. That's an issue that
> deserves to be solved.
>
> Maven 3.6.3's Super POM pulls in maven-surefire-plugin version 2.12.4,
> which was published 2012-09-24. Can we update the Super POM to something
> less ancient so that new users don't get burned by default?
>
> On Sun, Mar 7, 2021 at 2:07 PM Hervé BOUTEMY 
> wrote:
>
> > if you're talking about the little subset that we use for our default
> > packaging bindings [1], as you can see from the page, there is already a
> > version fixed by the bindings
> >
> > but:
> > 1. that ties you to a precise Maven version, which is something we want
> to
> > avoid
> > 2. it does not work for the many other plugins
> >
> > that's why any discussion is about making something flexible, and not
> > focusing
> > only on the few plugins used by default packagings
> >
> > regards,
> >
> > Hervé
> >
> > [1] https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html
> >
> > Le dimanche 7 mars 2021, 15:43:45 CET Mantas Gridinas a écrit :
> > > Maven does not provide all of those 5 thousand plugins by default, does
> > it?
> > >
> > > On Sun, Mar 7, 2021 at 11:39 AM Hervé BOUTEMY 
> > wrote:
> > > > > But my question is why not add a feature where maven would
> > > > > produce a pom that contains the default plugins, repositories, and
> > etc.
> > > > > regardless of how verbose it would be?
> > > >
> > > > because there is a wide diversity of plugins (more than 5,000 in
> > Central
> > > > Repository), then nobody can define everything
> > > >
> > > > We need something extensible
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le dimanche 7 mars 2021, 12:08:39 CET Mantas Gridinas a écrit :
> > > > > As far as I understand, depending on maven version, the list of
> > default
> > > > > plugin versions is different. One way I go around this is by using
> > maven
> > > > > wrapper, which also downloads the required maven version by the
> > project.
> > > > >
> > > > > The other way to go around this is to define all the plugin
> versions
> > > > > yourself. But my question is why not add a feature where maven
> would
> > > > > produce a pom that contains the default plugins, repositories, and
> > etc.
> > > > > regardless of how verbose it would be?
> > > > >
> > > > > On Sun, Mar 7, 2021, 12:46 Hervé BOUTEMY 
> > wrote:
> > > > > > sorry, I don't understand: can you explain a little more what you
> > mean
> > > > > > by
> > > > > > "produce the implied pom" and "some issues of irreproducability"?
> > > > > >
> > > > > > Le dimanche 7 mars 2021, 10:44:08 CET Mantas Gridinas a écrit :
> > > > > > > Why not provide an ability to produce the implied pom
> explicitly
> > in
> > > > > > > current project as well? This way you would get around some
> > issues
> > > > > > > of
> > > > > > > irreproducability.
> > > > > > >
> > > > > > > On Sun, Mar 7, 2021 at 9:29 AM Hervé BOUTEMY <
> > herve.bout...@free.fr>
> > > > > >
> > > > > > wrote:
> > > > > > > > every existing plugin version can't be defined by Maven
> itself,
> > > > > > > > given
> > > > > > > > diversity of plugins
> > > > > > > > then we need something extensible
> > > > > > > >
> > > > > > > > there is https://issues.apache.org/jira/browse/MNG-5588 ,
> > > > > > > > proposing to
> > > > > > > > mimic dependencyManagement import to get an equivalent
> > > > > > > > pluginManagement
> > > > > > > > import
> > > > > > > >
> > > > > > > > I love this idea, which is currently blocked by one stupid
> > > > > > > > concrete
> > > > > >
> > > > > > issue:
> > > > > > > > there is no "scope" field in plugin definition
> > > > > > > >
> > > > > > > > looking at model:
> > > > > > > >
> > https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_pl
> > > > > > > > ugin
> > > > > > > >
> > > > > > > > perhaps we could abuse plugin's "inherited" field, the same
> > way we
> > > > > >
> > > > > > abused
> > > > > >
> > > > > > > > "scope" field of dependencies...
> > > > > > > >
> > > > > > > > Any taker to work with me on trying to code that?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Hervé
> > > > > > > >
> > > > > > > > Le mardi 23 février 2021, 00:03:16 CET Greg Chabala a écrit :
> > > > > > > > > I agree with the recommendations made by Anthony, and that
> > best
> > > > > >
> > > > > > practice
> > > > > >
> > > > > > > > > is
> > > > > > > > > to specify all versions explicitly.
> > > > > > > > >
> > > > > > > > > However, I am also empathetic to the concerns raised by
> > Tilman.
> > > > > > > > > When
> > > > > > > > > people
> 

Re: Maven surefire plugin: parallel configuration not running tests in parallel

[Tibor Digana]

We will do our best as well. On one hand TeamCity uses flowId based on
Thread ID, the surefire plugin can use a similar mechanism we used before
in surefire-junit47-provider and we can identify the lines of system output
by Thread ID.

T

On Wed, Feb 17, 2021 at 6:31 PM Jay Crosley  wrote:

> My plan is to run these serially for local development and in parallel for
> TeamCity, and for TeamCity I think it will pick out the logs using flowId,
> so hopefully that will work.
>
> From: Tibor Digana 
> Date: Wednesday, February 17, 2021 at 2:19 AM
> To: Maven Users List 
> Subject: Re: Maven surefire plugin: parallel configuration not running
> tests in parallel
> In case of combining JUnit5 and Surefire/Failsafe, the configuration
> parameters e.g. "parallel" and "threadCountClasses" are not bound to the
> native JUnit parameters "junit.jupiter.execution.parallel.enabled" because
> it was an agreement between Maven/JUnit teams and the solution became "by
> design". We can talk about a new concept and bind these parameters of
> course.
>
> Regarding the parallel execution has it's own logging problems in plugin on
> the top of JUnit5 engine but that's another issue you may be facing. We are
> approaching the fix step by step.
>
> Cheers
> Tibor
>
> On Tue, Feb 16, 2021 at 11:04 PM Jay Crosley  wrote:
>
> > I’m trying to get junit5 tests to run in parallel using the maven
> surefire
> > plugin, as described on
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.apache.org_surefire_maven-2Dsurefire-2Dplugin_examples_fork-2Doptions-2Dand-2Dparallel-2Dexecution.html=DwIFaQ=0hefKdg9jtsMu47wpF0ovg=qyxGgg8iek4zUTwPHqQd2x5bP20ZI2bxMqb2S9cASmw=M_2Gjt2FtuqAHQQ0HhrtLwLB6txc8A381wmGzx0q2jw=9y-T5guZoywkTqejMKcpEcM60c0Eg_HNafGvBD39cxM=
> .
> > Despite configuration that looks correct, I can’t get them to run in
> > parallel. I’ll paste my configuration and what I’ve tried and experienced
> > so far. Any help is greatly appreciated!
> >
> > My surefire plugin configuration looks like this:
> >
> >
> > 
> >   org.apache.maven.plugins
> >   maven-surefire-plugin
> >   2.21.0
> >   
> > 
> >   org.junit.platform
> >   junit-platform-surefire-provider
> >   1.2.0
> > 
> > 
> >   org.junit.jupiter
> >   junit-jupiter-engine
> >   5.2.0
> > 
> >   
> > 
> >
> > And I have a maven profile setup with additional configuration for our
> > integration tests, which includes the parallel configuration. The
> commented
> > out configurations indicate all the things I’ve tried.
> >
> >
> > 
> >   integration-tests-local
> >   
> > 
> >   
> > org.apache.maven.plugins
> > maven-surefire-plugin
> > ${surefire.version}
> > 
> >   classes
> >   4
> >   true
> >   
> >   
> >   
> >   
> >   
> >   false
> >   
> >   false
> >   
> > none
> >   
> >   
> > **/*IntegrationTests*.java
> >   
> > 
> >   
> > 
> >   
> >
> > The project is structured with a parent pom.xml and several sub-projects.
> > The tests are in the “integration-tests” module, which pulls in the
> > surefire plugin with no additional configuration:
> >
> >
> > 
> >   maven-surefire-plugin
> > 
> >
> > I mention the sub-project because it means that the maven command I’m
> > running looks like this (I’ve tried with/without the “-T”):
> >
> >
> > mvn -T 4 test -e -pl integration-tests -am -Pintegration-tests-local
> >
> > For the purposes of debugging, I’ve created 10 .java files named
> > TestIntegrationTests1.java through TestIntegrationTests10.java, each of
> > which has 10 unit tests all of which look like this:
> >
> >
> > package com.axon.scorpius.integration_tests;
> >
> > import static org.junit.jupiter.api.Assertions.assertTrue;
> >
> > import org.junit.jupiter.api.Test;
> >
> > /**
> >  * Tests.
> >  */
> > public class TestIntegrationTests1 {
> >
> >   @Test
> >   void test1() {
> > try {
> >   Thread.sleep(1000);
> > } catch (InterruptedException ex) {
> >   System.out.println("Interrupted exception: " + ex);
> > }
> >
> > assertTrue(true);

Re: Maven surefire plugin: parallel configuration not running tests in parallel

[Tibor Digana]

In case of combining JUnit5 and Surefire/Failsafe, the configuration
parameters e.g. "parallel" and "threadCountClasses" are not bound to the
native JUnit parameters "junit.jupiter.execution.parallel.enabled" because
it was an agreement between Maven/JUnit teams and the solution became "by
design". We can talk about a new concept and bind these parameters of
course.

Regarding the parallel execution has it's own logging problems in plugin on
the top of JUnit5 engine but that's another issue you may be facing. We are
approaching the fix step by step.

Cheers
Tibor

On Tue, Feb 16, 2021 at 11:04 PM Jay Crosley  wrote:

> I’m trying to get junit5 tests to run in parallel using the maven surefire
> plugin, as described on
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html.
> Despite configuration that looks correct, I can’t get them to run in
> parallel. I’ll paste my configuration and what I’ve tried and experienced
> so far. Any help is greatly appreciated!
>
> My surefire plugin configuration looks like this:
>
>
> 
>   org.apache.maven.plugins
>   maven-surefire-plugin
>   2.21.0
>   
> 
>   org.junit.platform
>   junit-platform-surefire-provider
>   1.2.0
> 
> 
>   org.junit.jupiter
>   junit-jupiter-engine
>   5.2.0
> 
>   
> 
>
> And I have a maven profile setup with additional configuration for our
> integration tests, which includes the parallel configuration. The commented
> out configurations indicate all the things I’ve tried.
>
>
> 
>   integration-tests-local
>   
> 
>   
> org.apache.maven.plugins
> maven-surefire-plugin
> ${surefire.version}
> 
>   classes
>   4
>   true
>   
>   
>   
>   
>   
>   false
>   
>   false
>   
> none
>   
>   
> **/*IntegrationTests*.java
>   
> 
>   
> 
>   
>
> The project is structured with a parent pom.xml and several sub-projects.
> The tests are in the “integration-tests” module, which pulls in the
> surefire plugin with no additional configuration:
>
>
> 
>   maven-surefire-plugin
> 
>
> I mention the sub-project because it means that the maven command I’m
> running looks like this (I’ve tried with/without the “-T”):
>
>
> mvn -T 4 test -e -pl integration-tests -am -Pintegration-tests-local
>
> For the purposes of debugging, I’ve created 10 .java files named
> TestIntegrationTests1.java through TestIntegrationTests10.java, each of
> which has 10 unit tests all of which look like this:
>
>
> package com.axon.scorpius.integration_tests;
>
> import static org.junit.jupiter.api.Assertions.assertTrue;
>
> import org.junit.jupiter.api.Test;
>
> /**
>  * Tests.
>  */
> public class TestIntegrationTests1 {
>
>   @Test
>   void test1() {
> try {
>   Thread.sleep(1000);
> } catch (InterruptedException ex) {
>   System.out.println("Interrupted exception: " + ex);
> }
>
> assertTrue(true);
>   }
>
>
>
> … 9 identical tests
>
> My hope is that when I run “mvn test” (I’m running locally in iTerm on a
> Macbook), these 10 test classes will run in parallel (at least partially),
> but they run serially, as seen here:
>
> INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests4
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.057 s - in com.axon.scorpius.integration_tests.TestIntegrationTests4
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests6
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.029 s - in com.axon.scorpius.integration_tests.TestIntegrationTests6
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests10
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.025 s - in com.axon.scorpius.integration_tests.TestIntegrationTests10
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests2
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.027 s - in com.axon.scorpius.integration_tests.TestIntegrationTests2
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests7
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.032 s - in com.axon.scorpius.integration_tests.TestIntegrationTests7
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests5
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.027 s - in com.axon.scorpius.integration_tests.TestIntegrationTests5
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests1
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.032 s - in 

Re: 'mvn clean test' crashes

[Tibor Digana]

Hi Mukul,

Sorry for my late reply.
I am checking pending emails.

Usually these errors appear in the test itself or the *libraries*.
As for instance, we found out that a Spring's library is implementing Kafka
stuff calling the "Runtime.getRuntime().halt(  )".
The same bad thing is to call the "System.exit()".
I have recognized this situation after I saw a crashed test in your logs.
The test is supposed to be crashed if the execution breaks abruptly without
receiving a JUnit/TestNG event about finishing the test, see this log:

*[ERROR] Crashed tests: [ERROR] com.haldiram.business.helper.t*
*est.SuspiciousActivityHelperTe**st*

T



On Tue, Jul 28, 2020 at 8:49 AM Mukul Gandhi  wrote:

> On Tue, Jul 7, 2020 at 5:49 PM Gary Gregory 
> wrote:
>
> > I've tried to deal with JVM crashes in the FailSafe (I was not having the
> > problem in SureFire) plugin by using:
> >
> >   
> > org.apache.maven.plugins
> > maven-failsafe-plugin
> > ${hmp.failsafe.version}
> > 
> >   1
> >   false
> > 
> >   
> >
>
> I also ran the command 'mvn verify', by exactly specifying above within my
> Maven project's pom.xml file (and specifying the version
> as 3.0.0-M5), and got the same kind of build failure
> errors, as I've mentioned in my previous post on this list.
>
> Any further thoughts, about how to solve the problems I'm facing as
> specified within this thread, would be appreciated.
>
>
>
> --
> Regards,
> Mukul Gandhi
>

Re: Surefire - Forking - Identifying Tests that run in a particular fork

[Tibor Digana]

Thank you Martin for your ideas.
I have expected this goal in the console logs.

Can you support us with implementing this feature?
To make it more simple for contributors we have the abstraction in a
separate module.
Can you upgrade the class SurefireConsoleOutputReporter and open a
pullrequest on GitHub?
There should be a boolean parameter which specifically enables this feature
so that it stays disabled by default as we keep the backwards compatibility
with the previous behavior.
The code has all data available, so this is a sandbox for you and it is
quite doable i would say.

Cheers
Tibor

On Wed, Jul 8, 2020 at 11:43 PM Martin Lambert
 wrote:

> Hi Tibor,
>
> Sorry it's taken a little while to get back to you.
>
> To set the scene, as basic requirements when running n tests serially I'd
> like to know...
>
> * When all pass: I'd mainly be interested in the fact that all tests
> passed, what tests ran and if any were skipped
> * If one or more tests failed: it seems reasonable to additionally be told
> which test(s) failed
> * If one or more tests failed and re-running a failed test individually
> did not reproduce a failure: it would be exceedingly helpful to also be
> able to see what tests ran before a failing test, including their output,
> in order to identify if prior tests were not cleaning up after themselves
>
> The reason for posting my original question was that when Surefire is
> configured to use forking, e.g. 8, then as far as I've
> been able to find out only the first 2 points above hold. To help visualise
> this, you could imagine getting console output something like:
>
> Running org.apache.maven.MyTest1
> Running org.apache.maven.MyTest32
> Running org.apache.maven.MyTest4
> Running org.apache.maven.MyTest77
> ~~ Output from test unknown
> ~~ Output from test unknown
> ~~ Output from test unknown
> ~~ Output from test unknown
> ~~ Output from test unknown
> ...
> Test finished: org.apache.maven.MyTest4 total: 6 success: 4 failure: 2
> skipped: 0
> ~~ Output from test unknown
> ~~ Output from test unknown
> Running org.apache.maven.MyTest2
> ...
>
> What I'm looking for is to be able to untangle this obfuscated log i.e.
> only look at the output for a single fork, and if necessary thread, thereby
> getting back to a similar place as running a set of tests serially. As an
> example, given the output below one could easily filter the output based on
> "[Fork 2]":
>
> [Fork 1] Running org.apache.maven.MyTest1
> [Fork 2] Running org.apache.maven.MyTest32
> [Fork 3] Running org.apache.maven.MyTest4
> [Fork 4] Running org.apache.maven.MyTest77
> [Fork 2] ~~ Output from test unknown
> [Fork 2] ~~ Output from test unknown
> [Fork 1] ~~ Output from test unknown
> [Fork 3] ~~ Output from test unknown
> [Fork 2] ~~ Output from test unknown
> ...
> [Fork 3]  Test finished: org.apache.maven.MyTest4 total: 6 success: 4
> failure: 2 skipped: 0
> [Fork 4] ~~ Output from test unknown
> [Fork 4] ~~ Output from test unknown
> [Fork 3]  Running org.apache.maven.MyTest2
> ...
>
> My current work around achieves something similar to the last example and
> uses:
> * The JUnit TestExecutionListener mechanism to supplement the existing
> JUnit / Surefire log lines with test start and end messages that include a
> given fork JVM's process id, this could easily be expanded to include the
> thread if needed
> * Changed my test logging code to also include a given fork JVM's process
> id; again thread could be included if needed
>
> I did look at the examples page, however, on reflection it seems that if
> the fork functionality doesn't provide a mechanism for this out of the box
> then it would be highly desirable for it to do so based on the reasons
> outlined; of course, if the fork mechanism already supports doing this then
> it would be great to hear how to configure Surefire in order to get this
> behaviour.
>
> Cheers,
>
> Martin.
>
> -Original Message-
> From: Tibor Digana 
> Sent: 05 July 2020 11:59
> To: martin.lambe...@ntlworld.com.invalid
> Cc: Maven Users List 
> Subject: Re: Surefire - Forking - Identifying Tests that run in a
> particular fork
>
> Hi Martin,
>
> Can you be more concrete with your business expectations?
> What logger, what kind of notations about forked JVM id you want to
> express in the logs or somewhere else?
>
> Maybe you are not aware of new features in Surefire and Failsafe, but we
> introduced Extensions API in 3.0.0-M4.
> This way you have a chance to implement the Extensions API as you like.
> It means that the features of loggers and wrapped configuration parameters
> can be customized by adding new

Re: 'mvn clean test' crashes

[Tibor Digana]

You use jdk11. The jpms was activated. Deactivate it with the workaround,
config param "useModulePath" set to "false".

Dňa ne 5. 7. 2020, 15:27 Tibor Digana  napísal(a):

> We do not provide a support. See the message properly. The test reports
> and dump files.
>
> Dňa st 1. 7. 2020, 7:09 Mukul Gandhi  napísal(a):
>
>> Hi all,
>> I've been facing some problem during last few weeks, when using the
>> 'mvn clean test' command to run unit tests within my Maven project. At
>> some
>> point before when this issue is creating problem for me, the 'mvn clean
>> test' command was working fine with me and all unit tests within my Maven
>> project were passing. But I'm yet unable to find the reason, why 'mvn
>> clean
>> test' command is not working for me now.
>>
>> When I run the command 'mvn clean test' now, my Maven build fails and
>> following error trace is emitted,
>>
>> [INFO] BUILD FAILURE
>> [INFO]
>> 
>> [INFO] Total time:  05:51 min
>> [INFO] Finished at: 2020-07-01T09:44:06+05:30
>> [INFO]
>> 
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test)
>> on project haldiram-restapis: There are test failures.
>> [ERROR]
>> [ERROR] Please refer to
>>
>> F:\eclipseWorkspaces\haldiram_backend_sprint-19_sts\haldiram-backend\haldiram-restapis\target\surefire-reports
>> for the individual test results.
>> [ERROR] Please refer to dump files (if any exist) [date].dump,
>> [date]-jvmRun[N].dump and [date].dumpstream.
>> [ERROR] The forked VM terminated without properly saying goodbye. VM crash
>> or System.exit called?
>> [ERROR] Command was cmd.exe /X /C "C:\jdk1.8.0_241\jre\bin\java -jar
>>
>> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817\surefirebooter5568422068326404815.jar
>> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817
>> 2020-07-01T09-38-42_797-jvmRun1 surefire5010876784124620015tmp
>> surefire_07470042422408053869tmp"
>> [ERROR] Process Exit Code: 0
>> [ERROR] Crashed tests:
>> [ERROR] com.haldiram.business.helper.test.ApplnHelperTest
>> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The
>> forked VM terminated without properly saying goodbye. VM crash or
>> System.exit called?
>> [ERROR] Command was cmd.exe /X /C "C:\jdk1.8.0_241\jre\bin\java -jar
>>
>> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817\surefirebooter5568422068326404815.jar
>> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817
>> 2020-07-01T09-38-42_797-jvmRun1 surefire5010876784124620015tmp
>> surefire_07470042422408053869tmp"
>> [ERROR] Process Exit Code: 0
>> [ERROR] Crashed tests:
>> [ERROR] com.haldiram.business.helper.test.ApplnHelperTest
>> [ERROR] at
>>
>> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
>> [ERROR] at
>>
>> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
>> [ERROR] at
>>
>> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
>> [ERROR] at
>>
>> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
>> [ERROR] at
>>
>> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
>> [ERROR] at
>>
>> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
>> [ERROR] at
>>
>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>> [ERROR] at
>>
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
>> [ERROR] at
>>
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
>> [ERROR] at
>>
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
>> [ERROR] at
>>
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>> [ERROR] at
>>
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>> [ERROR] at
>>
>> org.apache.maven.lifecycle.internal.builder.singlethreaded

Re: 'mvn clean test' crashes

[Tibor Digana]

We do not provide a support. See the message properly. The test reports and
dump files.

Dňa st 1. 7. 2020, 7:09 Mukul Gandhi  napísal(a):

> Hi all,
> I've been facing some problem during last few weeks, when using the
> 'mvn clean test' command to run unit tests within my Maven project. At some
> point before when this issue is creating problem for me, the 'mvn clean
> test' command was working fine with me and all unit tests within my Maven
> project were passing. But I'm yet unable to find the reason, why 'mvn clean
> test' command is not working for me now.
>
> When I run the command 'mvn clean test' now, my Maven build fails and
> following error trace is emitted,
>
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  05:51 min
> [INFO] Finished at: 2020-07-01T09:44:06+05:30
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test)
> on project haldiram-restapis: There are test failures.
> [ERROR]
> [ERROR] Please refer to
>
> F:\eclipseWorkspaces\haldiram_backend_sprint-19_sts\haldiram-backend\haldiram-restapis\target\surefire-reports
> for the individual test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash
> or System.exit called?
> [ERROR] Command was cmd.exe /X /C "C:\jdk1.8.0_241\jre\bin\java -jar
>
> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817\surefirebooter5568422068326404815.jar
> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817
> 2020-07-01T09-38-42_797-jvmRun1 surefire5010876784124620015tmp
> surefire_07470042422408053869tmp"
> [ERROR] Process Exit Code: 0
> [ERROR] Crashed tests:
> [ERROR] com.haldiram.business.helper.test.ApplnHelperTest
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The
> forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> [ERROR] Command was cmd.exe /X /C "C:\jdk1.8.0_241\jre\bin\java -jar
>
> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817\surefirebooter5568422068326404815.jar
> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817
> 2020-07-01T09-38-42_797-jvmRun1 surefire5010876784124620015tmp
> surefire_07470042422408053869tmp"
> [ERROR] Process Exit Code: 0
> [ERROR] Crashed tests:
> [ERROR] com.haldiram.business.helper.test.ApplnHelperTest
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
> [ERROR] at
>
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> [ERROR] at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [ERROR] at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
>
> 

Re: Surefire - Forking - Identifying Tests that run in a particular fork

[Tibor Digana]

Hi Martin,

Can you be more concrete with your business expectations?
What logger, what kind of notations about forked JVM id you want to express
in the logs or somewhere else?

Maybe you are not aware of new features in Surefire and Failsafe, but we
introduced Extensions API in 3.0.0-M4.
This way you have a chance to implement the Extensions API as you like.
It means that the features of loggers and wrapped configuration parameters
can be customized by adding new ones.
See the documentation
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#Surefire_Extensions_and_Reports_Configuration_for_.40DisplayName
It is maybe easier for the user due to now it is quite simple for the
contributor to concentrate on the abstraction which easily leads you to the
(default) implementation.

The extensions concerns anything, not only junit5.

Cheers
T

On Fri, Jul 3, 2020 at 9:25 AM Martin Lambert
 wrote:

> Hi Falko,
>
> Thanks for the suggestion. In the end I created a simple Junit
> TestExecutionListener class that overrode executionStarted() and
> executionFinished(); both methods have a TestIdentifier parameter, if this
> is actually an instance of MethodSource (
> https://junit.org/junit5/docs/current/api/org.junit.platform.engine/org/junit/platform/engine/support/descriptor/MethodSource.html)
> you can downcast it, this allows you can get hold of the test class' name
> using getClassName() on the same object; somewhere I was able to call an
> isTest() method to filter out noise - I can't remember where off the top of
> my head. To make the whole thing work you have to create a ServiceLoader
> file as mentioned in 6.1.4 here:
> https://junit.org/junit5/docs/current/user-guide/#launcher-api-listeners-custom
> (it really does just involve creating the specific file in the location
> mentioned, containing only the fully qualified name of your
> TestExecutionListener class  ).
>
> Cheers,
>
> Martin.
>
> -Original Message-
> From: Falko Modler 
> Sent: 01 July 2020 23:48
> To: users@maven.apache.org
> Subject: Re: Surefire - Forking - Identifying Tests that run in a
> particular fork
>
> Hi Martin,
>
> OOTB you'll probably have to resort to -X (which logs way too much) and
> even then I am not 100% sure you'll get what you need.
>
> Did you have a look at |${surefire.forkNumber}| (see
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
> )?
>
> I've been using this as a system property in my projects to:
>
> - write one logfile per fork (e.g. via Logback)
> - prefix each logged line with the fork number (also via Logback,
> especially useful for Jenins console log)
> - log each test method in a JUnit4 listener together with the log file
> (certainly also possible with JUnit5 etc.)
> - separate working directories, generate tracing ids etc.
>
> I can really recommend to take these extra measures, otherwise analyzing
> test failures with multiple forks and/or parallel modules (-T) will be a
> real pain in the long run.
>
> Cheers,
>
> Falko
>
> Am 02.07.2020 um 00:12 schrieb Martin Lambert:
> > Hello,
> >
> >
> >
> > I'm currently using the Surefire plugin with Maven 3.6.3 and would
> > like to know if there is any way to identify what tests were run in a
> > given fork? I haven't seen any option for it in the current
> > documentation. I'm running around ~10K test cases hence using the fork
> > option to speed things up. The problem I'm trying to solve is that a
> > single test intermittently fails, which, when run individually
> > succeeds; I suspect this is due to a prior test case not cleaning up
> > properly and would therefore like to be able to identify at a minimum
> > what test cases are in a fork group so that I can take a divide and
> > conquer approach to resolving the issue, even better would be to know
> which test cases ran before the failing test case.
> >
> >
> >
> > Thanks for your help,
> >
> >
> >
> > Martin.
> >
> >
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Re[2]: How does surefire 3.0.0-M5 run JPMS with junit5?

[Tibor Digana]

I think you are talking about the issue
https://issues.apache.org/jira/browse/SUREFIRE-1809
See the last comment, the workaround is to set
false in plugin config.
Of course this is a temporal workaround.

I have understood the title of the message as you are a fan of JPMS.
T



On Fri, Jul 3, 2020 at 5:41 PM Alex Orlov  wrote:

> Hi Tibor,
>
> Thank you for your answer. I’ve read the link you provided but didn’t find
> the
> answer to my question. I don’t have any questions about how to run jpms
> tests.
> I can’t understand how tests are executed without junit platform in boot
> layer.
> As I understand we have the following chain:
> maven → surefire → junit-platform-launcher → junit-platform-engine.
>
> However, I can’t find maven, surefire, launcher, engine in boot layer. How
> does it work? Could you explain what magic I miss?
>
> Alex
>
> Пятница, 3 июля 2020, 17:40 +03:00 от Tibor Digana  >:
>
> Hi Alex,
>
> This is the documentation regarding this topic
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html
> and you can see the links with the integration tests for TestNG, JUnit4
> and JUnit5.
> These tests use JPMS in main and tests as well. You should be able to
> access "org.junit" packages of course.
> The class-path may be empty, or it contains only surefire libraries.
>
> Try to copy the ITs and try to run "mvn test". It should work for you.
>
> Cheers
> T
>
>
> On Fri, Jul 3, 2020 at 2:57 PM Alex Orlov  <http:///compose?To=ooo_satu...@mail.ru.invalid>> wrote:
>
>
> Hi all,
>
> I want to understand how surefire 3.0.0-M5 run JPMS with junit5. When I
> run my
> tests on boot layer I see only two junit modules:
>
> org.junit.jupiter.api
> org.junit.platform.commons
>
> And there is no platform, no engine. Besides "java.class.path" is empty.
> Could anyone
> explain where is platform, engine etc.
>
> --
> Alex Orlov
>
>
>
> --
> Alex Orlov
>
>

Re: How does surefire 3.0.0-M5 run JPMS with junit5?

[Tibor Digana]

Hi Alex,

This is the documentation regarding this topic
https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html
and you can see the links with the integration tests for TestNG, JUnit4 and
JUnit5.
These tests use JPMS in main and tests as well. You should be able to
access "org.junit" packages of course.
The class-path may be empty, or it contains only surefire libraries.

Try to copy the ITs and try to run "mvn test". It should work for you.

Cheers
T


On Fri, Jul 3, 2020 at 2:57 PM Alex Orlov 
wrote:

>
> Hi all,
>
> I want to understand how surefire 3.0.0-M5 run JPMS with junit5. When I
> run my
> tests on boot layer I see only two junit modules:
>
> org.junit.jupiter.api
> org.junit.platform.commons
>
> And there is no platform, no engine. Besides "java.class.path" is empty.
> Could anyone
> explain where is platform, engine etc.
>
> --
> Alex Orlov

Re: maven failsafe plugin & POJO tests

[Tibor Digana]

Hi Nigel,

I wrote a project for you
https://github.com/Tibor17/pojo-testing

It is related to the JUnit POJO testing with Maven Failsafe Plugin.
I guess you did not use the expected postfix. That's why there were 0 tests
to run.
Additionally, README file shows the command line example with filtering the
test.
btw, The postfix can be customized by the configuration.

Cheers
Tibor




On Thu, Jul 2, 2020 at 9:44 PM Nigel Jones  wrote:

>
>
> On 2020/07/02 19:08:26, Nigel Jones  wrote:
>
> > What is odd though is that the class 'GlossaryFVT' itself isn't showing
> up in the Tests run line -- even with the includes in place. Yet other
> files like 'FVTContants' are. This I don't understand - before I get to the
> methods (though once found, the static methods observation is very
> valuable. )
>
> From a quick test, it does seem that if I convert to a JUnit5 test I don't
> have an issue in getting tests run - seems specific to the pojo tests. I
> may work on that tomorrow.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: (Negative) impact of Jansi

[Tibor Digana]

>> we started seeing Surefire JVM fork crashes on various Windows 10
workstations when Jansi was active

Can you show me the log how it crashed, and maybe the dump file from
target/surefire-reports?

On Sun, Jun 28, 2020 at 7:29 PM Falko Modler  wrote:

> Hi everyone!
>
> I recently ran into problems when trying to get colored log output from
> Quarkus tests (via Surefire):
> https://github.com/fusesource/jansi/issues/171
>
> Coincidentally, we started seeing Surefire JVM fork crashes on various
> Windows 10 workstations when Jansi was active (sorry, I do not have more
> details at the moment).
>
> I also found out that building Quarkus (651 modules) is 40% faster with
> -Djansi.passthrough=true (using Git Bash on Windows 10 & TERM=cygwin,
> and I guess also with xterm-256color).
>
> Given these three observations, I am wondering whether it would be
> better if Maven actively used -Djansi.passthrough=true for TERM variants
> that are known to handle coloring on their own?
> Or at least document this?
>
> Best regards,
>
> Falko
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[ANN] Apache Maven Surefire Plugin 3.0.0-M5 Released

[Tibor Digana]

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

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

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

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


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


or for failsafe:


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


or for surefire-report:


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



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

Release Notes - Maven Surefire - Version 3.0.0-M5


Bug

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

New Feature

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

Improvement

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

Re: Surefire 3.0.0-M4 not failing build on errors

[Tibor Digana]

Now we are able to handle the errors on the class level.
Before in 2.22.x and in M4 we handled the test errors only and ignored the
class level errors.

I would trust NoClassDefFoundError because ControllerAdvice really could
not be found in IntelliJ IDEA.
So the IDE is telling me the same thing, and this is perhaps the root cause
for NoSuchBeanDefinitionException. You know your application better than
me.

Even if i use the IntelliJ IDEA and run the tests, i get the same error on
the console:

Test ignored.

*java.lang.NoClassDefFoundError:
org/springframework/web/bind/annotation/ControllerAdvice*
at
org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTypeExcludeFilter.(WebMvcTypeExcludeFilter.java:59)
...
Suppressed: java.lang.NoClassDefFoundError: Could not initialize class
org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTypeExcludeFilter
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
...
Caused by: java.lang.ClassNotFoundException:
org.springframework.web.bind.annotation.ControllerAdvice
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:604)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 61 more








On Sat, Jun 13, 2020 at 10:51 PM Jeff Jensen  wrote:

> Great news that it fails!  Thank you Tibor.
>
> I note it emits a different exception than with 2.22.2 or running in IDE.
> 2.22.2 emits an IllegalStateException with root
> NoSuchBeanDefinitionException but per below M5 emits NoClassDefFoundError.
> Is this ok because you changed something locally or is this a concern?
>
>
> On Sat, Jun 13, 2020 at 12:47 PM Tibor Digana 
> wrote:
>
> > We have changed the resolution of junit5 engines 2 times.
> > Now I have got the result with 3.0.0-M5. I think it is what you expect:
> >
> > [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @
> > surefire-no-build-fail ---
> > [INFO]
> > [INFO] ---
> > [INFO]  T E S T S
> > [INFO] ---
> > [INFO] Running com.jeffjensen.surefire.ApplicationTest
> > 19:43:18.789 [main] DEBUG
> org.springframework.test.context.BootstrapUtils -
> > Instantiating CacheAwareContextLoaderDelegate from class
> >
> >
> [org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate]
> > 19:43:18.821 [main] DEBUG
> org.springframework.test.context.BootstrapUtils -
> > Instantiating BootstrapContext using constructor [public
> >
> >
> org.springframework.test.context.support.DefaultBootstrapContext(java.lang.Class,org.springframework.test.context.CacheAwareContextLoaderDelegate)]
> > 19:43:18.910 [main] DEBUG
> org.springframework.test.context.BootstrapUtils -
> > Instantiating TestContextBootstrapper for test class
> > [com.jeffjensen.surefire.ApplicationTest] from class
> >
> >
> [org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTestContextBootstrapper]
> > 19:43:18.944 [main] INFO
> >
> >
> org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTestContextBootstrapper
> > - Neither @ContextConfiguration nor @ContextHierarchy found for test
> class
> > [com.jeffjensen.surefire.ApplicationTest], using SpringBootContextLoader
> > 19:43:18.951 [main] DEBUG
> > org.springframework.test.context.support.AbstractContextLoader - Did not
> > detect default resource location for test class
> > [com.jeffjensen.surefire.ApplicationTest]: class path resource
> > [com/jeffjensen/surefire/ApplicationTest-context.xml] does not exist
> > 19:43:18.952 [main] DEBUG
> > org.springframework.test.context.support.AbstractContextLoader - Did not
> > detect default resource location for test class
> > [com.jeffjensen.surefire.ApplicationTest]: class path resource
> > [com/jeffjensen/surefire/ApplicationTestContext.groovy] does not exist
> > 19:43:18.952 [main] INFO
> > org.springframework.test.context.support.AbstractContextLoader - Could
> not
> > detect default resource locations for test class
> > [com.jeffjensen.surefire.ApplicationTest]: no resource found for suffixes
> > {-context.xml, Context.groovy}.
> > 19:43:18.953 [main] INFO
> >
> org.springfr

Re: Surefire 3.0.0-M4 not failing build on errors

[Tibor Digana]

We have changed the resolution of junit5 engines 2 times.
Now I have got the result with 3.0.0-M5. I think it is what you expect:

[INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @
surefire-no-build-fail ---
[INFO]
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running com.jeffjensen.surefire.ApplicationTest
19:43:18.789 [main] DEBUG org.springframework.test.context.BootstrapUtils -
Instantiating CacheAwareContextLoaderDelegate from class
[org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate]
19:43:18.821 [main] DEBUG org.springframework.test.context.BootstrapUtils -
Instantiating BootstrapContext using constructor [public
org.springframework.test.context.support.DefaultBootstrapContext(java.lang.Class,org.springframework.test.context.CacheAwareContextLoaderDelegate)]
19:43:18.910 [main] DEBUG org.springframework.test.context.BootstrapUtils -
Instantiating TestContextBootstrapper for test class
[com.jeffjensen.surefire.ApplicationTest] from class
[org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTestContextBootstrapper]
19:43:18.944 [main] INFO
org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTestContextBootstrapper
- Neither @ContextConfiguration nor @ContextHierarchy found for test class
[com.jeffjensen.surefire.ApplicationTest], using SpringBootContextLoader
19:43:18.951 [main] DEBUG
org.springframework.test.context.support.AbstractContextLoader - Did not
detect default resource location for test class
[com.jeffjensen.surefire.ApplicationTest]: class path resource
[com/jeffjensen/surefire/ApplicationTest-context.xml] does not exist
19:43:18.952 [main] DEBUG
org.springframework.test.context.support.AbstractContextLoader - Did not
detect default resource location for test class
[com.jeffjensen.surefire.ApplicationTest]: class path resource
[com/jeffjensen/surefire/ApplicationTestContext.groovy] does not exist
19:43:18.952 [main] INFO
org.springframework.test.context.support.AbstractContextLoader - Could not
detect default resource locations for test class
[com.jeffjensen.surefire.ApplicationTest]: no resource found for suffixes
{-context.xml, Context.groovy}.
19:43:18.953 [main] INFO
org.springframework.test.context.support.AnnotationConfigContextLoaderUtils
- Could not detect default configuration classes for test class
[com.jeffjensen.surefire.ApplicationTest]: ApplicationTest does not declare
any static, non-private, non-final, nested classes annotated with
@Configuration.
19:43:19.024 [main] DEBUG org.springframework.test.context.BootstrapUtils -
Instantiating CacheAwareContextLoaderDelegate from class
[org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate]
19:43:19.024 [main] DEBUG org.springframework.test.context.BootstrapUtils -
Instantiating BootstrapContext using constructor [public
org.springframework.test.context.support.DefaultBootstrapContext(java.lang.Class,org.springframework.test.context.CacheAwareContextLoaderDelegate)]
19:43:19.025 [main] DEBUG org.springframework.test.context.BootstrapUtils -
Instantiating TestContextBootstrapper for test class
[com.jeffjensen.surefire.ApplicationTest] from class
[org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTestContextBootstrapper]
19:43:19.026 [main] INFO
org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTestContextBootstrapper
- Neither @ContextConfiguration nor @ContextHierarchy found for test class
[com.jeffjensen.surefire.ApplicationTest], using SpringBootContextLoader
19:43:19.027 [main] DEBUG
org.springframework.test.context.support.AbstractContextLoader - Did not
detect default resource location for test class
[com.jeffjensen.surefire.ApplicationTest]: class path resource
[com/jeffjensen/surefire/ApplicationTest-context.xml] does not exist
19:43:19.028 [main] DEBUG
org.springframework.test.context.support.AbstractContextLoader - Did not
detect default resource location for test class
[com.jeffjensen.surefire.ApplicationTest]: class path resource
[com/jeffjensen/surefire/ApplicationTestContext.groovy] does not exist
19:43:19.029 [main] INFO
org.springframework.test.context.support.AbstractContextLoader - Could not
detect default resource locations for test class
[com.jeffjensen.surefire.ApplicationTest]: no resource found for suffixes
{-context.xml, Context.groovy}.
19:43:19.029 [main] INFO
org.springframework.test.context.support.AnnotationConfigContextLoaderUtils
- Could not detect default configuration classes for test class
[com.jeffjensen.surefire.ApplicationTest]: ApplicationTest does not declare
any static, non-private, non-final, nested classes annotated with
@Configuration.
19:43:19.035 [main] DEBUG org.springframework.test.context.BootstrapUtils -
Instantiating CacheAwareContextLoaderDelegate from class
[org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate]
19:43:19.035 [main] DEBUG 

Re: Surefire 3.0.0-M4 not failing build on errors

[Tibor Digana]

Can you upload the project, dump file and log to the gist?
I am sure it has nothing to do with the spring.
run with:
mvn test -X -e

On Sat, Jun 13, 2020 at 12:15 AM Jeff Jensen <
jeffjen...@upstairstechnology.com> wrote:

> I looked for this issue in JIRA but haven't found anything yet.  Anyone
> know if this has been reported and/or fixed?
>
> Our scenario is a failure occurs at startup of tests but Surefire doesn't
> fail the build.  Specifically, Spring controller tests aren't failing when
> there is a Spring configuration problem.
>
> Spring top-level thrown exception is:
>   java.lang.IllegalStateException: Failed to load ApplicationContext
>
> but Surefire doesn't report fail.  Surefire output results is:
>   Tests run: 0, Failures: 0, Errors: 0, Skipped: 0,
>
> Running the tests in an IDE correctly fail for the setup problem.
>

Re: Maven Surefire Forked Test Execution in a multimodule project

[Tibor Digana]

Enrico is right.

Surefire does NOT execute 3 Maven modules in parallel.
Opposite!
One module executes Surefire which divides the test into 3 additional
JVMs and the Surefire (module) is waiting for their completion.

On Thu, Apr 9, 2020 at 1:09 PM Debraj Manna  wrote:
>
> Hi
>
> I am reading the maven surefire documentation
> 
> about
> the forked test execution. It states
>
> *The default setting is forkCount=1/reuseForks=true, which means that
> maven-surefire-plugin creates one new JVM process to execute all tests in
> one Maven module.*
>
> *forkCount=1/reuseForks=false executes each test class in its own JVM
> process, one after another. It creates the highest level of separation for
> the test execution, but it would probably also give you the longest
> execution time of all the available options. Consider it as a last reso*rt.
>
>
> Can someone resolve my below doubts about the above para:
>
> In a maven multimodule project if I am setting forkcount=3 /
> reuseForks=true. Then does that mean maven-surefire-plugin will create 3
> new JVM processes and then execute tests from 3 modules in 3 JVM and all
> tests from a module will be running in the same JVM?



-- 
Cheers
Tibor

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

Re: Build Failed

[Tibor Digana]

Enable the debug logs in Maven (i.e. mvn -X install) and read the logs
around when Downloading...
You may find the root cause this way.
T

On Thu, Mar 19, 2020 at 12:53 PM Robert Manikonda 
wrote:

> Hi
>  Please check the attached error and im unable to build maven project
>
> Thanks
>
> Br//
> Robert M
> --
>
>
>
>
> Thanks & Regards
> Robert Manikonda
> 7013207511
>

Re: maven surefire report does not pick up message published by JUnit5-TestReporter

[Tibor Digana]

The TestReporter is not supported yet.
Currently, in M5, we are fixing the process communication via pipes and TCP.
Then we will work on this issue in M6 as well.

Meanwhile please use SLF4J logger or another one.

On Wed, Jan 15, 2020 at 8:45 AM Knoche, Heinz 
wrote:

> I uploaded this simple project to illustrate the subject:
> https://github.com/gabalawi/junit5-testreporter
>
> Maybe someone could help me with clarifying
> - if there is a bug or lacking feature in the surefire plugin
> - or if I did not properly configure the surefire plugin
> - or if it is up to another plugin (maven-reporting?) to pick up the
> TestReporter's publications
> - or if I have some misunderstanding about the TestReporter intentions
> usage at all
>
> Thank you very much in advance, kind regards,
> Heinz
>
>
> --
>
> Heinz Knoche
> Consultant
> Development
> Public Authorities Web & Application Security
> secunet Security Networks AG
>
>
> www.secunet.com
>

Re: Take threaddump on hung surefire tests

[Tibor Digana]

This thread dump already exists in the version 3.0.0-M4.
https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java#L283
See the dump file for the particular JVM in /target/surefire-reports

On Mon, Dec 9, 2019 at 6:29 PM Debraj Manna 
wrote:

> Thanks again Tibor.
>
> One more question is it possible to get a thread dump before failing the
> build when forkedProcessTimeoutInSeconds
> <
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkedProcessTimeoutInSeconds
> >
> is
> reached?
>
> On Mon, Dec 9, 2019 at 4:38 PM Tibor Digana 
> wrote:
>
> >  fixed typo:If your Jenkins sends SIGKILL to the Maven process then
> enable
> > the process checker, see more details in the documentaion:
> >
> >
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#enableProcessChecker
> >
> >
> http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#enableProcessChecker
> >
> > On Mon, Dec 9, 2019 at 12:01 PM Tibor Digana 
> > wrote:
> >
> > > Hi Debraj,
> > >
> > > >> to fail the build immediately when timeout is reached
> > >
> > > This feature exists for years:
> > >
> > >
> >
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkedProcessTimeoutInSeconds
> > >
> > >
> >
> http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#forkedProcessTimeoutInSeconds
> > >
> > > >> to fail the ... when someone presses abort button on the jenkins
> > >
> > > This also exists with several alternatives (changed across the
> versions).
> > > See the detailed page
> > >
> >
> http://maven.apache.org/surefire/maven-failsafe-plugin/examples/shutdown.html
> > >
> > > If your Jenkins sends the SIGTERM signal into the Maven process (same
> as
> > > CTRL+C) then the standard input stream in process pipe becomes closed
> and
> > > the EOFException is caugh byt the forked JVM and shutdown is called:
> > >
> > >
> >
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#shutdown
> > >
> > >
> >
> maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#shutdown
> > > If you want to kill the JVM, you can reconfigure the default behavior.
> > >
> > > If your Jenkins sends SIGTERM to the Maven process then enable the
> > process
> > > checker, see more details in the documentaion:
> > >
> > >
> >
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#enableProcessChecker
> > >
> > >
> >
> http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#enableProcessChecker
> > >
> > > Did it help?
> > >
> > > Here is the FAQ:
> > > http://maven.apache.org/surefire/maven-failsafe-plugin/faq.html
> > >
> > > Feel free to ask any questions if you have a problem with this topic.
> > >
> > >
> > > Cheers
> > > Tibor17
> > >
> > >
> > > On Mon, Dec 9, 2019 at 3:40 AM Debraj Manna 
> > > wrote:
> > >
> > >> No Tibor.  I am not getting much time to spend on this. For new
> classes
> > i
> > >> have been using Timeout rule for now.
> > >>
> > >> One more question in a multi-module project is it possible to fail the
> > >> build immediately when timeout is reached and in other failure cases
> > fail
> > >> in the end. I am using Jenkins so here fail-on-end is set to true. Is
> it
> > >> possible to do this?
> > >>
> > >>
> > >> On Fri, 22 Nov 2019, 02:51 Tibor Digana, 
> > wrote:
> > >>
> > >> > Hi Debraj,
> > >> >
> > >> > It's over one month when you wrote this email.
> > >> > How did you solve this issue, did you find the real root cause?
> > >> > Let us know how you are doing, thx!
> > >> > btw, we released the new version 3.0.0-M4 in Nov/17.
> > >> >
> > >> > Cheers
> > >> > Tibor17
> > >> >
> > >> >
> > >> >
> > >> > On Thu, Oct 3, 2019 at 2:49 PM Debraj Manna <
> subharaj.ma...@gmail.com
> > >
> > >> > wrote:
> > >> >
> > >> > > Sometimes I have maven surefire tests that get hung, due to either
> > >> races
> > >> > or
> > >> > > deadlocks.
> > >> > >
> > >> > > When this happens I have to discover what slave is being used, and
> > >> then I
> > >> > > have to log on that slave, sudo to jenkins account and execute
> > either
> > >> > > jstack or kill -3
> > >> > >
> > >> > > I am looking for a simple solution like doing jstack / kill -3
> when
> > >> > someone
> > >> > > presses abort button on the jenkins.
> > >> > >
> > >> > > Can someone suggest how can I automate this or some better way of
> > >> > handling
> > >> > > this?
> > >> > >
> > >> >
> > >>
> > >
> >
>

Re: Tests not running on Maven

[Tibor Digana]

Hi Jeronimo,

The old version of Surefire and Failsafe required to have the Junit5 engine
in the test dependency.

But you do not have to declare it if you use the version 3.0.0-M4.
It's enough to have only Junit Jupiter API in the test dependency.
The plugin will find out the engine from Junit5.

btw, pls remove the dependency with the artifactId: surefire-junit47.

As Karl has explained, see the documentation in [1]. This should help.

If you have any problem, feel free to reply.

Cheers
Tibor17

On Mon, Dec 9, 2019 at 2:12 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> first you have to use junit-jupiter-engine[1] instead of api apart from
> that you won't be able to get that running cause JUnit Jupiter requires
> JDK8+ (see [2]).
>
> furthermore dependencies to junit provider is simply not needed cause
> this is automatically done by maven-surefire/maven-failsafe-plugin...
>
> Kind regards
> Karl Heinz Marbaise
>
> [1]:
>
> http://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
> [2]:
> https://junit.org/junit5/docs/current/user-guide/#overview-java-versions
>
> On 09.12.19 13:31, Jeronimo wrote:
> > Hi,
> >
> > I am using Maven 3.6
> >
> > $ mvn -version
> > Apache Maven 3.6.0
> > Maven home: /usr/share/maven
> > Java version: 11.0.4, vendor: Ubuntu, runtime:
> > /usr/lib/jvm/java-11-openjdk-amd64
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.0.0-37-generic", arch: "amd64", family:
> "unix"
> >
> > My pom.xml seems like this:
> > $ cat pom.xml
> > 
> >
> > http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> > http://www.w3.org/2001/XMLSchema-instance;
> >xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> >4.0.0
> >
> >br.edu.ifrs
> >totalinventory
> >1.0-SNAPSHOT
> >war
> >
> >totalinventory Maven Webapp
> >http://www.poa.ifrs.edu.br
> >
> >
> >  UTF-8
> >  1.7
> >  1.7
> >
> >
> >
> >  
> >junit
> >junit
> >4.11
> >test
> >  
> >  
> >org.junit.jupiter
> >junit-jupiter-api
> >5.5.2
> >test
> >  
> >  
> >  javax.persistence
> >  javax.persistence-api
> >  2.2
> >  
> >  
> >  javax.ejb
> >  ejb-api
> >  3.0
> >  provided
> >  
> >  
> >  javax.ws.rs
> >  javax.ws.rs-api
> >  2.1.1
> >  
> >  
> >  javax.annotation
> >  javax.annotation-api
> >  1.3.2
> >  
> >  
> >org.apache.maven.surefire
> >surefire-junit47
> >2.22.1
> >  
> >
> >
> >
> >  totalinventory
> >  
> >
> >  
> >maven-clean-plugin
> >3.1.0
> >  
> >  
> >  
> >maven-resources-plugin
> >3.0.2
> >  
> >  
> >maven-compiler-plugin
> >3.8.0
> >  
> >  
> >maven-surefire-plugin
> >2.22.1
> >  
> >  
> >org.apache.maven.plugins
> >maven-failsafe-plugin
> >2.22.1
> >  
> >  
> >maven-war-plugin
> >3.2.2
> >  
> >  
> >maven-install-plugin
> >2.5.2
> >  
> >  
> >maven-deploy-plugin
> >2.8.2
> >  
> >
> >  
> >
> > 
> >
> >
> > When trying to execute JUnit testes:
> > $ mvn clean test
> > [INFO] Scanning for projects...
> > [INFO]
> > [INFO] -< br.edu.ifrs:totalinventory
> >> -
> > [INFO] Building totalinventory Maven Webapp 1.0-SNAPSHOT
> > [INFO] [ war
> > ]-
> > [INFO]
> > [INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @
> totalinventory
> > ---
> > [INFO] Deleting
> /home/jeronimo/Documents/maven-testes/totalinventory/target
> > [INFO]
> > [INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @
> > totalinventory ---
> > [INFO] Using 'UTF-8' encoding to copy filtered resources.
> > [INFO] Copying 1 resource
> > [INFO]
> > [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @
> > totalinventory ---
> > [INFO] Changes detected - recompiling the module!
> > [INFO] Compiling 5 source files to
> > /home/jeronimo/Documents/maven-testes/totalinventory/target/classes
> > [INFO]
> > [INFO] --- maven-resources-plugin:3.0.2:testResources
> > (default-testResources) @ totalinventory ---
> > [INFO] Using 'UTF-8' encoding to copy filtered resources.
> > [INFO] skip non existing resourceDirectory
> > /home/jeronimo/Documents/maven-testes/totalinventory/src/test/resources
> > [INFO]
> > [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile)
> @
> > totalinventory ---
> > [INFO] Changes detected - recompiling the module!
> > [INFO] *Compiling 1 source 

Re: Take threaddump on hung surefire tests

[Tibor Digana]

 fixed typo:If your Jenkins sends SIGKILL to the Maven process then enable
the process checker, see more details in the documentaion:
http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#enableProcessChecker
http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#enableProcessChecker

On Mon, Dec 9, 2019 at 12:01 PM Tibor Digana  wrote:

> Hi Debraj,
>
> >> to fail the build immediately when timeout is reached
>
> This feature exists for years:
>
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkedProcessTimeoutInSeconds
>
> http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#forkedProcessTimeoutInSeconds
>
> >> to fail the ... when someone presses abort button on the jenkins
>
> This also exists with several alternatives (changed across the versions).
> See the detailed page
> http://maven.apache.org/surefire/maven-failsafe-plugin/examples/shutdown.html
>
> If your Jenkins sends the SIGTERM signal into the Maven process (same as
> CTRL+C) then the standard input stream in process pipe becomes closed and
> the EOFException is caugh byt the forked JVM and shutdown is called:
>
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#shutdown
>
> maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#shutdown
> If you want to kill the JVM, you can reconfigure the default behavior.
>
> If your Jenkins sends SIGTERM to the Maven process then enable the process
> checker, see more details in the documentaion:
>
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#enableProcessChecker
>
> http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#enableProcessChecker
>
> Did it help?
>
> Here is the FAQ:
> http://maven.apache.org/surefire/maven-failsafe-plugin/faq.html
>
> Feel free to ask any questions if you have a problem with this topic.
>
>
> Cheers
> Tibor17
>
>
> On Mon, Dec 9, 2019 at 3:40 AM Debraj Manna 
> wrote:
>
>> No Tibor.  I am not getting much time to spend on this. For new classes i
>> have been using Timeout rule for now.
>>
>> One more question in a multi-module project is it possible to fail the
>> build immediately when timeout is reached and in other failure cases fail
>> in the end. I am using Jenkins so here fail-on-end is set to true. Is it
>> possible to do this?
>>
>>
>> On Fri, 22 Nov 2019, 02:51 Tibor Digana,  wrote:
>>
>> > Hi Debraj,
>> >
>> > It's over one month when you wrote this email.
>> > How did you solve this issue, did you find the real root cause?
>> > Let us know how you are doing, thx!
>> > btw, we released the new version 3.0.0-M4 in Nov/17.
>> >
>> > Cheers
>> > Tibor17
>> >
>> >
>> >
>> > On Thu, Oct 3, 2019 at 2:49 PM Debraj Manna 
>> > wrote:
>> >
>> > > Sometimes I have maven surefire tests that get hung, due to either
>> races
>> > or
>> > > deadlocks.
>> > >
>> > > When this happens I have to discover what slave is being used, and
>> then I
>> > > have to log on that slave, sudo to jenkins account and execute either
>> > > jstack or kill -3
>> > >
>> > > I am looking for a simple solution like doing jstack / kill -3 when
>> > someone
>> > > presses abort button on the jenkins.
>> > >
>> > > Can someone suggest how can I automate this or some better way of
>> > handling
>> > > this?
>> > >
>> >
>>
>

Re: Take threaddump on hung surefire tests

[Tibor Digana]

Hi Debraj,

>> to fail the build immediately when timeout is reached

This feature exists for years:
http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkedProcessTimeoutInSeconds
http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#forkedProcessTimeoutInSeconds

>> to fail the ... when someone presses abort button on the jenkins

This also exists with several alternatives (changed across the versions).
See the detailed page
http://maven.apache.org/surefire/maven-failsafe-plugin/examples/shutdown.html

If your Jenkins sends the SIGTERM signal into the Maven process (same as
CTRL+C) then the standard input stream in process pipe becomes closed and
the EOFException is caugh byt the forked JVM and shutdown is called:
http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#shutdown
maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#shutdown
If you want to kill the JVM, you can reconfigure the default behavior.

If your Jenkins sends SIGTERM to the Maven process then enable the process
checker, see more details in the documentaion:
http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#enableProcessChecker
http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#enableProcessChecker

Did it help?

Here is the FAQ:
http://maven.apache.org/surefire/maven-failsafe-plugin/faq.html

Feel free to ask any questions if you have a problem with this topic.


Cheers
Tibor17


On Mon, Dec 9, 2019 at 3:40 AM Debraj Manna 
wrote:

> No Tibor.  I am not getting much time to spend on this. For new classes i
> have been using Timeout rule for now.
>
> One more question in a multi-module project is it possible to fail the
> build immediately when timeout is reached and in other failure cases fail
> in the end. I am using Jenkins so here fail-on-end is set to true. Is it
> possible to do this?
>
>
> On Fri, 22 Nov 2019, 02:51 Tibor Digana,  wrote:
>
> > Hi Debraj,
> >
> > It's over one month when you wrote this email.
> > How did you solve this issue, did you find the real root cause?
> > Let us know how you are doing, thx!
> > btw, we released the new version 3.0.0-M4 in Nov/17.
> >
> > Cheers
> > Tibor17
> >
> >
> >
> > On Thu, Oct 3, 2019 at 2:49 PM Debraj Manna 
> > wrote:
> >
> > > Sometimes I have maven surefire tests that get hung, due to either
> races
> > or
> > > deadlocks.
> > >
> > > When this happens I have to discover what slave is being used, and
> then I
> > > have to log on that slave, sudo to jenkins account and execute either
> > > jstack or kill -3
> > >
> > > I am looking for a simple solution like doing jstack / kill -3 when
> > someone
> > > presses abort button on the jenkins.
> > >
> > > Can someone suggest how can I automate this or some better way of
> > handling
> > > this?
> > >
> >
>

Re: Take threaddump on hung surefire tests

[Tibor Digana]

Hi Debraj,

It's over one month when you wrote this email.
How did you solve this issue, did you find the real root cause?
Let us know how you are doing, thx!
btw, we released the new version 3.0.0-M4 in Nov/17.

Cheers
Tibor17



On Thu, Oct 3, 2019 at 2:49 PM Debraj Manna 
wrote:

> Sometimes I have maven surefire tests that get hung, due to either races or
> deadlocks.
>
> When this happens I have to discover what slave is being used, and then I
> have to log on that slave, sudo to jenkins account and execute either
> jstack or kill -3
>
> I am looking for a simple solution like doing jstack / kill -3 when someone
> presses abort button on the jenkins.
>
> Can someone suggest how can I automate this or some better way of handling
> this?
>

Re: java 1.8 and java 11 using toolchains plus compiler and surefire

[Tibor Digana]

Hi John,

Have you used the version 3.0.0-M4?
There were important fixes for Java 11/Linux (alt. Docker).
The message "The forked VM terminated without properly saying goodbye." is
too general error message.
Can you post the configuration of the plugin with the latest version in
your POM including the test summary? What provider you use?

Cheers
Tibor17



On Sat, Aug 31, 2019 at 7:53 PM John Patrick  wrote:

> evening,
>
> i'm having trouble testing a multi-release jar project using
> toolchains. i want to test it using both java 1.8 and java 11.
>
> i've the following structure;
> src/main/java
> src/main/java11
> src/test/java
> src/test/java11
>
> tried both maven-surefire-plugin v 2.22.2 and 3.0.0-M3
>
> if i set java to 1.8 and do mvn clean install, everything works but it
> uses java 1.8 for the testing.
>
> if i set java to 11 and do maven clean install, it fails starting surefire.
>
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException:
> The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
>
> How can I test using java 1.8 then execute tests again using java 11.
>
> What profile or toolchain settings can i configure so for a surefire
> execution it uses the java version i choose?
>
> John
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[ANN] Apache Maven Surefire Plugin 3.0.0-M4 Released

[Tibor Digana]

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

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

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

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


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


or for failsafe:


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


or for surefire-report:


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



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

Release Notes - Maven Surefire - Version3.0.0-M4

Bug

[SUREFIRE-1222] - ForkClient attempts to consume unrelated lines
[SUREFIRE-1464] - Failsafe plugin exposes slf4j-jdk14 dependency
[SUREFIRE-1534] - Surefire 2.21.0 ClassNotFoundException:
org.apache.maven.plugin.surefire.StartupReportConfiguration using
reuseForks set to false
[SUREFIRE-1546] - JUnit 5 runner does not honor JUnit 5 display names
[SUREFIRE-1664] - "plugin's wiki page" points to non-existing web page
[SUREFIRE-1669] - POJO tests do not call fixture methods setUp and
tearDown and test instances are not new between tests
[SUREFIRE-1670] - wrong "Filtering by Test Class Names" in failsafe
"Using JUnit 5 Platform" page
[SUREFIRE-1675] - Forked JVM terminates with 'halt' when another
module's tests fail
[SUREFIRE-1679] - Caching of provider classpath with module-specific
changes may break test bootstrapping in subsequent modules
[SUREFIRE-1684] - The documentation of Maven Surefire Report Plugin
contains wrong number of plugin goals
[SUREFIRE-1689] - The fast PpidChecker is switched to the slow 30
seconds PING after the subprocess (/bin/ps -o etime= -p ...) failed with
exit 1
[SUREFIRE-1690] - Typo fixed: classpathDependencyExclude
[SUREFIRE-1701] - Surefire / Failsafe rerun failed tests functionality
fails with JUnit 5 if using @DisplayName
[SUREFIRE-1707] - Forked JVM is killed when GC paused the tests for
over 30 seconds
[SUREFIRE-1712] - Running tests with JDK13 fails with Unsupported class
file major version 57
[SUREFIRE-1716] - JUnit5 Parameterized tests and re-run should see
unique test runs with different parameters

New Feature

[SUREFIRE-1584] - Rerun Failing Tests with JUnit 5
[SUREFIRE-1705] - new config parameter Exclude Environment Variables
[SUREFIRE-1711] - Support @ParameterizedTest for JUnit 5 test reruns
[SUREFIRE-1717] - Enable Process Checkers

Improvement

[SUREFIRE-1004] - Enhance pattern/wildcard capabilities for
dependenciesToScan to GAVT
[SUREFIRE-1585] - Align JUnit Platform version at runtime
[SUREFIRE-1617] - Surefire fails with bad message when path contains
colon
[SUREFIRE-1619] - FileReporter should not use PintWriter because i/o
errors are not thrown
[SUREFIRE-1620] - Replaced deprecated component ArtifactFactory with
RepositorySystem
[SUREFIRE-1634] - Add missing since tags to excludesFile and
includesFile
[SUREFIRE-1635] - Set properties readonly where it doesn't make sense
to change values
[SUREFIRE-1647] - When using junit5, delay loading testClass and use
myown classLoader
[SUREFIRE-1666] - printSummary=false does not completely suppress the
summary on the console
[SUREFIRE-1668] - The stackTrace should use CDATA in XML report.
[SUREFIRE-1682] - Default value for config parameter 'shutdown' should
change from 'testset' to 'exit'
[SUREFIRE-1702] - [JDK 11 Alpine Linux] JAR content is not flushed
completely down to drive "Error: Invalid or corrupt jarfile
target/surefire/surefirebooter13749914711390838584.jar"
[SUREFIRE-1703] - [JDK 11 Alpine Linux] Surefire handled random order
of pid and /procps does not filter pid on busybox distributions
[SUREFIRE-1704] - [JDK 11 Alpine Linux] long etime within hours has
format 2h01 on busybox

Task

[SUREFIRE-1678] - JUnit5 Integration Tests should test wide spectrum of
versions
[SUREFIRE-1683] - Buildfix: TLS 1.2 passed to maven-invoker-plugin via
system property
[SUREFIRE-1706] - Use the checkstyle in tests and set
includeTestSourceDirectory=true
[SUREFIRE-1714] - Created module "surefire-shared-utils" as a required
dependency in "surefire-extensions-api" and "maven-surefire-common"

Dependency upgrade

[SUREFIRE-1642] - Upgrade plexus-java to Version 1.0.3
[SUREFIRE-1646] - Upgrade maven-artifact-transfer Version 0.11.0
[SUREFIRE-1672] - DOXIA updated to version 1.9
[SUREFIRE-1674] - DOXIA TOOLS updated to version 1.9.1
[SUREFIRE-1685] - Upgrade maven-fluido-skin to 1.8 and
maven-site-plugin to 3.8.2


Enjoy,

-The Apache Maven team

the alternatives with modular-path in Surefire/Failsafe

[Tibor Digana]

Hi Stephen,

You reported issues against Surefire and modular path. Since you also have
experiences with modular paths I would like to ask you about the CLI used
in Surefire and Failsafe.
Are you facing more needs to customize this CLI with Java modules?
Maybe you are facing more alternatives. You already described 4
alternatives in [1].
We recognize modular and classical Jars and we split them in two paths. So
we separated them properly. WDYT?
You can see the CLI if you run "mvn -X test" and the CLI is printed in
sevelar lines on the console right before the test set startup.

[1]: https://blog.joda.org/2018/03/jpms-negative-benefits.html

Regarding your requirements to select modularpath or classpath in plugin
configuration, this already exists, see
https://issues.apache.org/jira/browse/SUREFIRE-1497?focusedCommentId=16975659=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16975659


Cheers
Tibor17

Maven Surefire/Failsafe Release-3.0.0-M4

[Tibor Digana]

Hi,

There are altogether 43 bugfixes in the JIRA.
I would like to start a new release Vote today evening.

Kind regards,
Tibor17

Re: Surefire Report Bug with Assumption after at least 1 Rerun Test

[Tibor Digana]

We can write the concept together, here in ML.
Currently we are working on the release, so give us some days to finish it
first.

Meanwhile open every Provider implementation and notice which events are
fired from the provider via RunListener.
Try to realize the call sequences.
Then see the TestSetRunListener and the StatelessXmlReporter.
The classes in between are not mandatory to see.

You can draw a picture with the events if you want to see a global picture.
Then see the SimpleReportEntry and that's maybe all for the preparation
phase.

Of course see the unit or integration tests and you can write the missing
ones.
Based on the StatelessXmlReporter code you will see which tests are missing.
These are important tests because those will guarantee that we do not
produce more buggy implementation than it is now.
This would be a very big help!

Cheers
Tibor


On Mon, Nov 11, 2019 at 9:24 PM Ryan Thomas  wrote:

> Hi Tibor,
>
> That would be great. How would I go about doing that?
>
> *Ryan Thomas*
> *Sr. QA Engineer*
> BrainPOP
>
>
> On Mon, Nov 11, 2019 at 2:57 PM Tibor Digana 
> wrote:
>
>> yes, i saw the code. So it is reproducible.
>> but we will release a new version, so no time for me in this bug fix.
>>
>> IMHO this class should be written again.
>> We have this ambition in the version 3.0.0-M5.
>>
>> I can see the principal problems with the design, and you can see the
>> detailed code level issue.
>> I think you should try to find a workaround if your company cannot wait
>> and open a pull request on GitHub.
>> Another option is to participate on rewriting this class and write
>> missing tests. Then the class will reach higher quality.
>>
>> These issues will always exist because the class is stateful and it make
>> some guesses about the rerun feeture which is bad of course.
>> So i don't think that the logic is bullet proof.
>> IMO this class should handle all events and process them without making
>> any guess of what test was the first and second, and any guess of using the
>> loops.
>> We for instance it does not handle events in this class saying that this
>> is the normal run and this is the rerun, etc.
>> That's why this class makes some guess about the order and it comes with
>> errors.
>> This design will cause the bugs that we have regarding parallel
>> executions of JUnit5 methods. It is fine in JUnit47+ because there is a
>> trick which bypassed this problem.
>> The next issue is the efficiency of the report writer because this class
>> attempts to rewrite the content.
>>
>> So, this all is due to legacy code and therefore I did not spend the time
>> with induvidual bugs because my time can be better utilized if I make one
>> commit and fix 10 Jira issues at once.
>> Now the cost makes sense for me only if we rewrite the class completely
>> because we can close all bugs for all users, and not only the one bug for
>> only few users.
>>
>> Maybe you want to paricipate in 3.0.0-M5 development.
>>
>>
>> T
>>
>> On Mon, Nov 11, 2019 at 8:20 PM Ryan Thomas  wrote:
>>
>>> Hi Tibor,
>>>
>>> Were you able to test this scenario with the code snippet I provided in
>>> testSomething3()?
>>> My company has a legitimate test that falls into this scenario but I
>>> provided that snippet as a proof of concept.
>>>
>>> What I have found is 2 things:
>>> 1. *There is a conflict in the reported type when there are
>>> Errors/Failures before a Skip from an Assumption in
>>> DefaultReporterFactory.getTestResultType()*
>>> It is technically impossible for the code contained to return a skipped
>>> status if there was previously an Error or Failure reported in the repeated
>>> test Runs
>>>
>>> https://github.com/apache/maven-surefire/blob/33360045e005b38b16eb2c6d1169f43de927bb3d/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/DefaultReporterFactory.java#L253
>>> Here we see that if there was an Error or a Failure and the
>>> rerunFailingTestsCount> 0, if there was a success after we report
>>> flake, but because the other scenario is an ELSE, it will always in this
>>> flow return seenError? error: failure.  It will not be able to move onto
>>> the outer if/else if/else to return a skipped status.
>>>
>>> 2. *There is an issue in StatelessXmlReporter when we are then handling
>>> this misreported Skipped state as a Failure*
>>>
>>> https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plu

Re: Surefire Report Bug with Assumption after at least 1 Rerun Test

[Tibor Digana]

yes, i saw the code. So it is reproducible.
but we will release a new version, so no time for me in this bug fix.

IMHO this class should be written again.
We have this ambition in the version 3.0.0-M5.

I can see the principal problems with the design, and you can see the
detailed code level issue.
I think you should try to find a workaround if your company cannot wait and
open a pull request on GitHub.
Another option is to participate on rewriting this class and write missing
tests. Then the class will reach higher quality.

These issues will always exist because the class is stateful and it make
some guesses about the rerun feeture which is bad of course.
So i don't think that the logic is bullet proof.
IMO this class should handle all events and process them without making any
guess of what test was the first and second, and any guess of using the
loops.
We for instance it does not handle events in this class saying that this is
the normal run and this is the rerun, etc.
That's why this class makes some guess about the order and it comes with
errors.
This design will cause the bugs that we have regarding parallel executions
of JUnit5 methods. It is fine in JUnit47+ because there is a trick which
bypassed this problem.
The next issue is the efficiency of the report writer because this class
attempts to rewrite the content.

So, this all is due to legacy code and therefore I did not spend the time
with induvidual bugs because my time can be better utilized if I make one
commit and fix 10 Jira issues at once.
Now the cost makes sense for me only if we rewrite the class completely
because we can close all bugs for all users, and not only the one bug for
only few users.

Maybe you want to paricipate in 3.0.0-M5 development.


T

On Mon, Nov 11, 2019 at 8:20 PM Ryan Thomas  wrote:

> Hi Tibor,
>
> Were you able to test this scenario with the code snippet I provided in
> testSomething3()?
> My company has a legitimate test that falls into this scenario but I
> provided that snippet as a proof of concept.
>
> What I have found is 2 things:
> 1. *There is a conflict in the reported type when there are
> Errors/Failures before a Skip from an Assumption in
> DefaultReporterFactory.getTestResultType()*
> It is technically impossible for the code contained to return a skipped
> status if there was previously an Error or Failure reported in the repeated
> test Runs
>
> https://github.com/apache/maven-surefire/blob/33360045e005b38b16eb2c6d1169f43de927bb3d/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/DefaultReporterFactory.java#L253
> Here we see that if there was an Error or a Failure and the
> rerunFailingTestsCount> 0, if there was a success after we report flake,
> but because the other scenario is an ELSE, it will always in this flow
> return seenError? error: failure.  It will not be able to move onto the
> outer if/else if/else to return a skipped status.
>
> 2. *There is an issue in StatelessXmlReporter when we are then handling
> this misreported Skipped state as a Failure*
>
> https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java#L250
>
> Here we see that when writing to the XML for all of the subsequent runs
> after the first run, we are getting the singleRunEntry.
> getReportEntryType().getRerunXmlTag(), which in the case for the
> ReportType enum, SKIPPED has its flakyXmlTag and rerunXmlTag defined as "",
> an empty string.
>
> https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/ReportEntryType.java#L31
>
> This conflict arises because the individual entry IS reported as skipped,
> but the getTestResultType check from the list or tries incorrectly reported
> it as a Failure. So it goes through the incorrect reporting type for the
> XML output, hence why it contains the system-out, and system-err sub
> elements
>
> Thank you for taking the time to look into this!
>
> *Ryan Thomas*
> *Sr. QA Engineer*
> BrainPOP
>
>
> On Mon, Nov 11, 2019 at 2:04 PM Tibor Digana 
> wrote:
>
>> Hi Ryan,
>>
>> I found this issue already reported in JIRA.
>> https://issues.apache.org/jira/browse/SUREFIRE-1556
>>
>> There is no fix because we have not received any reproducible project.
>>
>> IMO this section should not exist in the XML:
>>
>> < message="This is a bug">
>>
>>   
>>
>>   
>>
>> 
>>
>> It looks like the message is XML attribute used as an element.
>>
>> I checked the StatelessXmlReporter  right now but i could not find any
>> logical reason for this iss

Re: Surefire Report Bug with Assumption after at least 1 Rerun Test

[Tibor Digana]

Hi Ryan,

I found this issue already reported in JIRA.
https://issues.apache.org/jira/browse/SUREFIRE-1556

There is no fix because we have not received any reproducible project.

IMO this section should not exist in the XML:

< message="This is a bug">

  

  



It looks like the message is XML attribute used as an element.

I checked the StatelessXmlReporter  right now but i could not find any
logical reason for this issue.
I have really no idea what code and how injected this section into the XML
file.

Here is the method which is responsible for writing the system-out and
system-err but I still do not see the root cause in the latest revision.
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java#L479

Maybe you have older version where is this bug.
So the only thing we can do is to ask you to run the test with
3.0.0-SNAPSHOT.
And then somebody has to debug the code. ;-(

Pls write the test result in JIRA.
If the bug is still present with the snapshot version then I would ask you
to help us, dig in to the code and debug it.

Cheers
Tibor


On Mon, Nov 11, 2019 at 6:33 PM Ryan Thomas  wrote:

> Hi Tibor,
>
>
>
> My Company BrainpOP is using Maven 3.6.2 with Junit4.7+ (Junit
> 4.13-beta-3, Junit 4.13-rc-1) and has recently come into an issue while
> trying to optimize flaky test run times.
>
>
>
> We are implementing assumptions to have Tests that are in a bad state to
> be skipped so that they do not add a ton of run time to the Test Suite in a
> case where the next Selenium run command fails with a long
> TimeOutException. However, we have come across some scenarios where
> sometime the Test might fail do to a failed Assertion, and on its next Run
> due to rerunFailingTestCount  criteria being met, an Assumption will fail
> resulting in further runs of the test being skipped. When this occurs, The
> surefire-report-plugin has been failing at parsing the generated XML.
>
>
>
> In analyzing the XML output for the scenario, I found the the XML
> generated was invalid, and that the message tied to where the Assumption
> failed in malformed. In this case, the Tag name (e.g. failure, skipped,
> rerunFailure, etc…) is missing and only the message attribute  and type
> remains. Looking at the surefire-test-report-3.0.xsd Schema, I can see that
> this is invalid.
>
>
>
> Here is the sample Test run in Junit through Maven
>
>
>
> @SuppressWarnings("deprecation")
>
> @Test
>
> public void testSomething3() {
>
> System.out.println("the end");
>
> i++;
>
> if(i == 3)
>
> Assume.assumeTrue("This is a bug", false);
>
> else
>
> Assert.assertTrue("Run: " + i,false);
>
> }
>
>
>
> Included here is a sample snippet of the malformed tag from the generated
> XML
>
>
>
>  time="13.289">
>
>  type="java.lang.AssertionError">java.lang.AssertionError: Run: 1
>
> at
> com.brainpop.tests.LoggingTest.testSomething3(LoggingTest.java:66)
>
> 
>
> 
>
> 
>
> 
>
>   java.lang.AssertionError: Run: 2
>
> at
> com.brainpop.tests.LoggingTest.testSomething3(LoggingTest.java:66)
>
> 
>
>   
>
>   
>
> 
>
> < message="This is a bug">
>
>   
>
>   
>
> 
>
>   
>
>
>
>
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>

Re: build-helper-maven-plugin: java.lang.IllegalArgumentException: version can neither be null, empty nor blank

[Tibor Digana]

Hi Jamin,
Pls open a JIRA ticket and keep this discussion open.
Thx!

On Sat, Nov 2, 2019 at 7:17 PM Jamin Collins 
wrote:

> I'm running into an issue with build-helper-maven-plugin in a project
> I'm attempting to build.
>
> I was previously (roughly about a year ago) able to build this project
> without issue on this host.
>
> I'm now getting "java.lang.IllegalArgumentException: version can neither
> be null, empty nor blank".  Others within the project can still build fine.
>
> I've tried a fresh source checkout and purging my maven cache. I've also
> tried updating the build-helper-maven-plugin version used by the project
> to what I understand is the latest (3.0.0), no change.
>
> Full build logs from both attempts are available here:
> - https://asgardsrealm.net/tmp/forge/build-helper-maven-plugin-1.8.log
> - https://asgardsrealm.net/tmp/forge/build-helper-maven-plugin-3.0.0.log
>
> Hoping for some guidance on how to debug this.
>
> Thanks in advance.
>
> --
> Jamin W. Collins
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Take threaddump on hung surefire tests

[Tibor Digana]

pleaseStop() can be called only inside Surefire.
So your solution has to be embedded in Surefire and the feature has to
configured.
Unfortunately it's by design of JUnit.
RunNotifier cannot be exposed because it must be only one instance and we
need to instantiate it and have it under the control in Surefire.
Therefore this feature has to be internal and implement a hook between
RunListener and RunNotifier which already exists in Surefire.
This is the support I was talking about in one of my previous emails.

T

On Sat, Oct 5, 2019 at 5:57 PM Debraj Manna 
wrote:

> Enrico apache-bookeeper seems to be using timeout in @Test as I can see
> from their github repo here
> <
> https://github.com/apache/bookkeeper/search?q=%40Test%28timeout+%3D_q=%40Test%28timeout+%3D
> >
> .
>
> Tibor how can I pass an instance of RunNotifier to a class extending from
> RunListener so that I can call pleaseStop() from the listener when the
> timeout of a test expires? Is there any example code I can refer to?
>
> I am using Junit 4.12 and maven-surefire 2.22.2
>
> On Sat, Oct 5, 2019 at 6:27 PM Tibor Digana 
> wrote:
>
> > Some users may have a requirement to stop the exertion when a test hangs.
> > Other users woul maybe prefer to interrupt the test and continue with
> next
> > test.
> > This would lead to configuration with more than one config value => POJO
> in
> > new config parameter.
> >
> > On Sat, Oct 5, 2019 at 2:17 PM Debraj Manna 
> > wrote:
> >
> > > Thanks again Enrico. I will try to find out from apache-bookmark code
> or
> > > check in apache-bookkeper mailing list.
> > >
> > > Yes Tibor I am looking for a global timeout without explicitly adding
> the
> > > timeout annotation in all of my tests / classes. I am not using
> > forkCount >
> > > 1. I get your testStarted part but it is still not clear to me about
> > > calling 'pleaseStop() on the listener'. Are you suggesting to add this
> in
> > > each of my test classes? Can you explain this a bit more?
> > >
> > > On Fri, Oct 4, 2019 at 11:52 PM Tibor Digana 
> > > wrote:
> > >
> > > > Hi Debraj,
> > > >
> > > > It depends on your requirements.
> > > >
> > > > As I initially understood your email, every test method wants to have
> > > > implicit timeout value even without the annotation @Timeout.
> > > > Then the testStarted is important event even your code will see when
> > the
> > > > test method has started and timeout can be easily computed.
> > > > Of course you need to use an extra thread which checks the end
> events.
> > > >
> > > >
> > >
> >
> https://junit.org/junit4/javadoc/4.12/org/junit/runner/notification/RunListener.html#testStarted(org.junit.runner.Description)
> > > > Your code can call the method "pleaseStop()" on the listener. I think
> > it
> > > > would not be reliable algorithm in all use cases if you use forkCount
> > > 1
> > > > and there you will need to have our support.
> > > >
> > > > Is it this what you need, the global timeout with the same value on
> > every
> > > > test method?
> > > >
> > > > Cheers
> > > > Tibor
> > > >
> > > > On Fri, Oct 4, 2019 at 4:30 PM Debraj Manna <
> subharaj.ma...@gmail.com>
> > > > wrote:
> > > >
> > > > > Enrico
> > > > >
> > > > > If I get the approach correctly then all my junit4 tests should
> have
> > > > > timeout specified (either via @Test or via @Rule) then only I can
> use
> > > the
> > > > > listener. But the problem is we are having more than 2000 tests and
> > > > > specifying a timeout in each of the tests/classes is cumbersome.
> > > > >
> > > > > Correct me if I have misunderstood anything.
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Oct 4, 2019 at 3:18 PM Debraj Manna <
> > subharaj.ma...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Yeah sure ... thanks.
> > > > > >
> > > > > > On Thu, Oct 3, 2019 at 7:50 PM Tibor Digana <
> > tibordig...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > >> Hi Debraj,
> > > > > >>
> > > > > >> There is nice technical idea from Enrico.
> > > >

Re: Proposal: maven release lifecycle

[Tibor Digana]

Release lifecycle does not exist yet.
There's only "default", "clean", "site".

Therefore i would prefer to have this in CLI, i.e.
$ maven release

>> nowdays needs (release, js build, cloud deployment, gh-pages, etc...)
We cannot be technology specific but we can provide customization of the
release lifecycle.

The outcome of this discussion should be some frame-work as well as list of
items where we can agree and start writing Wiki page.
We do not have to go deeply "how" to do.
We should agree on "what" to do at least.



On Sat, Oct 5, 2019 at 4:08 PM Romain Manni-Bucau 
wrote:

> Personally Id like to keep current release lifecycle, it is the most
> generic one we can get but we need to let users create their own chain of
> mojo very easily in the pom.
>
> It is trivial to do with a custom descriptor and extension but it must be
> built in cause of nowdays needs (release, js build, cloud deployment,
> gh-pages, etc...)
>
> Le sam. 5 oct. 2019 à 15:18, Tibor Digana  a
> écrit :
>
> > I have never seen a documentation for ship-maven-plugin.
> > It could be a good motivation for us.
> >
> > I can say for myself, my requirements are to the new lifecycle and plugin
> > goal release:release:
> > 1. executes phases from clean to deploy
> > 2. installation of "release" artifacts is skipped (snapshots are not
> > skipped)
> > 3. unit and integration tests are executed only once and not two times
> >
> > Tagging and SCM checkout are just fine.
> >
> > Second lifecycle for release without scm checkout and deployment. The
> test
> > would be executed once, tagging and both commit messages are the must.
> >
> > WDYT? How you would like to see the release lifecysle?
> > Notice that we should not say how the project should look like in the
> > customer. The customer may have reasons to use his project structures as
> > they are and the architecture too. So we should NOT define these
> > structures!
> >
> >
> > On Sat, Oct 5, 2019 at 2:47 PM Marco Schulz 
> > wrote:
> >
> > > All this points are in my opinion an indicator that a release is a
> > complex
> > > process and very difficult to handle in just a plugin. To maintain all
> > that
> > > different points a relesaplugin will ver a ueber (god) plugin.
> > >
> > > Docker for example is another big toic we need to think about.
> > >
> > > rwgards and anice weekend to all
> > > . marco
> > >
> > > Sent from Outlook Mobile<https://aka.ms/blhgte>
> > >
> > > 
> > > From: Romain Manni-Bucau 
> > > Sent: Saturday, October 5, 2019 2:06:27 AM
> > > To: Maven Developers List 
> > > Cc: users 
> > > Subject: Re: Proposal: maven release lifecycle
> > >
> > > I like the words but fail to see the missing pieces (understand actions
> > to
> > > do).
> > >
> > > Typically today when i release at work i use release plugin enriched
> with
> > > github page deployment for the doc using antora + a ftp update of my
> > server
> > > output capture to have a mock backing openapi/swagger ui + docker ilage
> > > deployment on docker hub + an intellij plugin deployment on jetbrains
> > > marketplace etc...adding a flyway migration with a rolling update in a
> > k8s
> > > cluster is trivial (ops need to say yes though ;)).
> > >
> > > So technically it is verbose but doable.
> > >
> > > Custom lifecycle definition is not neat, custom build tasks require a
> > build
> > > hack or using groovy plugin but it works.
> > >
> > > Typically, an extension could enable all that based on convention, just
> > > injecting needed plugins based on the file presence and values of the
> > > distribution urls.
> > >
> > > This is why i ended up thinking we are more on 1. Sugar in release
> plugin
> > > and 2. Maybe on a generic extension cretion (it replaces rigid
> lifecycle
> > > for such cases these days due to their writing easiness)
> > >
> > > Am I missing something?
> > >
> > > Le sam. 5 oct. 2019 à 08:23, Marco Schulz  a
> > > écrit :
> > >
> > > > Hello Romain, hello Tibor
> > > >
> > > > Thanks for your feedback. I had yesterday a very interesting
> > conversation
> > > > with
> > > > Karl Heinz. He gave me some very informative links about deeply maven
> > > > insights.
> > >

Re: Proposal: maven release lifecycle

[Tibor Digana]

> on maven central(validate). To secure a reproducible build, in a second
> > step we
> > enforce that no SNAPSHOT artifacts are involved, the correct maven
> version
> > is
> > used etc. (the existing enforcer plugin do a great job). After the
> > preconditions
> > are fine we can execute external acceptance tests like JGiven. In another
> > step
> > the JavaDoc got generated. the pgp plugin sing the artifacts and check
> > that the
> > public key is available. The SCM plugin create a tag for the released
> > revision.
> > Difficult parts are auto increment the version number and auto check the
> > scm if
> > the release is produced with the last revision of the code. This actions
> > are by
> > my experience a bit error prune.
> > A release process could have some vocabulary like prepare, perform,
> > deploy. This
> > are just conventions, like it is used in the build lifecycle. To realize
> > this
> > idea, many already existing plugins can used, like the release plugin. In
> > this
> > proposal I was also not mentions external plugins to use like flyway, for
> > database versioning and so on. A lot of things ar imaginable.
> >
> > In future more lifecycles or workflows could be possible. For example a
> > deploy
> > lifecycle and so on. And then maven transform from a plugin execution
> > framework
> > to a process management framework, like Jason van Zyl described in his
> book
> > better build with maven.
> >
> > warm regards to all
> > .marco
> >
> >
> >
> >
> > On Fri, 2019-10-04 at 11:28 +0200, Romain Manni-Bucau wrote:
> > > @Tibor: I agree merging both in one "super" command can be neat (I
> always
> > > run both at once typically) but I disagree with last parts "skip the
> > test"
> > > - maven is also there to enforce tests as a good practise, if you don't
> > > automatically test it you can configure maven to skip tests for the
> > release
> > > but it is at your own risk, can be fine or not - and "skip the deploy"
> -
> > > here again you can configure maven to do it if you need but maven must
> > > respect the build attached artifact.
> > >
> > > 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 ven. 4 oct. 2019 à 11:22, Tibor Digana  a
> > écrit :
> > >
> > > > It would be worth to add a new goal called "release" to the
> > > > maven-release-plugin which merges "prepare" and "perform".
> > > > We developers in companies use both goals prepare and perform
> > immediately
> > > > together because for us two goals do not make sense.
> > > > Two goals make sense for those who can wait days to start manual
> tests
> > of
> > > > the TAG but we don't!
> > > >
> > > > We are testing the JAR libraries beforehand and then we evaluate the
> > > > quality/manual tests with SNAPSHOT whether it makes sense to start
> the
> > > > release process in CLI.
> > > > If there are web archives, the prepare phase would be enough because
> > > > deployment in Nexus is useless nothing but the TAG itself and
> > Continuous
> > > > Delivery.
> > > >
> > > > On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Marco,
> > > > >
> > > > > I have 2 thoughts reading your post:
> > > > >
> > > > > 1. Should be enforced by an extension (sonatype plugin if target is
> > > > > central?)
> > > > > 2. It likely misses a few phases compared to maven release plugin
> > which
> > > > > validates the release can be done (including tests) and runs the
> > tests on
> > > > > the tag as well
> > > > >
> > > > > Now if 200 lines of xml can be replaced by a single extension I am
> > +1000
> > > >
> > > > on
> > > > > that track
> > > > >
&

Re: Take threaddump on hung surefire tests

[Tibor Digana]

Some users may have a requirement to stop the exertion when a test hangs.
Other users woul maybe prefer to interrupt the test and continue with next
test.
This would lead to configuration with more than one config value => POJO in
new config parameter.

On Sat, Oct 5, 2019 at 2:17 PM Debraj Manna 
wrote:

> Thanks again Enrico. I will try to find out from apache-bookmark code or
> check in apache-bookkeper mailing list.
>
> Yes Tibor I am looking for a global timeout without explicitly adding the
> timeout annotation in all of my tests / classes. I am not using forkCount >
> 1. I get your testStarted part but it is still not clear to me about
> calling 'pleaseStop() on the listener'. Are you suggesting to add this in
> each of my test classes? Can you explain this a bit more?
>
> On Fri, Oct 4, 2019 at 11:52 PM Tibor Digana 
> wrote:
>
> > Hi Debraj,
> >
> > It depends on your requirements.
> >
> > As I initially understood your email, every test method wants to have
> > implicit timeout value even without the annotation @Timeout.
> > Then the testStarted is important event even your code will see when the
> > test method has started and timeout can be easily computed.
> > Of course you need to use an extra thread which checks the end events.
> >
> >
> https://junit.org/junit4/javadoc/4.12/org/junit/runner/notification/RunListener.html#testStarted(org.junit.runner.Description)
> > Your code can call the method "pleaseStop()" on the listener. I think it
> > would not be reliable algorithm in all use cases if you use forkCount > 1
> > and there you will need to have our support.
> >
> > Is it this what you need, the global timeout with the same value on every
> > test method?
> >
> > Cheers
> > Tibor
> >
> > On Fri, Oct 4, 2019 at 4:30 PM Debraj Manna 
> > wrote:
> >
> > > Enrico
> > >
> > > If I get the approach correctly then all my junit4 tests should have
> > > timeout specified (either via @Test or via @Rule) then only I can use
> the
> > > listener. But the problem is we are having more than 2000 tests and
> > > specifying a timeout in each of the tests/classes is cumbersome.
> > >
> > > Correct me if I have misunderstood anything.
> > >
> > >
> > >
> > > On Fri, Oct 4, 2019 at 3:18 PM Debraj Manna 
> > > wrote:
> > >
> > > > Yeah sure ... thanks.
> > > >
> > > > On Thu, Oct 3, 2019 at 7:50 PM Tibor Digana 
> > > > wrote:
> > > >
> > > >> Hi Debraj,
> > > >>
> > > >> There is nice technical idea from Enrico.
> > > >> If you apply it and you are convinced that it would work properly
> for
> > > all
> > > >> the Java community, feel free to show it and we can discuss it on
> how
> > we
> > > >> would adopt your solution in Surefire project.
> > > >>
> > > >> Cheers
> > > >> Tibor17
> > > >>
> > > >> On Thu, Oct 3, 2019 at 2:49 PM Debraj Manna <
> subharaj.ma...@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >> > Sometimes I have maven surefire tests that get hung, due to either
> > > >> races or
> > > >> > deadlocks.
> > > >> >
> > > >> > When this happens I have to discover what slave is being used, and
> > > then
> > > >> I
> > > >> > have to log on that slave, sudo to jenkins account and execute
> > either
> > > >> > jstack or kill -3
> > > >> >
> > > >> > I am looking for a simple solution like doing jstack / kill -3
> when
> > > >> someone
> > > >> > presses abort button on the jenkins.
> > > >> >
> > > >> > Can someone suggest how can I automate this or some better way of
> > > >> handling
> > > >> > this?
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: Take threaddump on hung surefire tests

[Tibor Digana]

Notice that Surefire instantiates new JUnitCore() and then runs the test
class(es).
The method pleaseStop() stops this execution so that no new test method
would be followed.

On Sat, Oct 5, 2019 at 2:17 PM Debraj Manna 
wrote:

> Thanks again Enrico. I will try to find out from apache-bookmark code or
> check in apache-bookkeper mailing list.
>
> Yes Tibor I am looking for a global timeout without explicitly adding the
> timeout annotation in all of my tests / classes. I am not using forkCount >
> 1. I get your testStarted part but it is still not clear to me about
> calling 'pleaseStop() on the listener'. Are you suggesting to add this in
> each of my test classes? Can you explain this a bit more?
>
> On Fri, Oct 4, 2019 at 11:52 PM Tibor Digana 
> wrote:
>
> > Hi Debraj,
> >
> > It depends on your requirements.
> >
> > As I initially understood your email, every test method wants to have
> > implicit timeout value even without the annotation @Timeout.
> > Then the testStarted is important event even your code will see when the
> > test method has started and timeout can be easily computed.
> > Of course you need to use an extra thread which checks the end events.
> >
> >
> https://junit.org/junit4/javadoc/4.12/org/junit/runner/notification/RunListener.html#testStarted(org.junit.runner.Description)
> > Your code can call the method "pleaseStop()" on the listener. I think it
> > would not be reliable algorithm in all use cases if you use forkCount > 1
> > and there you will need to have our support.
> >
> > Is it this what you need, the global timeout with the same value on every
> > test method?
> >
> > Cheers
> > Tibor
> >
> > On Fri, Oct 4, 2019 at 4:30 PM Debraj Manna 
> > wrote:
> >
> > > Enrico
> > >
> > > If I get the approach correctly then all my junit4 tests should have
> > > timeout specified (either via @Test or via @Rule) then only I can use
> the
> > > listener. But the problem is we are having more than 2000 tests and
> > > specifying a timeout in each of the tests/classes is cumbersome.
> > >
> > > Correct me if I have misunderstood anything.
> > >
> > >
> > >
> > > On Fri, Oct 4, 2019 at 3:18 PM Debraj Manna 
> > > wrote:
> > >
> > > > Yeah sure ... thanks.
> > > >
> > > > On Thu, Oct 3, 2019 at 7:50 PM Tibor Digana 
> > > > wrote:
> > > >
> > > >> Hi Debraj,
> > > >>
> > > >> There is nice technical idea from Enrico.
> > > >> If you apply it and you are convinced that it would work properly
> for
> > > all
> > > >> the Java community, feel free to show it and we can discuss it on
> how
> > we
> > > >> would adopt your solution in Surefire project.
> > > >>
> > > >> Cheers
> > > >> Tibor17
> > > >>
> > > >> On Thu, Oct 3, 2019 at 2:49 PM Debraj Manna <
> subharaj.ma...@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >> > Sometimes I have maven surefire tests that get hung, due to either
> > > >> races or
> > > >> > deadlocks.
> > > >> >
> > > >> > When this happens I have to discover what slave is being used, and
> > > then
> > > >> I
> > > >> > have to log on that slave, sudo to jenkins account and execute
> > either
> > > >> > jstack or kill -3
> > > >> >
> > > >> > I am looking for a simple solution like doing jstack / kill -3
> when
> > > >> someone
> > > >> > presses abort button on the jenkins.
> > > >> >
> > > >> > Can someone suggest how can I automate this or some better way of
> > > >> handling
> > > >> > this?
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: Take threaddump on hung surefire tests

[Tibor Digana]

Hi Debraj,

It depends on your requirements.

As I initially understood your email, every test method wants to have
implicit timeout value even without the annotation @Timeout.
Then the testStarted is important event even your code will see when the
test method has started and timeout can be easily computed.
Of course you need to use an extra thread which checks the end events.
https://junit.org/junit4/javadoc/4.12/org/junit/runner/notification/RunListener.html#testStarted(org.junit.runner.Description)
Your code can call the method "pleaseStop()" on the listener. I think it
would not be reliable algorithm in all use cases if you use forkCount > 1
and there you will need to have our support.

Is it this what you need, the global timeout with the same value on every
test method?

Cheers
Tibor

On Fri, Oct 4, 2019 at 4:30 PM Debraj Manna 
wrote:

> Enrico
>
> If I get the approach correctly then all my junit4 tests should have
> timeout specified (either via @Test or via @Rule) then only I can use the
> listener. But the problem is we are having more than 2000 tests and
> specifying a timeout in each of the tests/classes is cumbersome.
>
> Correct me if I have misunderstood anything.
>
>
>
> On Fri, Oct 4, 2019 at 3:18 PM Debraj Manna 
> wrote:
>
> > Yeah sure ... thanks.
> >
> > On Thu, Oct 3, 2019 at 7:50 PM Tibor Digana 
> > wrote:
> >
> >> Hi Debraj,
> >>
> >> There is nice technical idea from Enrico.
> >> If you apply it and you are convinced that it would work properly for
> all
> >> the Java community, feel free to show it and we can discuss it on how we
> >> would adopt your solution in Surefire project.
> >>
> >> Cheers
> >> Tibor17
> >>
> >> On Thu, Oct 3, 2019 at 2:49 PM Debraj Manna 
> >> wrote:
> >>
> >> > Sometimes I have maven surefire tests that get hung, due to either
> >> races or
> >> > deadlocks.
> >> >
> >> > When this happens I have to discover what slave is being used, and
> then
> >> I
> >> > have to log on that slave, sudo to jenkins account and execute either
> >> > jstack or kill -3
> >> >
> >> > I am looking for a simple solution like doing jstack / kill -3 when
> >> someone
> >> > presses abort button on the jenkins.
> >> >
> >> > Can someone suggest how can I automate this or some better way of
> >> handling
> >> > this?
> >> >
> >>
> >
>

Re: Proposal: maven release lifecycle

[Tibor Digana]

I did not say that we skip test. I never skip the tests in prepare/perform.
Some colleagues do but for me it is good time to spend in the kitchen and
take a tea.

Our architecture was simply designed with isolated SCM projects, so the
dependencies are being downloaded into it and therefore I verify that what
would happen in SCM2 now if I compiled the lib in SCM1. Usually it is okay
because we have good ITs in SCM1 and we are cool devs ;-)

On Fri, Oct 4, 2019 at 11:28 AM Romain Manni-Bucau 
wrote:

> @Tibor: I agree merging both in one "super" command can be neat (I always
> run both at once typically) but I disagree with last parts "skip the test"
> - maven is also there to enforce tests as a good practise, if you don't
> automatically test it you can configure maven to skip tests for the release
> but it is at your own risk, can be fine or not - and "skip the deploy" -
> here again you can configure maven to do it if you need but maven must
> respect the build attached artifact.
>
> 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 ven. 4 oct. 2019 à 11:22, Tibor Digana  a
> écrit :
>
> > It would be worth to add a new goal called "release" to the
> > maven-release-plugin which merges "prepare" and "perform".
> > We developers in companies use both goals prepare and perform immediately
> > together because for us two goals do not make sense.
> > Two goals make sense for those who can wait days to start manual tests of
> > the TAG but we don't!
> >
> > We are testing the JAR libraries beforehand and then we evaluate the
> > quality/manual tests with SNAPSHOT whether it makes sense to start the
> > release process in CLI.
> > If there are web archives, the prepare phase would be enough because
> > deployment in Nexus is useless nothing but the TAG itself and Continuous
> > Delivery.
> >
> > On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau  >
> > wrote:
> >
> > > Hi Marco,
> > >
> > > I have 2 thoughts reading your post:
> > >
> > > 1. Should be enforced by an extension (sonatype plugin if target is
> > > central?)
> > > 2. It likely misses a few phases compared to maven release plugin which
> > > validates the release can be done (including tests) and runs the tests
> on
> > > the tag as well
> > >
> > > Now if 200 lines of xml can be replaced by a single extension I am
> +1000
> > on
> > > that track
> > >
> > > Le ven. 4 oct. 2019 à 08:24, Marco Schulz  a
> > > écrit :
> > >
> > > > Hello Maven Dev & Community
> > > >
> > > > Sine a long time I thought, it would be cool to have a well defined
> > > > process to
> > > > prepare a release of an artifact and deploy it on mvn central. Now I
> > got
> > > a
> > > > bit
> > > > time to formulate a short proposal of my idea. I published a
> > description
> > > > of my
> > > > thought on my bolg:
> > > > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
> > > >
> > > > A poll is also created, may to see what other people think about it.
> > > > Please feel
> > > > free to leave also comments, every feedback is welcome.
> > > >
> > > > warm regards & thanks to the maven dev team for the great job they
> do.
> > > > .marco (@ElmarDott)
> > > >
> > > > --
> > > >
> > > >
> > >
> >
> 
> > > >  Dipl. Inf. Marco Schulz (MSc)
> > > >
> > > >   Expert for (WEB) Enterprise Applications
> > > >- worldwide -
> > > >   + Project Manager + Consultant + Writer + Speaker + Trainer +
> > > >
> > > >
> > > >
> > >
> >
> [Contact]___
> > > >
> > > >WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
> > > >Cell :  +49 (0) 163 69 18 445 :: Germany
> > > >E-Mail   :  marco.sch...@outlook

Re: Proposal: maven release lifecycle

[Tibor Digana]

It would be worth to add a new goal called "release" to the
maven-release-plugin which merges "prepare" and "perform".
We developers in companies use both goals prepare and perform immediately
together because for us two goals do not make sense.
Two goals make sense for those who can wait days to start manual tests of
the TAG but we don't!

We are testing the JAR libraries beforehand and then we evaluate the
quality/manual tests with SNAPSHOT whether it makes sense to start the
release process in CLI.
If there are web archives, the prepare phase would be enough because
deployment in Nexus is useless nothing but the TAG itself and Continuous
Delivery.

On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau 
wrote:

> Hi Marco,
>
> I have 2 thoughts reading your post:
>
> 1. Should be enforced by an extension (sonatype plugin if target is
> central?)
> 2. It likely misses a few phases compared to maven release plugin which
> validates the release can be done (including tests) and runs the tests on
> the tag as well
>
> Now if 200 lines of xml can be replaced by a single extension I am +1000 on
> that track
>
> Le ven. 4 oct. 2019 à 08:24, Marco Schulz  a
> écrit :
>
> > Hello Maven Dev & Community
> >
> > Sine a long time I thought, it would be cool to have a well defined
> > process to
> > prepare a release of an artifact and deploy it on mvn central. Now I got
> a
> > bit
> > time to formulate a short proposal of my idea. I published a description
> > of my
> > thought on my bolg:
> > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
> >
> > A poll is also created, may to see what other people think about it.
> > Please feel
> > free to leave also comments, every feedback is welcome.
> >
> > warm regards & thanks to the maven dev team for the great job they do.
> > .marco (@ElmarDott)
> >
> > --
> >
> >
> 
> >  Dipl. Inf. Marco Schulz (MSc)
> >
> >   Expert for (WEB) Enterprise Applications
> >- worldwide -
> >   + Project Manager + Consultant + Writer + Speaker + Trainer +
> >
> >
> >
> [Contact]___
> >
> >WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
> >Cell :  +49 (0) 163 69 18 445 :: Germany
> >E-Mail   :  marco.sch...@outlook.com
> >
> >Blog :  https://enRebaja.wordpress.com
> >twitter  :  https://twitter.com/ElmarDott
> >tumblr   :  https://elmardott.tumblr.com
> >facebook :  https://www.facebook.com/elmar.dott
> >
> >
> >
> [Services]__
> >
> > + Individual software development
> > + Software Project Management
> > + Build-,  Configuration-, & Delivery Management
> > + Release Management
> > + Business Analysis
> > + Software Architecture
> > + Process Automation
> >
> >
> 
> > This message is intended only for the use of the individual or entity to
> > which
> > it is addressed, and may contain information that is privileged,
> > confidential
> > and that may not be made public by law or agreement. If you are not the
> > intended
> > recipient or entity, you are hereby notified that any further
> > dissemination,
> > distribution or copying of this information is strictly prohibited.
> > If you have received this communication in error, please contact us
> > immediately
> > and delete the message from your system.
> >
> >
>

Re: Take threaddump on hung surefire tests

[Tibor Digana]

Hi Debraj,

There is nice technical idea from Enrico.
If you apply it and you are convinced that it would work properly for all
the Java community, feel free to show it and we can discuss it on how we
would adopt your solution in Surefire project.

Cheers
Tibor17

On Thu, Oct 3, 2019 at 2:49 PM Debraj Manna 
wrote:

> Sometimes I have maven surefire tests that get hung, due to either races or
> deadlocks.
>
> When this happens I have to discover what slave is being used, and then I
> have to log on that slave, sudo to jenkins account and execute either
> jstack or kill -3
>
> I am looking for a simple solution like doing jstack / kill -3 when someone
> presses abort button on the jenkins.
>
> Can someone suggest how can I automate this or some better way of handling
> this?
>

Re: Same snapshot deploy number for entire build - possible

[Tibor Digana]

Hi Francois and Dan,

I understood it the same way as Francois mentioned. Not sure if NN in the
format "artifactId-version-timestamp-NN" is a bug. Who cares is probably
someone who downloads the artifact manually, maybe the QA.
Also downloading the artifacts from Nexus never was so trivial for QA and
development team.
There's Nexus Proffessional and the Staging Repos but I found it useful
only in OSS developers.

What was found acceptable was the solution where the QA does not traverse
the path of groupId/artifactId in the repo, and it was a simple button in
GUI and automatic deployment. Something where nobody downloads the artifact
directly.
My colleagues like integrating release candidates and not the Snapsthots
because Snapshots are very volatile and the RCs are positively deployed
ones or two times a month - rarely.

If the Snapshots must be downloaded every day then the question is why such
processes exist in the company or what's wrong with the project structures,
and what is missing in the automatic deployment.

Cheers
Tibor17



On Sun, Sep 15, 2019 at 10:15 PM Francois Marot 
wrote:

> I'm sorry to insist but nevertheless I insist ;). I may have misunderstood
> the problem but as I understand it, the whole problem can be sumed up by:
> " the fact that the repository adds a number at the end of the deployed
> files is a problem because not all artifacts deployed from the same reactor
> may not get the same suffix/number if some previous build failed half way".
> I still do not see how it is a problem as it is only a problem if one wants
> to get each files manually from the filesystem. In this case he does not
> know the *right* number for each artifact.
> But if the QA want to download all the artifacts belonging to the latest
> build, all he has to do is create a pom.xml referencing all those artifact,
> use a variable as the version number and use the dependency plugin (
>
> https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html
> ) to retrieve the artifacts locally.
>
> This way, what you see as a problem is hust an internal implementation
> detail of Maven/repository that you can circumvent easily.
>
> Again, I may have misunderstood so please excuse me if I'm talking nonsense
> but I thought it could help.
>
> Regards
>
>
>
>
>
>
>
> *- - - - -François Marot06 50 91 96 38*
>
>
>
> On Thu, 12 Sep 2019 at 04:07, Dan Tran  wrote:
>
> > Hello Maven Users and Development Team
> >
> > Currently, artifact deployed as snapshot at Maven repository has the
> > following format
> >
> >  artifactId-version-timestamp-NN
> >
> > where NN auto-incremented at each maven module and the number varies
> >
> > Is there a way to use same snapshot NN for the entire multi-module maven
> > build?
> >
> > If I have to implement a solution, would it be as an extension or I have
> to
> > tinker with maven-deploy-plugin?
> >
> > Very appreciated any advice
> >
> > -D
> >
>

Re: Same snapshot deploy number for entire build - possible

[Tibor Digana]

Dan, you know how we solved this problem, we wrote Jenkinsfile with
interactive GUI. The release manager of QA filled out the items in web GUI
of Jenkins, means Version, Deployment IP in QA machines and some build
options. Simply we moved the responsibility to the person who argued the
most about the builds with different versions.

On Sat, Sep 14, 2019 at 7:17 AM Dan Tran  wrote:

> Hi Jason,
>
> There is no problem having maven to maven snapshot dependencies between
> teams.
>
> The problem arises when you have 3 to 4 installer type artifacts landing on
> QA  teams who have to install/deploy and coordinate
>
>  Having the same snapshot number at the end of each installer artifact
> helps.  Knowing all coming from same build
>
> Still waiting for the maven dev team to chime in if there is possible
> solution :-)
>
> Thanks for all feedbacks
>
> -D
>
>
>
>
> On Fri, Sep 13, 2019 at 5:33 PM Jason Young 
> wrote:
>
> > Dan,
> >
> > Why are people asking about anything after `SNAPSHOT` in the version
> > number, i.e. why do they care? Are discrepancies causing build failures
> > somehow?
> >
> > My team's projects depend on each other with `SNAPSHOT` versions but
> > without specifying a build number or timestamp, e.g.
> > `1.2.3-SNAPSHOT`. This, combined with a policy to
> always
> > get the latest SNAPSHOT (just like the `-U` argument only applied
> > implicitly), makes every build use the latest SNAPSHOT of any
> dependencies
> > it does not build from source. Nobody ever asks me about timestamps or
> > build numbers that e.g. Nexus keeps up with.
> >
> > Regarding the policy or the -U argument, IMO these are necessary for
> > correct builds because the default policy, last I checked, is to download
> > the latest SNAPSHOT only if Maven hasn't checked in the last 24 hours,
> > which I find bewildering.
> >
> > Again, you can define the version _once for all projects_ in a parent
> > pom.xml. Let us know if that makes sense or if it is not an option for
> some
> > reason.
> >
> > HTH. Sorry if I still don't understand the problem.
> >
> > On Fri, Sep 13, 2019 at 6:22 PM Dan Tran  wrote:
> >
> > > @ Tamás Cservenák you read my mind thanks
> > >
> > > The problem I am facing is, out of a few hundred artifacts deployed
> every
> > > build.
> > > There is a handful of artifacts that landed on QA side. By having the
> > same
> > > 'buildNo/snapshotNo'
> > >  ( ie artifactId-version-timestamp-buildNo.xx)  it is much easier to
> > > communicate,
> > > otherwise, it is a constant problem explaining why they are not the
> same
> > >
> > > This is an ongoing problem at my workplace.
> > >
> > > deployAtEnd never work for us
> > > https://issues.apache.org/jira/projects/MDEPLOY especially this one
> > > https://issues.apache.org/jira/projects/MDEPLOY/issues/MDEPLOY-226
> > >
> > > We can switch to release build but that is not an option since we would
> > run
> > > out  of storage quickly and have to purge ourselves
> > >
> > > The question here what is the best way to implement an option asking
> > > maven-deploy-plugin to use the same provided 'buildNo' ? possible?
> > >
> > > Thanks
> > >
> > > -D
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Sep 13, 2019 at 1:53 PM Francois Marot <
> francois.ma...@gmail.com
> > >
> > > wrote:
> > >
> > > > OK, I get the "problem" but in fact I do not think this is a problem.
> > > > How those files (with the number suffix) are named, whether you
> deploy
> > > (to
> > > > a remote repo) or install (to a local folder), is just an
> > implementation
> > > > detail. You should never end up accessing those files by their name.
> > > > Let me explain: if you want to get all the 3 latest artifacts,
> whatever
> > > the
> > > > file name and the timestamp version, you can just create a pom having
> > > those
> > > > 3 artifacts declared as dependencies and use maven dependency plugin
> (
> > > >
> > >
> >
> https://maven.apache.org/plugins/maven-dependency-plugin/plugin-info.html
> > > > )
> > > > to copy those artifacts in a directory. Use the "-U" flag to make
> sure
> > to
> > > > get the latest version. This way, maven will care about the file
> names,
> > > but
> > > > you will not.
> > > >
> > > > I hope I can help
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, 13 Sep 2019 at 22:42, Tamás Cservenák 
> > > wrote:
> > > >
> > > > > Howdy,
> > > > >
> > > > > so what Dan is asking for is I think the following thing:
> > > > > On multi module snapshot deploy, the last bit of snapshot
> timestamped
> > > > > version is "buildNo".
> > > > >
> > > > > Consider following scenario: you have a 3 module reactor build:
> > > > > i) you deploy first time: the buildNo is -1
> > > > > ii) you deploy second time, and 2nd module UT fails: result in repo
> > is
> > > > 1st
> > > > > module has -2, while the rest, as module2 failed, is not deployed
> > > > > iii) you deploy third time: the build No is -3 for 1st module,
> while
> > it
> > > > is
> > > > > -2 for the 

Re: Same snapshot deploy number for entire build - possible

[Tibor Digana]

I think the timestamp after "-SNAPSHOT" is something which should not be
customized as by Maven design.
The version before "-SNAPSHOT"is something which is up to you.
Some companies customize the version to *--* executed on Jenkins CI.
If it is a problem in multimodule project with messy timestamp then it is
strange bug. You can configure installAtEnd=true
https://maven.apache.org/plugins/maven-install-plugin/install-mojo.html#installAtEnd
but it is only a workaround.

On Fri, Sep 13, 2019 at 10:42 PM Tamás Cservenák 
wrote:

> Howdy,
>
> so what Dan is asking for is I think the following thing:
> On multi module snapshot deploy, the last bit of snapshot timestamped
> version is "buildNo".
>
> Consider following scenario: you have a 3 module reactor build:
> i) you deploy first time: the buildNo is -1
> ii) you deploy second time, and 2nd module UT fails: result in repo is 1st
> module has -2, while the rest, as module2 failed, is not deployed
> iii) you deploy third time: the build No is -3 for 1st module, while it is
> -2 for the rest.
>
> All sounds great ("as it should be"), but buildNo has "fall apart". 3rd
> deployment will have snapshots that will have their version like
> 1.0-mmdd.hhmmss-3 while the rest version is 1.0-mmdd.hhmmss-2.
>
> Determining buildNo is possible only from maven metadata.xml, that may be
> overkill. Nothing logically "groups" the two version above, even if they
> were deployed at same time, by the same build.
>
> Deploy at end may help here, yes, but personally, I dislike the fact how
> buildNo is calculated (md get, buildNo++ jar put,, modified md put).
>
> Also, this topic seems to me, like somewhat related to the overall issue of
> https://issues.apache.org/jira/browse/MNG-6581
>
> Thanks,
> T
>
>
>
> On Fri, Sep 13, 2019 at 8:32 PM Francois Marot 
> wrote:
>
> >  can you tell us a little bit more about your problem please ?
> > You say "Currently, artifact deployed as snapshot at Maven repository has
> > the following format: artifactId-version-timestamp-NN ". Do youmean the
> > filename in the repo ? If so, why is it a problem for you ?
> > Share more with us and I think we'll suggest solution more adapted for
> your
> > use case  ;)
> >
> > Regards,
> > Francois
> >
> >
> >
> > On Thu, 12 Sep 2019 at 04:07, Dan Tran  wrote:
> >
> > > Hello Maven Users and Development Team
> > >
> > > Currently, artifact deployed as snapshot at Maven repository has the
> > > following format
> > >
> > >  artifactId-version-timestamp-NN
> > >
> > > where NN auto-incremented at each maven module and the number varies
> > >
> > > Is there a way to use same snapshot NN for the entire multi-module
> maven
> > > build?
> > >
> > > If I have to implement a solution, would it be as an extension or I
> have
> > to
> > > tinker with maven-deploy-plugin?
> > >
> > > Very appreciated any advice
> > >
> > > -D
> > >
> >
>

Re: java 1.8 and java 11 using toolchains plus compiler and surefire

[Tibor Digana]

Hi John,

See this page, the toolchain and JAXB and much more is decribed there
https://maven.apache.org/surefire/maven-surefire-plugin/java9.html

We designed Surefire to understand the compiled sources (src/main/java)
with Java Modularity.
Not the modular test sources. I think we do not have any test for such
usecase.

I am not the best berson to answer Jigsaw stuff.
Robert Sholte is the expert in this area.

We cannot help you right now because you sent a little information and the
stacktrace is not the root cause.
So you should post your GitHub project where we can investigate the error.

Cheers
Tibor17


On Sat, Aug 31, 2019 at 7:53 PM John Patrick  wrote:

> evening,
>
> i'm having trouble testing a multi-release jar project using
> toolchains. i want to test it using both java 1.8 and java 11.
>
> i've the following structure;
> src/main/java
> src/main/java11
> src/test/java
> src/test/java11
>
> tried both maven-surefire-plugin v 2.22.2 and 3.0.0-M3
>
> if i set java to 1.8 and do mvn clean install, everything works but it
> uses java 1.8 for the testing.
>
> if i set java to 11 and do maven clean install, it fails starting surefire.
>
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException:
> The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
>
> How can I test using java 1.8 then execute tests again using java 11.
>
> What profile or toolchain settings can i configure so for a surefire
> execution it uses the java version i choose?
>
> John
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Found Issues - Release Apache Maven Version 3.6.2

[Tibor Digana]

Hi Alexander,

Would it solve your problem if we uncover the method [1] and develop a
builder for the chain of methods [2]?
To uncover [2] means to make the Plexus Container API accessible within the
builder.
Perhaps more has to be done but that's up to the future collaborative work
on GitHub.

[1]:
https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L281
[2]:
https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L276-L288

Cheers
Tibor17

On Thu, Aug 29, 2019 at 3:39 PM Alexander Bubenchikov <
alexander.bubenchi...@jetbrains.com> wrote:

> Hi Stuart
> E.g.
> https://github.com/JetBrains/intellij-community/blob/master/plugins/maven/maven3-server-impl/src/org/jetbrains/idea/maven/server/Maven3XServerEmbedder.java
> customizeComponents method
>
> Originally idea use own components defined in
> META-INF/plexus/components.xml with hints "ide", then original maven
> components are replaced in plexus container. Container instance is getting
> using reflection from MavenCli,
> This functionality is very old. It was an only solution before introducing
> extensions in maven, as I understand. Also at the moment, we still support
> IDE compatibility with maven versions starting from 3.0, there are still
> some amount of users who use really old maven versions in their enterprise
> projects.
>
> Thank you for your answer, I'll consider refactoring maven server to core
> extension mechanism for maven 3.3.1 and above
>
>
>
>
> On Thu, Aug 29, 2019 at 3:57 PM Stuart McCulloch 
> wrote:
>
>> How are you replacing them currently?
>>
>> The typical way is to use the extensions mechanism:
>> https://maven.apache.org/docs/3.3.1/release-notes.html#Core_Extensions
>>
>> Components contributed via an extension have a higher priority over the
>> original component in core (assuming that they have the same JSR330 name
>> or
>> Plexus hint)
>>
>> On Thu, 29 Aug 2019 at 11:46, Alexander Bubenchikov <
>> alexander.bubenchi...@jetbrains.com> wrote:
>>
>> > Hi Enrico, my name is Alex, I've joined to Jetbrains this year and
>> > responsible for maven integration and Intellij idea.
>> >
>> > he issue happen because we replace some components in maven
>> > (ModelInterpolator in this case) to our own implementation which have
>> > injected PathTranslator and UrlNormalizer
>> > I've workarounded the issue in our code, but I didn't dig well into
>> this.
>> > Is there any new way to replace maven components?
>> >
>> > On Wed, Aug 28, 2019 at 11:57 PM Enrico Olivelli 
>> > wrote:
>> >
>> > > It may be due to any change regarding jsr 330 like
>> > > https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-6686
>> > >
>> > >
>> > > I think it is an issue for Idea and not for us.
>> > > It would be good to have some developer from Jetbrains on this list
>> > >
>> > >
>> > > Enrico
>> > >
>> > > Il mer 28 ago 2019, 22:23 Tibor Digana  ha
>> > > scritto:
>> > >
>> > > > I do not have NPE in the log.
>> > > > Guice is certainly not CDI. Moving Guice to CDI must be painful.
>> > > > One reason why PathTranslator could not be found is that there are
>> > > several
>> > > > bean instances of the same interface.
>> > > > Second problem might go with the Guice/CDI.
>> > > > See this inheritance:
>> > > >
>> > > > @Named
>> > > > @Singleton
>> > > > public class DefaultPathTranslator
>> > > > implements PathTranslator
>> > > > {
>> > > >
>> > > > public interface PathTranslator
>> > > > {
>> > > >
>> > > >
>> > > >
>> > > > On Wed, Aug 28, 2019 at 10:04 PM Filipe Sousa 
>> > wrote:
>> > > >
>> > > >> Hi,
>> > > >>
>> > > >> Not sure if it’s the same bug I commented in
>> > > >>
>> > >
>> >
>> https://issues.apache.org/jira/browse/MNG-6638?focusedCommentId=16852351=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16852351
>> > > >>
>> > > >> I reported to Jetbrains
>> > > https://youtrack.jetbrains.com/issue/IDEA-215315
>> > > >> <https://youtrack.jetbrains.com/issue/IDEA-215315> and is

Re: Found Issues - Release Apache Maven Version 3.6.2

[Tibor Digana]

We are draming of Maven 4 and Maven 5 and features in it, and we have
legacy code + patch over a patch.
We are using Guice with a nice Guice API and we are using components.xml
like it was in the old Spring.
Would it be a good time to change some code in favor of modern style?
Nevertheless this particular singleton is one instance in Guice context and
interfaces with polymorhism are ready for more classes which would not work
because we expect just only one class, so would it be good idea to cut off
the old era away and do the things in a different way?

Let's see this example with Guice:

bind(org.apache.maven.model.path.PathTranslator.class)
.toInstance(new org.apache.maven.model.path.DefaultPathTranslator());


No reflection, no XML, no orrididden beans, no preconditions of
default/non-default beans no workarounds.
It is just as easy as it can be with Guice, and this would be then a
solution for MavenCli and Maven Embedder used by any tool, not only
IntelliJ IDEA.
The tools will "fill out" the container with singletons or stateless beans
or services and that's it.
Then only call execute() method and handle callback calls with received
events from the Maven core.

So it's just the work to separate execution of Maven from deployment of
beans to the container.
Split it and it is the way for programming style of Open Closed principle
and customization of Maven as well.

Cheers
Tibor17

On Thu, Aug 29, 2019 at 3:39 PM Alexander Bubenchikov <
alexander.bubenchi...@jetbrains.com> wrote:

> Hi Stuart
> E.g.
> https://github.com/JetBrains/intellij-community/blob/master/plugins/maven/maven3-server-impl/src/org/jetbrains/idea/maven/server/Maven3XServerEmbedder.java
> customizeComponents method
>
> Originally idea use own components defined in
> META-INF/plexus/components.xml with hints "ide", then original maven
> components are replaced in plexus container. Container instance is getting
> using reflection from MavenCli,
> This functionality is very old. It was an only solution before introducing
> extensions in maven, as I understand. Also at the moment, we still support
> IDE compatibility with maven versions starting from 3.0, there are still
> some amount of users who use really old maven versions in their enterprise
> projects.
>
> Thank you for your answer, I'll consider refactoring maven server to core
> extension mechanism for maven 3.3.1 and above
>
>
>
>
> On Thu, Aug 29, 2019 at 3:57 PM Stuart McCulloch 
> wrote:
>
>> How are you replacing them currently?
>>
>> The typical way is to use the extensions mechanism:
>> https://maven.apache.org/docs/3.3.1/release-notes.html#Core_Extensions
>>
>> Components contributed via an extension have a higher priority over the
>> original component in core (assuming that they have the same JSR330 name
>> or
>> Plexus hint)
>>
>> On Thu, 29 Aug 2019 at 11:46, Alexander Bubenchikov <
>> alexander.bubenchi...@jetbrains.com> wrote:
>>
>> > Hi Enrico, my name is Alex, I've joined to Jetbrains this year and
>> > responsible for maven integration and Intellij idea.
>> >
>> > he issue happen because we replace some components in maven
>> > (ModelInterpolator in this case) to our own implementation which have
>> > injected PathTranslator and UrlNormalizer
>> > I've workarounded the issue in our code, but I didn't dig well into
>> this.
>> > Is there any new way to replace maven components?
>> >
>> > On Wed, Aug 28, 2019 at 11:57 PM Enrico Olivelli 
>> > wrote:
>> >
>> > > It may be due to any change regarding jsr 330 like
>> > > https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-6686
>> > >
>> > >
>> > > I think it is an issue for Idea and not for us.
>> > > It would be good to have some developer from Jetbrains on this list
>> > >
>> > >
>> > > Enrico
>> > >
>> > > Il mer 28 ago 2019, 22:23 Tibor Digana  ha
>> > > scritto:
>> > >
>> > > > I do not have NPE in the log.
>> > > > Guice is certainly not CDI. Moving Guice to CDI must be painful.
>> > > > One reason why PathTranslator could not be found is that there are
>> > > several
>> > > > bean instances of the same interface.
>> > > > Second problem might go with the Guice/CDI.
>> > > > See this inheritance:
>> > > >
>> > > > @Named
>> > > > @Singleton
>> > > > public class DefaultPathTranslator
>> > > > implements PathTranslator
>> > > > {
>> > > >
>&g

Re: Found Issues - Release Apache Maven Version 3.6.2

[Tibor Digana]

Having interface in a singleton is a kind of silly design because these are
two abstractions which go one against the other.
The CDI has an injection Provider and you caniterate over beans of certain
bean type and select according @Name then.
I think this mechanism can be used.

On Thu, Aug 29, 2019 at 12:46 PM Alexander Bubenchikov <
alexander.bubenchi...@jetbrains.com> wrote:

> Hi Enrico, my name is Alex, I've joined to Jetbrains this year and
> responsible for maven integration and Intellij idea.
>
> he issue happen because we replace some components in maven
> (ModelInterpolator in this case) to our own implementation which have
> injected PathTranslator and UrlNormalizer
> I've workarounded the issue in our code, but I didn't dig well into this.
> Is there any new way to replace maven components?
>
> On Wed, Aug 28, 2019 at 11:57 PM Enrico Olivelli 
> wrote:
>
>> It may be due to any change regarding jsr 330 like
>> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-6686
>>
>>
>> I think it is an issue for Idea and not for us.
>> It would be good to have some developer from Jetbrains on this list
>>
>>
>> Enrico
>>
>> Il mer 28 ago 2019, 22:23 Tibor Digana  ha
>> scritto:
>>
>> > I do not have NPE in the log.
>> > Guice is certainly not CDI. Moving Guice to CDI must be painful.
>> > One reason why PathTranslator could not be found is that there are
>> several
>> > bean instances of the same interface.
>> > Second problem might go with the Guice/CDI.
>> > See this inheritance:
>> >
>> > @Named
>> > @Singleton
>> > public class DefaultPathTranslator
>> > implements PathTranslator
>> > {
>> >
>> > public interface PathTranslator
>> > {
>> >
>> >
>> >
>> > On Wed, Aug 28, 2019 at 10:04 PM Filipe Sousa  wrote:
>> >
>> >> Hi,
>> >>
>> >> Not sure if it’s the same bug I commented in
>> >>
>> https://issues.apache.org/jira/browse/MNG-6638?focusedCommentId=16852351=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16852351
>> >>
>> >> I reported to Jetbrains
>> https://youtrack.jetbrains.com/issue/IDEA-215315
>> >> <https://youtrack.jetbrains.com/issue/IDEA-215315> and is supposed to
>> be
>> >> fixed in 2019.3
>> >>
>> >> > On 28 Aug 2019, at 20:43, Tibor Digana 
>> wrote:
>> >> >
>> >> > I used Maven 3.6.2 in the IntelliJ IDEA 2019.2.1 and I found these
>> >> errors
>> >> > in the log file:
>> >> > ~/.IntelliJIdea2019.2/system/log/idea.log
>> >> >
>> >> > 2019-08-28 21:31:32,072 [255937677]  ERROR -
>> >> #org.jetbrains.idea.maven
>> >> > - com.google.inject.CreationException: Unable to create injector, see
>> >> the
>> >> > following errors:
>> >> >
>> >> > 1) No implementation for org.apache.maven.model.path.PathTranslator
>> was
>> >> > bound.
>> >> >  while locating org.apache.maven.model.path.PathTranslator
>> >> >for field at
>> >> >
>> >>
>> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
>> >> > Source)
>> >> >  at
>> >> >
>> >>
>> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
>> >> >
>> >> > 2) No implementation for org.apache.maven.model.path.UrlNormalizer
>> was
>> >> > bound.
>> >> >  while locating org.apache.maven.model.path.UrlNormalizer
>> >> >for field at
>> >> >
>> >>
>> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
>> >> > Source)
>> >> >  at
>> >> >
>> >>
>> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
>> >> >
>> >> > 2 errors
>> >> > java.lang.RuntimeException: com.google.inject.CreationException:
>> Unable
>> >> to
>> >> > create injector, see the following errors:
>> >> >
>> >> > 1) No implementation for org.apache.maven.model.path.PathTranslator
>> was
>> >> > bound.
>> >> >  while locating org.apache.maven.model.path.PathT

Re: Found Issues - Release Apache Maven Version 3.6.2

[Tibor Digana]

I do not have NPE in the log.
Guice is certainly not CDI. Moving Guice to CDI must be painful.
One reason why PathTranslator could not be found is that there are several
bean instances of the same interface.
Second problem might go with the Guice/CDI.
See this inheritance:

@Named
@Singleton
public class DefaultPathTranslator
implements PathTranslator
{

public interface PathTranslator
{



On Wed, Aug 28, 2019 at 10:04 PM Filipe Sousa  wrote:

> Hi,
>
> Not sure if it’s the same bug I commented in
> https://issues.apache.org/jira/browse/MNG-6638?focusedCommentId=16852351=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16852351
>
> I reported to Jetbrains https://youtrack.jetbrains.com/issue/IDEA-215315 <
> https://youtrack.jetbrains.com/issue/IDEA-215315> and is supposed to be
> fixed in 2019.3
>
> > On 28 Aug 2019, at 20:43, Tibor Digana  wrote:
> >
> > I used Maven 3.6.2 in the IntelliJ IDEA 2019.2.1 and I found these errors
> > in the log file:
> > ~/.IntelliJIdea2019.2/system/log/idea.log
> >
> > 2019-08-28 21:31:32,072 [255937677]  ERROR -
> #org.jetbrains.idea.maven
> > - com.google.inject.CreationException: Unable to create injector, see the
> > following errors:
> >
> > 1) No implementation for org.apache.maven.model.path.PathTranslator was
> > bound.
> >  while locating org.apache.maven.model.path.PathTranslator
> >for field at
> >
> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
> > Source)
> >  at
> >
> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
> >
> > 2) No implementation for org.apache.maven.model.path.UrlNormalizer was
> > bound.
> >  while locating org.apache.maven.model.path.UrlNormalizer
> >for field at
> >
> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
> > Source)
> >  at
> >
> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
> >
> > 2 errors
> > java.lang.RuntimeException: com.google.inject.CreationException: Unable
> to
> > create injector, see the following errors:
> >
> > 1) No implementation for org.apache.maven.model.path.PathTranslator was
> > bound.
> >  while locating org.apache.maven.model.path.PathTranslator
> >for field at
> >
> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
> > Source)
> >  at
> >
> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
> >
> > 2) No implementation for org.apache.maven.model.path.UrlNormalizer was
> > bound.
> >  while locating org.apache.maven.model.path.UrlNormalizer
> >for field at
> >
> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
> > Source)
> >  at
> >
> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
> >
> > 2 errors
> > at
> >
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:543)
> > at
> >
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:159)
> > at
> >
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:106)
> > at com.google.inject.Guice.createInjector(Guice.java:87)
> > at com.google.inject.Guice.createInjector(Guice.java:69)
> > at com.google.inject.Guice.createInjector(Guice.java:59)
> > at
> >
> org.codehaus.plexus.DefaultPlexusContainer.addComponent(DefaultPlexusContainer.java:344)
> > at
> >
> org.codehaus.plexus.DefaultPlexusContainer.addComponent(DefaultPlexusContainer.java:332)
> > at
> >
> org.jetbrains.idea.maven.server.Maven3XServerEmbedder.customizeComponents(Maven3XServerEmbedder.java:573)
> > at
> >
> org.jetbrains.idea.maven.server.Maven3XServerEmbedder.customize(Maven3XServerEmbedder.java:542)
> > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> > at
> >
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> > at
> >
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> > at java.rmi/sun.rmi.transport.Transport$1.run(Transp

Found Issues - Release Apache Maven Version 3.6.2

[Tibor Digana]

I used Maven 3.6.2 in the IntelliJ IDEA 2019.2.1 and I found these errors
in the log file:
~/.IntelliJIdea2019.2/system/log/idea.log

2019-08-28 21:31:32,072 [255937677]  ERROR -  #org.jetbrains.idea.maven
- com.google.inject.CreationException: Unable to create injector, see the
following errors:

1) No implementation for org.apache.maven.model.path.PathTranslator was
bound.
  while locating org.apache.maven.model.path.PathTranslator
for field at
org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
Source)
  at
org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)

2) No implementation for org.apache.maven.model.path.UrlNormalizer was
bound.
  while locating org.apache.maven.model.path.UrlNormalizer
for field at
org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
Source)
  at
org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)

2 errors
java.lang.RuntimeException: com.google.inject.CreationException: Unable to
create injector, see the following errors:

1) No implementation for org.apache.maven.model.path.PathTranslator was
bound.
  while locating org.apache.maven.model.path.PathTranslator
for field at
org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
Source)
  at
org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)

2) No implementation for org.apache.maven.model.path.UrlNormalizer was
bound.
  while locating org.apache.maven.model.path.UrlNormalizer
for field at
org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
Source)
  at
org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)

2 errors
at
com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:543)
at
com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:159)
at
com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:106)
at com.google.inject.Guice.createInjector(Guice.java:87)
at com.google.inject.Guice.createInjector(Guice.java:69)
at com.google.inject.Guice.createInjector(Guice.java:59)
at
org.codehaus.plexus.DefaultPlexusContainer.addComponent(DefaultPlexusContainer.java:344)
at
org.codehaus.plexus.DefaultPlexusContainer.addComponent(DefaultPlexusContainer.java:332)
at
org.jetbrains.idea.maven.server.Maven3XServerEmbedder.customizeComponents(Maven3XServerEmbedder.java:573)
at
org.jetbrains.idea.maven.server.Maven3XServerEmbedder.customize(Maven3XServerEmbedder.java:542)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
at
java.rmi/sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
at
java.rmi/sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at
java.rmi/java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:209)
at
java.rmi/java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:161)
at com.sun.proxy.$Proxy216.customize(Unknown Source)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 

Re: [VOTE] Retire Maven OSGi

[Tibor Digana]

Hi Dirk,

This project is not worth a plugin, it is a pure converter of single class.
In this case it is legal to adopt this code according to the license.
Anyway the Maven is not the OSGi. The OSGi is not our key API we deliver to
our customers.
We have to save our energy on what makes Maven The Maven.

Cheers
Tibor17

On Fri, Aug 23, 2019 at 5:21 PM Dirk Mahler 
wrote:

> Hi,
>
> I'm not using it but just for curiosity I checked on Maven Central if
> some artifacts have been pushed there recently that declare a dependency
> to this artifact (maven-osgi):
>
> "0.2.0" "org.glassfish.hk2:consolidatedbundle-maven-plugin:pom:2.6.0"
> "2019-07-31T22:22:29Z"
> "0.2.0" "org.glassfish.hk2:osgiversion-maven-plugin:pom:2.6.0"
> "2019-07-31T22:21:55Z"
> "0.2.0" "org.apache.sling:slingstart-maven-plugin:pom:1.8.4"
> "2019-06-13T11:29:18Z"
> "0.2.0" "org.apache.sling:slingfeature-maven-plugin:pom:1.0.4"
> "2019-06-13T09:52:03Z"
> ...
>
> Hope it helps for voting.
>
> Cheers
>
> Dirk
>
> -- Originalnachricht --
> Von: "Robert Scholte" 
> An: "Apache Maven Dev" 
> Cc: "Apache Maven Users" 
> Gesendet: 23.08.2019 15:17:23
> Betreff: [VOTE] Retire Maven OSGi
>
> >Hi,
> >
> >The Apache Maven project consist of about 90 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects,
> including our ambitious ideas for the next major version(s) of Maven
> itself.
> >To be able to gain more focus we need to criticize the current
> subprojects  and decide if it is worth maintaining.
> >
> >https://maven.apache.org/shared/maven-osgi/ describes the main purpose
> in  one line: Library for Maven-OSGi integration.
> >There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in
> December  2007 and just one open issue by Stuart McCulloch regarding an
> unclosed jar.
> >It is unclear to me if this library is still used. The library is based
> on  just 3 files: interface, default implementation and dedicated exception.
> >Either the library is complete or never used anymore. In both cases I
> see  no real reason to maintain it.
> >
> >I therefore propose that we retire the maven-osgi library.
> >
> >I don't think it makes sense to do a final release. Instead we should
> update the documentation and freeze the codebase.
> >
> >The process for retiring a plugin is described here:
> >https://maven.apache.org/developers/retirement-plan-plugins.html  [
> https://maven.apache.org/developers/retirement-plan-plugins.html]
> >
> >The vote is open for 72 hours.
> >[ ] +1 Yes, it's about time
> >[ ] -1 No, because...
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >For additional commands, e-mail: dev-h...@maven.apache.org
> >

Re: [VOTE] Retire Maven OSGi

[Tibor Digana]

There's very good BND plugin org.apache.felix:maven-bundle-plugin.
+1 to retire and delete old https://maven.apache.org/shared/maven-osgi/
Cheers
Tibor17

On Fri, Aug 23, 2019 at 3:17 PM Robert Scholte  wrote:

> Hi,
>
> The Apache Maven project consist of about 90 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects,
> including our ambitious ideas for the next major version(s) of Maven
> itself.
> To be able to gain more focus we need to criticize the current
> subprojects
> and decide if it is worth maintaining.
>
> https://maven.apache.org/shared/maven-osgi/ describes the main purpose
> in
> one line: Library for Maven-OSGi integration.
> There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December
> 2007 and just one open issue by Stuart McCulloch regarding an unclosed jar.
> It is unclear to me if this library is still used. The library is based
> on
> just 3 files: interface, default implementation and dedicated exception.
> Either the library is complete or never used anymore. In both cases I see
> no real reason to maintain it.
>
> I therefore propose that we retire the maven-osgi library.
>
> I don't think it makes sense to do a final release. Instead we should
> update the documentation and freeze the codebase.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
> [https://maven.apache.org/developers/retirement-plan-plugins.html]
>
> The vote is open for 72 hours.
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: surefire-plugin v3.0.0-M4 release

[Tibor Digana]

Hi Walid,

You are writing right on the time!
We could not make a new release because we interrupted important fix in
Surefire and we concentrated on:
+ build process issues
+ new Maven release 3.6.2
+ Resolver 1.4.1
+ JDK 1.8 vs Archetype 3.1.1 and 3.1.2

We have finished all these activities and the team will cut a new version
of Maven quite soon.
We have returned back from vacations, and Enrico and me will recover the
activity we previously interrupted in Surefire.
I guess we won't have a big blocker next days and hopefully we will get a
new release soon!

Cheers
Tibor17


On Thu, Aug 22, 2019 at 11:38 PM Walid Bounouar 
wrote:

> Hi,
>
> I am just wondering if there is a timeline for the release of the
> surefire-plugin version 3.0.0-M4 or if there's a way for me to track such a
> thing?
>
> Thanks for the help!
>
> Walid Bounouar
>

[ANN] Apache Maven Archetype Plugin version 3.1.2

[Tibor Digana]

The Apache Maven team is pleased to announce the release of the Apache
Maven Archetype Plugin, version 3.1.2.

The Archetype Plugin allows the user to create a Maven project from an
existing template called an archetype. It also allows the user to create an
archetype from an existing project.

https://maven.apache.org/archetype/maven-archetype-plugin/

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


   org.apache.maven.plugins
   maven-archetype-plugin
   3.1.2


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

Release Notes - Maven Archetype - Version 3.1.2

Bug

[ARCHETYPE-571] - Unable to generate project which has pom with
multiple profiles with modules section

Improvement

[ARCHETYPE-578] - Deleted unnecessary calls ".flush()" on I/O streams
[ARCHETYPE-579] - Missing try-with-resources and createNewFile() before
new FileOutputStream(f)
[ARCHETYPE-582] - Additional module in generated POM should keep line
indentation 2 chars

Test

[ARCHETYPE-580] - The build fails with integration test
(build-and-run-its) to find expected text in 'build.log'
[ARCHETYPE-581] - The build fails in the integration tests because
'build.log' is being copied and failed

Dependency upgrade

[ARCHETYPE-569] - Update to latest version of plexus utils
[ARCHETYPE-575] - Upgrade maven-artifact-transfer to 0.11.0
[ARCHETYPE-577] - Upgrade Wagon to 3.3.3


Enjoy,

-The Apache Maven team

The release of Archetype 3.1.2 planned for today

[Tibor Digana]

 Hi,
Just an announcement.
Today I would like to release Archetype 3.1.2.
https://issues.apache.org/jira/projects/ARCHETYPE/versions/12345957

Cheers
Tibor17

[ANN] Apache Maven Resolver 1.4.1 released

[Tibor Digana]

The Apache Maven team is pleased to announce the release of the Maven
Resolver 1.4.1.

https://maven.apache.org/resolver/

Release Notes - Maven Resolver - Version 1.4.1

** Task
 * [MRESOLVER-92] - Revert MRESOLVER-7


Enjoy,

-The Apache Maven team

Re: [VOTE] Retire Maven Repository Builder

[Tibor Digana]

+1

On Wed, Aug 7, 2019 at 9:13 PM Robert Scholte  wrote:

> Hi,
>
> The Apache Maven project consist of about 90 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects,
> including our ambitious ideas for the next major version(s) of Maven
> itself.
> To be able to gain more focus we need to criticize the current
> subprojects
> and decide if it is worth maintaining.
>
> https://maven.apache.org/shared/maven-repository-builder/ describes the
> main purpose in one line: Maven shared components. Okay, that's actually
> quite bad.
> Based on
>
> https://mvnrepository.com/artifact/org.apache.maven.shared/maven-repository-builder
>
> the library isn't used a lot. Both maven-assembly-plugin and
> maven-plugin-testing-tools don't use this library anymore.
> The sourcecode looks a bit like it has the same purpose as
> dependency:copy-dependencies.
>
> I therefore propose that we retire the maven-repository-builder.
>
> I don't think it makes sense to do a final release. Instead we should
> update the documentation and freeze the codebase.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
> [https://maven.apache.org/developers/retirement-plan-plugins.html]
>
> The vote is open for 72 hours.
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Using Git tags to cut releases to Maven Central from TravisCI

[Tibor Digana]

Ben, you have to delete the remote Tag from Git if you want to repeat the
release of the same version.
It happened many times to me and my colleagues that we had to delete the
tag for whatever reason, e.g. wrong SCM credentials or connectivity
problems.
So it was usual that we deleted the tag, fixed the problem and then we
repeated the process.
This maybe helps. It is the pseudocode of what has been done by our hands:

def ret = sh 'mvn release:prepare -DpushChanges=false'
sh 'git push origin tag yourTag'


if (ret) {
sh 'git tag -d yourTag'
sh 'git push origin :refs/tags/yourTag'
// exit 1
} else {
sh 'git push origin master'
sh 'mvn release:perform -Darguments="-DskipTests'
// ok
}


On Fri, Aug 2, 2019 at 5:19 PM Ben Podgursky  wrote:

> Thanks Hervé and Matthieu.  I'm afraid I am not following this point:
>
> > An issue with solutions like yours is reproducibility : `git checkout
> X.Y.Z && mvn install`will not build again artifact-X.Y.Z
>
> I guess I am not stating it explicitly, but once I release version X.Y.Z, I
> would never change the tag to point to a different commit, much like I
> would not change the Git commit history once it was pushed to master.  In
> Git, this would require deleting the tag and recreating it.  Even if I felt
> like doing this, it wouldn't do much good, because I cannot re-release the
> artifact to central.
>
> > you can't really predict how RELEASE value will really be related to PREV
>
> This is reasonable, although since it's my repository I do know what the
> next version will be.  I do feel this could be resolved by wrapping the
> commands I listed into a simple script that increments the version (similar
> to how the deploy plugin does it, but without the commit).
>
> I appreciate the feedback, thanks for taking the time to read this.
>
>
>
> On Thu, Aug 1, 2019 at 11:02 PM Hervé BOUTEMY 
> wrote:
>
> > thank you Matthieu for sharing
> >
> > to me, one key interesting part is:
> > > An issue with solutions like yours is reproducibility : `git checkout
> > X.Y.Z
> > > && mvn install`will not build again artifact-X.Y.Z ; but this can be
> > > considered minor depending on the use cases & needs.
> >
> > and with jgitver, there is the equivalent reproducibility issue: if a
> > release
> > creates a source tarball to be able to download and rebuild independently
> > from
> > source control (= something that is mandatory at Apache level, and IMHO a
> > good
> > practice), both Ben solution and jgitver fail at rebuilding
> >
> > I personally find these version changing commits *a key useful feature*:
> > when I
> > checkout any point in a projet scm history, whatever the scm (no Git is
> > not
> > the only scm in the world), I precisely know what precise version I'm
> > building
> > (be it a SNAPSHOT, where by definition the version is fuzzy, or a release
> > where
> > the version is strictly defined at a precise state for the whole source
> > tree)
> >
> >
> > What Maven could do better to me is avoiding modifying every pom.xml file
> > in
> > multi-module project: yes, here, modifying only the root pom would be an
> > improvement.
> > I know there is a MNG Jira issue (even if I can't find it right now)
> >
> >
> > But definitely, trying to remove versions changes at source level seems
> to
> > me
> > not not a good objective because these commits are useful: the codebase
> is
> > really switching from PREV-SNAPSHOT to RELEASE to NEXT-SNAPSHOT
> > And even the fact that:
> > - you can't really predict how RELEASE value will really be related to
> PREV
> > - you'll have to make a guess at choosing NEXT
> > proves that these changes at source level are useful.
> > What we should do is making them easier
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 1 août 2019, 11:23:33 CEST Matthieu BROUILLARD a écrit :
> > > Hi Ben,
> > >
> > > several years ago I created jgitver  to
> cover
> > > such a use case and even more.
> > >
> > > It uses git information (tags, branches, commits, metadatas, ...) to
> > > automatically compute a version based on configurable rules.
> > > So like you I can simply do: `git tag X.Y.Z && mvn deploy`
> > > jgitver  brings more features &
> configuration
> > > capabilities without never modifying the pom files (like `mvn versions
> > > -dnewVersion` does).
> > >
> > > It is a solution among others but it is worthwhile trying it.
> > >
> > > An issue with solutions like yours is reproducibility : `git checkout
> > X.Y.Z
> > > && mvn install`will not build again artifact-X.Y.Z ; but this can be
> > > considered minor depending on the use cases & needs.
> > >
> > > FYI here are the projects I maintain related to the topic:
> > >
> > >- jgitver library: https://github.com/jgitver/jgitver
> > >- jgitver maven extension:
> > >https://github.com/jgitver/jgitver-maven-plugin
> > >- jgitver gradle plugin:
> > https://github.com/jgitver/gradle-jgitver-plugin
> > >
> > 

Re: There seems to be a mistake in the documentation - MAVEN SUREFIRE PLUGIN

[Tibor Digana]

Hello Moina,

I have reported this issue in JIRA
https://issues.apache.org/jira/browse/SUREFIRE-1684

Cheers
Tibor17

On Fri, Jul 19, 2019 at 2:26 PM Moina Farheen 
wrote:

> Hi,
>
> I am a beginner and just started to learn maven for my project. I was
> reading about surefire plugin on the site and found this -
>
> image.png
>
> As I see here, there are 3 goals in this plugin but why does it say there
> "Surefire Report Plugin only has one goal"
> Have I misunderstood?
>
> Appreciate response.
>
> Thanks
>

Re: There seems to be a mistake in the documentation - MAVEN SUREFIRE PLUGIN

[Tibor Digana]

btw, you did not attach the image.

You mean this?
(You can open a Jira ticket and fix in PR on
github.com/apache/maven-surefire)

The Surefire Report Plugin only has one goal (the other is a workaround):

   - surefire-report:failsafe-report-only
   

   This goal does not run the tests, it only builds the IT reports. See
   SUREFIRE-257 
   - surefire-report:report
   

   Generates the test results report into HTML format.
   - surefire-report:report-only
   

   This goal does not run the tests, it only builds the reports. It is
   provided as a work around for SUREFIRE-2
   


On Fri, Jul 19, 2019 at 2:26 PM Moina Farheen 
wrote:

> Hi,
>
> I am a beginner and just started to learn maven for my project. I was
> reading about surefire plugin on the site and found this -
>
> image.png
>
> As I see here, there are 3 goals in this plugin but why does it say there
> "Surefire Report Plugin only has one goal"
> Have I misunderstood?
>
> Appreciate response.
>
> Thanks
>

Re: the surefire maven plugin and codehaus

[Tibor Digana]

Asking Andrew. Maven is still using the old version 2.12.4 but this will be
changed, see https://issues.apache.org/jira/browse/MNG-6169

On Sat, Jun 29, 2019 at 5:05 PM Thomas Broyer  wrote:

> On Sat, Jun 29, 2019 at 4:50 PM Tibor Digana 
> wrote:
>
> > Where do we use dependency with groupId "org.codehaus.mojo"?
> >
>
> I wasn't replying to the surefire part of the OP, Tibor; only about
> org.codehaus.mojo groupId and whether those are "dead components".
>

Re: the surefire maven plugin and codehaus

[Tibor Digana]

Where do we use dependency with groupId "org.codehaus.mojo"?
Thx
Tibor

On Sat, Jun 29, 2019 at 3:18 PM Thomas Broyer  wrote:

> Artifacts using the org.codehaus.mojo groupId does not mean they "come
> from" the mojo.codehaus.org forge.
>
> All the (maintained) plugins and libraries have found a new home at
> MojoHaus, i.e. GitHub: https://www.mojohaus.org/, and they continue to be
> published within the org.codehaus.mojo groupId.
>
> On Sat, Jun 29, 2019 at 8:31 AM Marlow, Andrew
>  wrote:
>
> > Hello everyone,
> >
> >
> >
> > As we know, codehaus went dark some time ago, March 2015 in fact (see
> >
> https://www.javaworld.com/.../codehaus-the-once-great-house-of-code-has-fallen.html
> > ) . I just found out that the maven surefire plugin uses codehaus
> > components such as mojo. This works at the moment because there are so
> many
> > maven repos that contain the jar+pom+sha, so dependency resolution all
> > works and we can all build and run our unit tests. However, isn’t anyone
> > bothered by the fact that the plugin is using a dead component? What
> about
> > projects that need the source for legal reasons (e.g. the source is often
> > where the license is). What are the plans please?
> >
> >
> >
> > *Andrew Marlow*
> >
> > Consultant developer, Apex
> >
> > 38th Floor, 25 Canada Square,
> >
> > Canary Wharf, London E14 5LQ
> >
> > *T*:  020-8081-2367 / 07966-451-521
> > *E*: andrew.mar...@fisglobal.com
> > *FIS | Empowering the Financial World* [image:
> > cid:image001.png@01D112FA.C4A77D90]  >[image:
> > cid:image002.png@01D112FA.C4A77D90]  >[image:
> > cid:image003.png@01D112FA.C4A77D90] <
> https://www.linkedin.com/company/fis>
> >
> > FIS Apex (UK) Limited * Registered in England and Wales No. 3573008 *
> > Registered Office: 38th floor, 25 Canada Square, London, E14 5LQ, United
> > Kingdom
> >
> > [image: 50_3]
> >
> >
> > The information contained in this message is proprietary and/or
> > confidential. If you are not the intended recipient, please: (i) delete
> the
> > message and all copies; (ii) do not disclose, distribute or use the
> message
> > in any manner; and (iii) notify the sender immediately. In addition,
> please
> > be aware that any message addressed to our domain is subject to archiving
> > and review by persons other than the intended recipient. FIS is a trading
> > name of the following companies: Advanced Portfolio Technologies Ltd (No:
> > 6312142) | Clear2Pay Limited (No: 5792457) | Decalog (UK) Limited (No:
> > 2567370) | FIS Apex (International) Limited (No: 260) | FIS Apex (UK)
> > Limited (No. 3573008) | FIS Consulting Services (UK) Limited (No:
> 2486794)
> > | FIS Derivatives Utility Services (UK) Limited (No: 9398140) | FIS
> Energy
> > Solutions Limited (No: 1889028) | FIS Global Execution Services Limited
> > (No. 3127109) | FIS Global Trading (UK) Limited (No: 2523114) | FIS
> > Investment Systems (UK) Limited (No: 1366010) | FIS Sherwood Systems
> Group
> > Limited (No: 982833) | FIS Systems Limited (No: 1937159) | FIS Treasury
> > Systems (Europe) Limited (No: 2624209) | FIS Treasury Systems (UK)
> Limited
> > (No: 2893376) | GL Settle Limited (No: 2396127) | Integrity Treasury
> > Solutions Europe Limited (No: 3289271) | Monis Software Limited (No:
> > 2333925) | Reech Capital Limited (No: 3649490) | Solutions Plus
> Consulting
> > Services Limited (No: 3839487) | Valuelink Information Services Limited
> > (No: 3827424) all registered in England & Wales with their registered
> > office at 25 Canada Square, London E14 5LQ | FIS Global Execution
> Services
> > Limited is authorised and regulated by the Financial Conduct Authority |
> > Certegy Card Services Limited (No: 3517639) | Certegy France Limited (No:
> > 2557650) | eFunds International Limited (No: 1930117) | Fidelity
> > Information Services Limited (No: 2225203) | FIS Payments (UK) Limited
> (No:
> > 4215488) | Metavante Technologies Limited (No: 2659326) all registered in
> > England & Wales with their registered office at 1st Floor Tricorn House,
> > 51-53 Hagley Road, Edgbaston, Birmingham, West Midlands, B16 8TU, United
> > Kingdom | FIS Payments (UK) Limited is authorised and regulated by the
> > Financial Conduct Authority; some services are covered by the Financial
> > Ombudsman Service (in the UK). Clear2Pay Limited, Registered in Scotland
> > (No SC157659), Registered Office: Clear2Pay House, Pitreavie Court,
> > Pitreavie Business Park Queensferry Rd, Dunfermline, Fife, SS, KY11 8UU,
> > Scotland | FIS eProcess Intelligence LLC (UK Branch), UK Establishment
> > Registered in England & Wales (No: FC16527/Branch No. BR000355),
> Registered
> > Branch Office: 25 Canada Square, London, E14 5LQ; FIS eProcess
> Intelligence
> > LLC is a limited liability company formed in the USA registered on file
> > with the Office of the Delaware Secretary of State, Division of
> > Corporations (File No. 2032143), Head Office: 601