Re: API for listening to generic test events
Hello, Am Do., 16. Mai 2019 um 12:36 Uhr schrieb Tibor Digana < tibordig...@apache.org>: > Is it what Marc Philipp was asking me on the chat? > The purpose looked like a top secret ;-) but it was not because Mark needed > it for testing of some internal report. > Now it looks like Junit5 wants to remove the Surefire report out been dead > and move these features into Junit5. > My request is unrelated to JUnit 5 or how the test report is currently created. > > The RunListener could be always added. So it exists in JUnit4 and TestNG > provider for the purposes like custom report but not the standard report. > We agreed with JUnit5 developers in OpenTes4J to propose a specification > for a new standard report file. > This means the runners (e.g. JUnit or TestNG) should only run the tests and > Maven should run the build including creation of the project site reports. > The JUnit5 must not create report file because Maven controls all regarding > when/where and how to save and distribute the reports in the site. > Additionally, since the Maven is part of build system it may easily > integrate reports to CI systems, but JUnit5 must never do this; otherwise > it would be *chaos of responsibilities*. > Currently the IDEs handle events programatically from JUnit4 and then they > create GUI report, so the file report is useless for such GUI. > > The Surefire has several kinds of reports: > + Testset Info > + Console Report > + XML test report > > Having the test report in JUnit5 or OpenTes4J would be architecture > misunderstanding of responsibilities. > It is a perfect understanding of responsibilities when we introduce > extensions of these reports in Surefire and we do so as we proposed > together with Kristian Rosenvold and Andreas Gudian. > The same should happen with the new report standard (not only JUnit5) > initiated activities by JUni5 developers. > This way we will be fully consistent and users may expect clear > responsibility segregation between CI/Maven/JUnit5. > So I expect designing a specification of test report by OpenTes4J > contributors so that the tools, like Surefire etc, can internally implement > it according to their programming limitations and technologies they use. > > Benedikt, you can provide PR of course. It's quite simple to do - only > these two simple lines as follows (motivated by what exists in > JUnitCoreProvider). > > https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java#L101 > > https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java#L158 > > Yes, I know about this, but I'm talking about org.apache.maven.surefire.report.RunListener and not about test framework specific listeners. > So it's quite easy because it is these two lines to add in > JUnitPlatformProvider. Please improve the coverage with new unit tests and > integration tests. > Thx. > > > > > On Thu, May 16, 2019 at 11:01 AM Benedikt Ritter > wrote: > > > Hello, > > > > I'm currently working on a Maven extension that needs to be notified of > > what happened during test execution in Surefire. Currently it is only > > possible to register test framework specific listeners via the > > > setting [1]. However there is also the org.apache.maven.surefire.report. > > RunListener interface [2]. I would like to provide my own implementation > > for this interface, but it doesn't seem to be possible. I'm willing to > > provide a PR to add this functionality if there are chances to get it > > merged. > > > > WDYT? > > > > Benedikt > > > > [1] > > > > > https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#properties > > [2] > > > > > https://github.com/apache/maven-surefire/blob/master/surefire-api/src/main/java/org/apache/maven/surefire/report/RunListener.java > > >
API for listening to generic test events
Hello, I'm currently working on a Maven extension that needs to be notified of what happened during test execution in Surefire. Currently it is only possible to register test framework specific listeners via the setting [1]. However there is also the org.apache.maven.surefire.report. RunListener interface [2]. I would like to provide my own implementation for this interface, but it doesn't seem to be possible. I'm willing to provide a PR to add this functionality if there are chances to get it merged. WDYT? Benedikt [1] https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#properties [2] https://github.com/apache/maven-surefire/blob/master/surefire-api/src/main/java/org/apache/maven/surefire/report/RunListener.java
Re: [VOTE] Release Apache Maven Surefire Plugin version 2.22.2
Hello, Am Sa., 27. Apr. 2019 um 18:04 Uhr schrieb Enrico Olivelli < eolive...@gmail.com>: > Hi, > > We solved 1 issue: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12345433&styleName=Text&projectId=12317927&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED%7C568123541489d632001256d1b9872c5af17721f9%7Clout > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1500/ > > https://repository.apache.org/content/repositories/maven-1500/org/apache/maven/surefire/surefire/2.22.2/surefire-2.22.2-source-release.zip > > Source release checksum(s): > surefire-2.22.2-source-release.zip > sha512: > de47c5f8343bc531fd78704e7cee35d3aa7496c8c631ba6ac8d6b3ee75d2ccaebf2f985b295b7ae5f44dc440c3a1ffa33e2993e0270690cdff8cd2f3c6cac3e8 > > Staging site: > https://maven.apache.org/surefire-archives/surefire-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > The proposed artifacts passed all tests in our internal integration test suite. +1 (non-binding) Benedikt > > Enrico Olivelli > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Surefire maintenance release
Am Do., 25. Apr. 2019 um 22:08 Uhr schrieb Enrico Olivelli < eolive...@gmail.com>: > FYI > I have staged the release artifacts at > https://repository.apache.org/content/repositories/maven-1500/ > and created the tag > > but I have to do some burocratic steps in JIRA before sending the > official [VOTE] email > I have sent other emails on this mailing list in order to complete my task > > @Stephane Nicoll if you want to try out the artifacts you are welcome. > Anyway I will expect an official +1 on the VOTE thread > > I am sorry that the procedure takes so long but the staging proceure > (mvn release:prepare...release:perform) must run all of the Its and it > longs 2h > Helllo Enrico, the staged artifacts passed our internal test suite. Regards, Benedikt > > Enrico > > Il giorno gio 25 apr 2019 alle ore 10:25 Enrico Olivelli > ha scritto: > > > > Staging the artifact now. > > It will take the whole day I guess > > > > Enrico > > > > Il mer 24 apr 2019, 13:21 Enrico Olivelli ha > scritto: > >> > >> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana > >> ha scritto: > >> > > >> > What a test has failed? > >> > In this CI job all tests have passed successfully and the job is > "blue". > >> > >> You are right ! > >> My browser should have get messed somehow > >> > >> So we are good to go > >> sorry for beeing so late > >> > >> Enrico > >> > >> > > >> > On Wed, Apr 24, 2019 at 8:28 AM Enrico Olivelli > wrote: > >> > > >> > > I am sorry, > >> > > I had other priorities, this task is not still complete. > >> > > > >> > > Tests are still failing and this is weird because I think I saw > them green. > >> > > > >> > > This is the link to the job > >> > > > >> > > > >> > > > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/release%252F2.22.2/ > >> > > > >> > > Enrico > >> > > > >> > > Il gio 11 apr 2019, 08:11 Christian Stein ha > scritto: > >> > > > >> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli < > eolive...@gmail.com> > >> > > > wrote: > >> > > > > >> > > > > This is the final branch from which I will cut the release. > >> > > > > https://github.com/apache/maven-surefire/tree/release/2.22.2 > >> > > > > > >> > > > > Re-launched Jenkins to check for the last time: > >> > > > > > >> > > > > > >> > > > > >> > > > https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/ > >> > > > > > >> > > > > > >> > > > Go, Jenkins, go! ;-) > >> > > > > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [MJAVADOC] Where can I find the latest SNAPSHOT?
Am Do., 25. Apr. 2019 um 10:23 Uhr schrieb Olivier Lamy : > Hi > 3.1.1-SNAPSHOT just deployed. ( > > https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-javadoc-plugin/3.1.1-SNAPSHOT/maven-javadoc-plugin-3.1.1-20190425.073608-1.jar > ) > hth > Olivier > Cool, thank you! > > On Thu, 25 Apr 2019 at 17:04, Benedikt Ritter wrote: > > > Hi, > > > > I'd like to try my work project with the latest SNAPSHOT of the > > maven-javadoc-plugin. The repository has 3.1.1-SNAPSHOT as latest version > > [1] but the ASF snapshot repository only has 3.0.2-SNAPSHOT [2]. Any > chance > > of getting 3.1.1-SNAPSHOT into the snapshot repo? > > > > Thanks! > > Benedikt > > > > [1] > https://github.com/apache/maven-javadoc-plugin/blob/master/pom.xml#L33 > > [2] > > > > > https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-javadoc-plugin/ > > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy >
[MJAVADOC] Where can I find the latest SNAPSHOT?
Hi, I'd like to try my work project with the latest SNAPSHOT of the maven-javadoc-plugin. The repository has 3.1.1-SNAPSHOT as latest version [1] but the ASF snapshot repository only has 3.0.2-SNAPSHOT [2]. Any chance of getting 3.1.1-SNAPSHOT into the snapshot repo? Thanks! Benedikt [1] https://github.com/apache/maven-javadoc-plugin/blob/master/pom.xml#L33 [2] https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-javadoc-plugin/
Re: Summary of meeting about Maven performance improvements
Am Mi., 24. Apr. 2019 um 10:50 Uhr schrieb Benedikt Ritter < brit...@apache.org>: > Hello, > > this is a summary of a video conference call that happened yesterday > (April 24). > Sorry, actually yesterday was April 23... :o) > > Topic: > Discussion about performance improvements that have been proposed by > Stefan Oehme, namely: > > - [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource ( > https://github.com/apache/maven/pull/244) > - [MNG-6633] - Reduce memory usage of excludes ( > https://github.com/apache/maven/pull/243) - Speed up project discovery ( > https://github.com/apache/maven/pull/242) - Make location handling more > memory efficient (https://github.com/codehaus-plexus/modello/pull/31) > > The goal of this call was to give some more insights into how Stefan found > the improvements and to better understand what is missing before these > changes be merged. > > Attendees of the call: > - Benedikt Ritter (Gradle Inc.) > - Stefan Oehme (Gradle Inc.) > - Robert Scholte (Apache Maven Team) > - Hervé Boutemy (Apache Maven Team; joined about half an hour after the > call started) > > Summary: > > Stefan gave some insights into how he discovered bottlenecks in Maven: > >- > >One of our customers has a huge Maven build: >- > > Lots of sub projects (2000) > - > > Lots of entries in dependency management (4000) > - > > Results in a lot of garbage collection > - > >Problems discovered in that build: >- > > Re-parsing project POMs during dependency resolution > - > > Model objects are too large because of location tracking > - > > Low-level bottlenecks in project discovery (especially version > parsing) > - > >Customer now has a Maven fork with the proposed changes included: >- > > 1h 50min, 12GB RAM without changes > - > > 45min, 8GB RAM with changes > > > Robert: > >- > >How to ensure that improvements are not broken? >- > >No answer to how to test this > > > Stefan gave some insights into how performance testing works in the Gradle > project: > >- > >Build has a project generator >- > >Create different projects in different shapes (e.g. lots of >subprojects, deeply nested projects) during the build >- > >Download old Gradle version and run the build on generated projects >- > >Run build again with current Gradle version >- > >Compare results >- > >use statistic methods to filter out variance >- > >Downside to this approach is that it requires a lot of computing >resources > > More information can be found on GitHub: > https://github.com/gradle/gradle/tree/master/subprojects/performance > The corresponding TeamCity build can be found here: > https://builds.gradle.org/viewLog.html?buildId=22179604&buildTypeId=Gradle_Check_PerformanceExperimentCoordinator&tab=report_project941_Performance&branch_Gradle_Check_Stage_ReadyforRelease=master > (use > "Login as guest" to view) > > Robert: > >- > >What about measuring performance using instruction calls? > > > Stefan: > >- > >The performance improvements we found were mostly about garbage being >created >- > >Measuring using instruction calls is interesting >- > >... but it is also very machine dependent > > > Robert: > >- > >We need to find out who is interested in these kind improvements >inside the Maven community. >- > >Build a community of people who would like to work on these kind of >things. > > > Stefan: > >- > >It's easy to get started. We just used open source tools: >- > >We used async-profiler for measuring things ( >https://github.com/jvm-profiling-tools/async-profiler) >- > >Heap dumps for analyzing memory usage > > To get started with performance tests in the maven project: > >- > >Start with only a few test projects >- > >The Gradle generator is Apache License v2 and can be used as a >starting point to generate a big maven project > > > Hervé: > >- > >PRs should be merged soon >- > >Discussion need to be resolved >- > >Why was the PR not merged after the discussion and resolving all >issues with the code? >- > >Hervé will take care that the changes are merged soon > > > Thank you! > Benedikt >
Summary of meeting about Maven performance improvements
Hello, this is a summary of a video conference call that happened yesterday (April 24). Topic: Discussion about performance improvements that have been proposed by Stefan Oehme, namely: - [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource ( https://github.com/apache/maven/pull/244) - [MNG-6633] - Reduce memory usage of excludes ( https://github.com/apache/maven/pull/243) - Speed up project discovery ( https://github.com/apache/maven/pull/242) - Make location handling more memory efficient (https://github.com/codehaus-plexus/modello/pull/31) The goal of this call was to give some more insights into how Stefan found the improvements and to better understand what is missing before these changes be merged. Attendees of the call: - Benedikt Ritter (Gradle Inc.) - Stefan Oehme (Gradle Inc.) - Robert Scholte (Apache Maven Team) - Hervé Boutemy (Apache Maven Team; joined about half an hour after the call started) Summary: Stefan gave some insights into how he discovered bottlenecks in Maven: - One of our customers has a huge Maven build: - Lots of sub projects (2000) - Lots of entries in dependency management (4000) - Results in a lot of garbage collection - Problems discovered in that build: - Re-parsing project POMs during dependency resolution - Model objects are too large because of location tracking - Low-level bottlenecks in project discovery (especially version parsing) - Customer now has a Maven fork with the proposed changes included: - 1h 50min, 12GB RAM without changes - 45min, 8GB RAM with changes Robert: - How to ensure that improvements are not broken? - No answer to how to test this Stefan gave some insights into how performance testing works in the Gradle project: - Build has a project generator - Create different projects in different shapes (e.g. lots of subprojects, deeply nested projects) during the build - Download old Gradle version and run the build on generated projects - Run build again with current Gradle version - Compare results - use statistic methods to filter out variance - Downside to this approach is that it requires a lot of computing resources More information can be found on GitHub: https://github.com/gradle/gradle/tree/master/subprojects/performance The corresponding TeamCity build can be found here: https://builds.gradle.org/viewLog.html?buildId=22179604&buildTypeId=Gradle_Check_PerformanceExperimentCoordinator&tab=report_project941_Performance&branch_Gradle_Check_Stage_ReadyforRelease=master (use "Login as guest" to view) Robert: - What about measuring performance using instruction calls? Stefan: - The performance improvements we found were mostly about garbage being created - Measuring using instruction calls is interesting - ... but it is also very machine dependent Robert: - We need to find out who is interested in these kind improvements inside the Maven community. - Build a community of people who would like to work on these kind of things. Stefan: - It's easy to get started. We just used open source tools: - We used async-profiler for measuring things ( https://github.com/jvm-profiling-tools/async-profiler) - Heap dumps for analyzing memory usage To get started with performance tests in the maven project: - Start with only a few test projects - The Gradle generator is Apache License v2 and can be used as a starting point to generate a big maven project Hervé: - PRs should be merged soon - Discussion need to be resolved - Why was the PR not merged after the discussion and resolving all issues with the code? - Hervé will take care that the changes are merged soon Thank you! Benedikt
Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot
Am Do., 14. Feb. 2019 um 14:22 Uhr schrieb Tibor Digana < tibordig...@apache.org>: > Benedikt, it does not mean that something with public IP is for public use. > We made only a compromise for some users to verify some functionality. > Please read the information about Apache repositories: https://www.apache.org/dev/repository-faq.html > > On Thu, Feb 14, 2019 at 11:42 AM Benedikt Ritter > wrote: > > > Am Mi., 13. Feb. 2019 um 17:48 Uhr schrieb Tibor Digana < > > tibordig...@apache.org>: > > > > > Is it so a big problem to keep both versions? This is our internal > Nexus > > > server anyway. > > > > > > > From my PoV the metadata is incorrect. Latest should point to the latest > > available build. At the moment it does not. The Snapshot repository is > not > > an internal Nexus server. It is a public artifact repository for trying > out > > new things. I think the Maven project should get its own metadata > right... > > Why are you resisting? Do you see problems when updating master to > > 3.0.0-SNAPSHOT? > > > > Benedikt > > > > > > > > > > On Wed, Feb 13, 2019 at 1:27 PM Benedikt Ritter > > > wrote: > > > > > > > Hello, > > > > > > > > Am Di., 12. Feb. 2019 um 08:39 Uhr schrieb Benedikt Ritter < > > > > brit...@apache.org>: > > > > > > > > > Hello, > > > > > > > > > > Am Mo., 11. Feb. 2019 um 18:39 Uhr schrieb Enrico Olivelli < > > > > > eolive...@gmail.com>: > > > > > > > > > >> In maven coordinates 3.0.0 is different from 3.0.0-M4 (you already > > > > knew), > > > > >> so they can coexist. > > > > >> > > > > > > > > > > Yes, but the question is, what is latest available snapshot? The > > > > > 3.0.0-SNAPSHOT has been deployed sometime last June. > > > > > > > > > > > > > > >> > > > > >> How are you referring to surefire in your project? > > > > >> > > > > > > > > > > We have some end to end tests that determine the latest snapshots > of > > > some > > > > > plugins so we can run tests against them. We do this by analyzing > the > > > > > maven-metadata.xml so we don't have to hard code all the versions. > > > > > > > > > > > > > > >> > > > > >> Btw I will check and try to deploy current master > > > > >> > > > > > > > > > > I checked, it didn't help. Maybe the master branch should have > > > > > 3.0.0-SNAPSHOT as version and only be updated to a milestone > version > > > for > > > > a > > > > > milestone release. > > > > > > > > > > > > > the problem is still present. I suspect maven can not deal with > > milestone > > > > snapshot version. My suggestion is to change the version on the > master > > > > branch to 3.0.0-SNAPSHOT and create milestone releases without having > > an > > > > explicit milestone snapshot first. This would fix the metadata in > that > > > the > > > > latest version would again be the latest deployment from the master > > > branch. > > > > > > > > Regards, > > > > Benedikt > > > > > > > > > > > > > > > > > > Thank you! > > > > > Benedikt > > > > > > > > > > > > > > >> > > > > >> Enrico > > > > >> > > > > >> Il giorno lun 11 feb 2019, 14:59 Benedikt Ritter < > > brit...@apache.org> > > > > ha > > > > >> scritto: > > > > >> > > > > >> > Hi, > > > > >> > > > > > >> > I just realized that the maven-metadata.xml for Surefire in the > > > > snapshot > > > > >> > repository [1] does not point to the latest Surefire snapshot. > It > > > says > > > > >> that > > > > >> > 3.0.0-SNAPSHOT is the latest version but 3.0.0-M4-SNAPSHOT is > > > actually > > > > >> the > > > > >> > latest available snapshot. Is it possible to correct this? > > > > >> > > > > > >> > Thanks, > > > > >> > Benedikt > > > > >> > > > > > >> > [1] > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml > > > > >> > > > > > >> > > > > > > > > > > > > > > >
Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot
Am Mi., 13. Feb. 2019 um 17:48 Uhr schrieb Tibor Digana < tibordig...@apache.org>: > Is it so a big problem to keep both versions? This is our internal Nexus > server anyway. > >From my PoV the metadata is incorrect. Latest should point to the latest available build. At the moment it does not. The Snapshot repository is not an internal Nexus server. It is a public artifact repository for trying out new things. I think the Maven project should get its own metadata right... Why are you resisting? Do you see problems when updating master to 3.0.0-SNAPSHOT? Benedikt > > On Wed, Feb 13, 2019 at 1:27 PM Benedikt Ritter > wrote: > > > Hello, > > > > Am Di., 12. Feb. 2019 um 08:39 Uhr schrieb Benedikt Ritter < > > brit...@apache.org>: > > > > > Hello, > > > > > > Am Mo., 11. Feb. 2019 um 18:39 Uhr schrieb Enrico Olivelli < > > > eolive...@gmail.com>: > > > > > >> In maven coordinates 3.0.0 is different from 3.0.0-M4 (you already > > knew), > > >> so they can coexist. > > >> > > > > > > Yes, but the question is, what is latest available snapshot? The > > > 3.0.0-SNAPSHOT has been deployed sometime last June. > > > > > > > > >> > > >> How are you referring to surefire in your project? > > >> > > > > > > We have some end to end tests that determine the latest snapshots of > some > > > plugins so we can run tests against them. We do this by analyzing the > > > maven-metadata.xml so we don't have to hard code all the versions. > > > > > > > > >> > > >> Btw I will check and try to deploy current master > > >> > > > > > > I checked, it didn't help. Maybe the master branch should have > > > 3.0.0-SNAPSHOT as version and only be updated to a milestone version > for > > a > > > milestone release. > > > > > > > the problem is still present. I suspect maven can not deal with milestone > > snapshot version. My suggestion is to change the version on the master > > branch to 3.0.0-SNAPSHOT and create milestone releases without having an > > explicit milestone snapshot first. This would fix the metadata in that > the > > latest version would again be the latest deployment from the master > branch. > > > > Regards, > > Benedikt > > > > > > > > > > Thank you! > > > Benedikt > > > > > > > > >> > > >> Enrico > > >> > > >> Il giorno lun 11 feb 2019, 14:59 Benedikt Ritter > > ha > > >> scritto: > > >> > > >> > Hi, > > >> > > > >> > I just realized that the maven-metadata.xml for Surefire in the > > snapshot > > >> > repository [1] does not point to the latest Surefire snapshot. It > says > > >> that > > >> > 3.0.0-SNAPSHOT is the latest version but 3.0.0-M4-SNAPSHOT is > actually > > >> the > > >> > latest available snapshot. Is it possible to correct this? > > >> > > > >> > Thanks, > > >> > Benedikt > > >> > > > >> > [1] > > >> > > > >> > > > >> > > > https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml > > >> > > > >> > > > > > >
Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot
Hello, Am Di., 12. Feb. 2019 um 08:39 Uhr schrieb Benedikt Ritter < brit...@apache.org>: > Hello, > > Am Mo., 11. Feb. 2019 um 18:39 Uhr schrieb Enrico Olivelli < > eolive...@gmail.com>: > >> In maven coordinates 3.0.0 is different from 3.0.0-M4 (you already knew), >> so they can coexist. >> > > Yes, but the question is, what is latest available snapshot? The > 3.0.0-SNAPSHOT has been deployed sometime last June. > > >> >> How are you referring to surefire in your project? >> > > We have some end to end tests that determine the latest snapshots of some > plugins so we can run tests against them. We do this by analyzing the > maven-metadata.xml so we don't have to hard code all the versions. > > >> >> Btw I will check and try to deploy current master >> > > I checked, it didn't help. Maybe the master branch should have > 3.0.0-SNAPSHOT as version and only be updated to a milestone version for a > milestone release. > the problem is still present. I suspect maven can not deal with milestone snapshot version. My suggestion is to change the version on the master branch to 3.0.0-SNAPSHOT and create milestone releases without having an explicit milestone snapshot first. This would fix the metadata in that the latest version would again be the latest deployment from the master branch. Regards, Benedikt > > Thank you! > Benedikt > > >> >> Enrico >> >> Il giorno lun 11 feb 2019, 14:59 Benedikt Ritter ha >> scritto: >> >> > Hi, >> > >> > I just realized that the maven-metadata.xml for Surefire in the snapshot >> > repository [1] does not point to the latest Surefire snapshot. It says >> that >> > 3.0.0-SNAPSHOT is the latest version but 3.0.0-M4-SNAPSHOT is actually >> the >> > latest available snapshot. Is it possible to correct this? >> > >> > Thanks, >> > Benedikt >> > >> > [1] >> > >> > >> https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml >> > >> >
Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot
Hello, Am Mo., 11. Feb. 2019 um 18:39 Uhr schrieb Enrico Olivelli < eolive...@gmail.com>: > In maven coordinates 3.0.0 is different from 3.0.0-M4 (you already knew), > so they can coexist. > Yes, but the question is, what is latest available snapshot? The 3.0.0-SNAPSHOT has been deployed sometime last June. > > How are you referring to surefire in your project? > We have some end to end tests that determine the latest snapshots of some plugins so we can run tests against them. We do this by analyzing the maven-metadata.xml so we don't have to hard code all the versions. > > Btw I will check and try to deploy current master > I checked, it didn't help. Maybe the master branch should have 3.0.0-SNAPSHOT as version and only be updated to a milestone version for a milestone release. Thank you! Benedikt > > Enrico > > Il giorno lun 11 feb 2019, 14:59 Benedikt Ritter ha > scritto: > > > Hi, > > > > I just realized that the maven-metadata.xml for Surefire in the snapshot > > repository [1] does not point to the latest Surefire snapshot. It says > that > > 3.0.0-SNAPSHOT is the latest version but 3.0.0-M4-SNAPSHOT is actually > the > > latest available snapshot. Is it possible to correct this? > > > > Thanks, > > Benedikt > > > > [1] > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml > > >
[SUREFIRE] maven-metadata.xml does not point to latest snapshot
Hi, I just realized that the maven-metadata.xml for Surefire in the snapshot repository [1] does not point to the latest Surefire snapshot. It says that 3.0.0-SNAPSHOT is the latest version but 3.0.0-M4-SNAPSHOT is actually the latest available snapshot. Is it possible to correct this? Thanks, Benedikt [1] https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml
Re: Maven Surefire and JUnit 5
Hello Tibor, did you have some time to do the rebase and help me get the build to work in the junit5 branch? Regards, Benedikt > Am 18.10.2017 um 09:13 schrieb Benedikt Ritter : > > Hello Tibor, > > Sorry for the daily I somehow missed this mail. > >> Am 15.10.2017 um 13:07 schrieb Tibor Digana : >> >> Hi Benedikt, >> >> I am fine now after my illness, thx. >> I am finishing branch SUREFIRE-1262_2. Just to add few more tests and then >> I will cut a release. I want to add a fix for SUREFIRE-1374 which would be >> fast to do. >> Then I am ready for you and JUnit5. >> >> I have questions regarding our JUnit 5 Surefire Provider implemented in >> Surefire. >> >> Is it implemented exactly in the same like the origin by junit5 team? >> I am asking because I saw the implementation made by junit5 team and it is >> not like our *JUnitCoreProvider*. This means that they do not map method >> <-> Thread in *RunListener *and thus the provider would not associate test >> report logs and Thread properly and logs will be mixed. > > We imported the code from the JUnit project some while ago. They have in the > mean time updated their provider code. They are planning to bring those > changes back to surefire, once we get of the ground with the implementation > in surefire. So if you’re seeing difference in the implementation in surefire > and in the implementation in JUnit, that must have been introduced after we > imported the code. > >> >> Next question is regarding the feature re-run. It also exists in >> *JUnitCoreProvider >> *and *JUnit4Provider*. Does it exist in our provider too. > > I don’t know, need to check the code. > >> Also we need to have a feature where JUnit execution is stopped which can >> be configured by *skipAfterFailureCount *in POM. We have implementation in >> Surefire provider: >> >> notifier.asFailFast( isFailFast() ); > > We have to figure out, how this is supported by JUnit 5. > >> >> Regarding logger in forked provider, which has to do with parallel exec, I >> think the logs go to the dump file instead of reports file, because STDOUT >> is not wrapped in JUnit5's implementation and this should be called: >> >> startCapture( listener ) >> >> >> See my questions in https://github.com/xwiki/xwiki-platform/commit/ >> 5258a22301977a7d1ee7276cdd81af7641f4f5ac >> >> Do we have integration tests for these features? > > We only have very limited integration tests yet. I’m planning to write more > integration tests and work on the structure of the integration test project, > once the build does work again. Currently I’m unable to exec an integration > test on the junit5 branch. Once this is possible again, we can write the > missing tests. > > Thank you! > Benedikt > >> >> >> Cheers >> Tibor >> >> >> >> On Sat, Sep 30, 2017 at 10:34 AM, Benedikt Ritter >> wrote: >> >>> Hello, >>> >>> for over a year now I’m trying to help getting JUnit 5 support into Maven >>> Surefire. This has been hard since Tibor seems to be the only one >>> maintaining Maven Surefire and he had to come with other things. >>> >>> For this reason I’d like to ask other Maven maintainers to help with the >>> JUnit 5 support. I’m happy to do the work, but I’m constantly blocked by >>> obscure build failures which I’m unable to resolve myself or by lack of >>> code review und merge of changes. >>> >>> - Work on JUnit5 support is currently done in the junit5 branch. >>> - I have drafted a Provider Lookup implementation in the junit5 branch, >>> but I don’t know whether it works because I can’t get the integration tests >>> running >>> - There is an open PR to merge the master branch back into junit5 branch, >>> but it has build failures I don’t understand [1] >>> >>> Please help! >>> Cheers, >>> Benedikt >>> >>> [1] https://github.com/apache/maven-surefire/pull/165 >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Surefire and JUnit 5
Hello Tibor, Sorry for the daily I somehow missed this mail. > Am 15.10.2017 um 13:07 schrieb Tibor Digana : > > Hi Benedikt, > > I am fine now after my illness, thx. > I am finishing branch SUREFIRE-1262_2. Just to add few more tests and then > I will cut a release. I want to add a fix for SUREFIRE-1374 which would be > fast to do. > Then I am ready for you and JUnit5. > > I have questions regarding our JUnit 5 Surefire Provider implemented in > Surefire. > > Is it implemented exactly in the same like the origin by junit5 team? > I am asking because I saw the implementation made by junit5 team and it is > not like our *JUnitCoreProvider*. This means that they do not map method > <-> Thread in *RunListener *and thus the provider would not associate test > report logs and Thread properly and logs will be mixed. We imported the code from the JUnit project some while ago. They have in the mean time updated their provider code. They are planning to bring those changes back to surefire, once we get of the ground with the implementation in surefire. So if you’re seeing difference in the implementation in surefire and in the implementation in JUnit, that must have been introduced after we imported the code. > > Next question is regarding the feature re-run. It also exists in > *JUnitCoreProvider > *and *JUnit4Provider*. Does it exist in our provider too. I don’t know, need to check the code. > Also we need to have a feature where JUnit execution is stopped which can > be configured by *skipAfterFailureCount *in POM. We have implementation in > Surefire provider: > > notifier.asFailFast( isFailFast() ); We have to figure out, how this is supported by JUnit 5. > > Regarding logger in forked provider, which has to do with parallel exec, I > think the logs go to the dump file instead of reports file, because STDOUT > is not wrapped in JUnit5's implementation and this should be called: > > startCapture( listener ) > > > See my questions in https://github.com/xwiki/xwiki-platform/commit/ > 5258a22301977a7d1ee7276cdd81af7641f4f5ac > > Do we have integration tests for these features? We only have very limited integration tests yet. I’m planning to write more integration tests and work on the structure of the integration test project, once the build does work again. Currently I’m unable to exec an integration test on the junit5 branch. Once this is possible again, we can write the missing tests. Thank you! Benedikt > > > Cheers > Tibor > > > > On Sat, Sep 30, 2017 at 10:34 AM, Benedikt Ritter > wrote: > >> Hello, >> >> for over a year now I’m trying to help getting JUnit 5 support into Maven >> Surefire. This has been hard since Tibor seems to be the only one >> maintaining Maven Surefire and he had to come with other things. >> >> For this reason I’d like to ask other Maven maintainers to help with the >> JUnit 5 support. I’m happy to do the work, but I’m constantly blocked by >> obscure build failures which I’m unable to resolve myself or by lack of >> code review und merge of changes. >> >> - Work on JUnit5 support is currently done in the junit5 branch. >> - I have drafted a Provider Lookup implementation in the junit5 branch, >> but I don’t know whether it works because I can’t get the integration tests >> running >> - There is an open PR to merge the master branch back into junit5 branch, >> but it has build failures I don’t understand [1] >> >> Please help! >> Cheers, >> Benedikt >> >> [1] https://github.com/apache/maven-surefire/pull/165 >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: dependency:go-offline broken?
Hello, > Am 13.10.2017 um 21:32 schrieb Tibor Digana : > > This exception is expected. > Use pluginGroup in settings.xml or try this: > org.codehaus.mojo:tidy:1.0.0:check > or > org.codehaus.mojo:tidy-maven-plugin:1.0.0:check > > I don't know what dummy.jar has to do with tidy plugin, it's internal code > in surefire due to M2 API and tidy should not be influenced by. There are to distinct issues: 1) surefire does some trickery which can not be resolved by the dependency plugin. 2) the tidy plugin does not work in offline mode, even if dependencies have been downloaded before. Why do I have to define the plugin explicitly to work in offline mode? It does work in online mode. Regards, Benedikt > > Cheers > Tibor > > On Fri, Oct 13, 2017 at 6:36 PM, Benedikt Ritter wrote: > >> Hello, >> >>> Am 08.10.2017 um 15:54 schrieb Hervé BOUTEMY : >>> >>> Le dimanche 8 octobre 2017, 15:37:54 CEST Benedikt Ritter a écrit : >>>> Hello Hervé >>>> >>>>> Then I added a pluginManagement section to select version 3.0.2 and >> re-ran >>>>> the test: you'll see the output is completely different. >>>>> >>>>> And there is no issue any more >>>> >>>> Thank you so much, you took the time to investigate this issue! Really >> much >>>> appreciated. Now I wonder, why Maven uses an outdated version of the >>>> dependency plugin. Is this a problem with the super pom? >>> this is a choice to keep stability: >>> if one downloads dependencies using Maven 3.0.5 then a few days later >> builds >>> offline with Maven 3.5, he does not have any issue (and blame >> dependency-plugin) >>> >>> remember the good practice: define your plugin versions, either in your >> pom or >>> by using a parent that does the job >>> >>>> >>>> Furthermore I’ve noticed, that mvn -o test still does not work, because >> some >>>> surefire dependencies are missing: >>>> >>>> [ERROR] Failed to execute goal >>>> org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test >> (default-test) >>>> on project dependency-plugin-bug: Unable to generate classpath: >>>> org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: >>>> Missing: [ERROR] -- >>>> [ERROR] 1) org.apache.maven.surefire:surefire-junit3:jar:2.12.4 >>>> [ERROR] >>>> [ERROR] Try downloading the file manually from the project website. >>>> [ERROR] >>>> [ERROR] Then, install it using the command: >>>> [ERROR] mvn install:install-file -DgroupId=org.apache.maven.surefire >>>> -DartifactId=surefire-junit3 -Dversion=2.12.4 -Dpackaging=jar >>>> -Dfile=/path/to/file [ERROR] >>>> [ERROR] Alternatively, if you host your own repository you can deploy >> the >>>> file there: [ERROR] mvn deploy:deploy-file >>>> -DgroupId=org.apache.maven.surefire -DartifactId=surefire-junit3 >>>> -Dversion=2.12.4 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] >>>> -DrepositoryId=[id] [ERROR] >>>> [ERROR] Path to dependency: >>>> [ERROR] 1) dummy:dummy:jar:1.0 >>>> [ERROR] 2) org.apache.maven.surefire:surefire-junit3:jar:2.12.4 >>>> [ERROR] >>>> [ERROR] -- >>>> [ERROR] 1 required artifact is missing. >>>> [ERROR] >>>> [ERROR] for artifact: >>>> [ERROR] dummy:dummy:jar:1.0 >>>> [ERROR] >>>> [ERROR] from the specified remote repositories: >>>> [ERROR] central (https://repo.maven.apache.org/maven2, releases=true, >>>> snapshots=false) [ERROR] -> [Help 1] >>>> [ERROR] >>>> [ERROR] To see the full stack trace of the errors, re-run Maven with >> the -e >>>> switch. [ERROR] Re-run Maven using the -X switch to enable full debug >>>> logging. [ERROR] >>>> [ERROR] For more information about the errors and possible solutions, >> please >>>> read the following articles: [ERROR] [Help 1] >>>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException >>>> >>>> Since there are only a few dependencies missing, I will run test not in >>>> offline modus on my CI server. But I wonder whether this is a bug. >>> I'll have a look at this one and report >> >> I made another interesting observation: >> >> mvn tidy:check works, while mvn -o tidy:check does not work. It f
Re: dependency:go-offline broken?
Hello, > Am 08.10.2017 um 15:54 schrieb Hervé BOUTEMY : > > Le dimanche 8 octobre 2017, 15:37:54 CEST Benedikt Ritter a écrit : >> Hello Hervé >> >>> Then I added a pluginManagement section to select version 3.0.2 and re-ran >>> the test: you'll see the output is completely different. >>> >>> And there is no issue any more >> >> Thank you so much, you took the time to investigate this issue! Really much >> appreciated. Now I wonder, why Maven uses an outdated version of the >> dependency plugin. Is this a problem with the super pom? > this is a choice to keep stability: > if one downloads dependencies using Maven 3.0.5 then a few days later builds > offline with Maven 3.5, he does not have any issue (and blame > dependency-plugin) > > remember the good practice: define your plugin versions, either in your pom > or > by using a parent that does the job > >> >> Furthermore I’ve noticed, that mvn -o test still does not work, because some >> surefire dependencies are missing: >> >> [ERROR] Failed to execute goal >> org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) >> on project dependency-plugin-bug: Unable to generate classpath: >> org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: >> Missing: [ERROR] -- >> [ERROR] 1) org.apache.maven.surefire:surefire-junit3:jar:2.12.4 >> [ERROR] >> [ERROR] Try downloading the file manually from the project website. >> [ERROR] >> [ERROR] Then, install it using the command: >> [ERROR] mvn install:install-file -DgroupId=org.apache.maven.surefire >> -DartifactId=surefire-junit3 -Dversion=2.12.4 -Dpackaging=jar >> -Dfile=/path/to/file [ERROR] >> [ERROR] Alternatively, if you host your own repository you can deploy the >> file there: [ERROR] mvn deploy:deploy-file >> -DgroupId=org.apache.maven.surefire -DartifactId=surefire-junit3 >> -Dversion=2.12.4 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] >> -DrepositoryId=[id] [ERROR] >> [ERROR] Path to dependency: >> [ERROR] 1) dummy:dummy:jar:1.0 >> [ERROR] 2) org.apache.maven.surefire:surefire-junit3:jar:2.12.4 >> [ERROR] >> [ERROR] -- >> [ERROR] 1 required artifact is missing. >> [ERROR] >> [ERROR] for artifact: >> [ERROR] dummy:dummy:jar:1.0 >> [ERROR] >> [ERROR] from the specified remote repositories: >> [ERROR] central (https://repo.maven.apache.org/maven2, releases=true, >> snapshots=false) [ERROR] -> [Help 1] >> [ERROR] >> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e >> switch. [ERROR] Re-run Maven using the -X switch to enable full debug >> logging. [ERROR] >> [ERROR] For more information about the errors and possible solutions, please >> read the following articles: [ERROR] [Help 1] >> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException >> >> Since there are only a few dependencies missing, I will run test not in >> offline modus on my CI server. But I wonder whether this is a bug. > I'll have a look at this one and report I made another interesting observation: mvn tidy:check works, while mvn -o tidy:check does not work. It fails with: [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 0.640 s [INFO] Finished at: 2017-10-13T18:34:32+02:00 [INFO] Final Memory: 13M/309M [INFO] [ERROR] No plugin found for prefix 'tidy' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/Users/bene/workspace/github/dependency-plugin-bug/.m2), central (https://repo.maven.apache.org/maven2)] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoPluginFoundForPrefixException Cheers, Benedikt > > Regards, > > Hervé > >> >> Regards, >> Benedikt >> >>> Regards, >>> >>> Hervé >>> >>> Le mercredi 20 septembre 2017, 22:48:15 CEST Benedikt Ritter a écrit : >>>> Hi, >>>> >>>> as far as I understand it should be possible
Re: Maven Surefire and JUnit 5
Hello Tibor > Am 06.10.2017 um 01:18 schrieb Tibor Digana : > > Hi Benedikt, > > Would you agree with this plan. > Since we try to release version 2.21.0 with Jigsaw modularity which is Java 9 > related feature, we can make the same compromise with JUnit5 in next version > 2.22.0. Altough Surifire is compiled with javac -source 1.6 -target 1.6, and > JUnit 5/Java 1.8 provider is standalone jar file which does not force the > plugin itself to load Java 8 classes from the provider, we can freely work on > JUnit 5 provider after the version 2.21.0.Jigsaw has been released. I guess I > will start the release Vote next week and then we can pickup your commits > from the branch junit5, squash them into one single commit and rebase on the > top of future master/HEAD. > I believe you want to merge some more fixes from JUnit team afterwards and > maybe to add some more tests. > > What do you think, would it be possible for you? This would be so great! I’m currently really blocked by the fact, that I can’t run the surefire build without errors. If you could help fix this, maybe by rebasing everything, this would be very much appreciated. Looking forward to hearing from you! Regards, Benedikt > > Cheers > Tibor > > On Sun, Oct 1, 2017 at 5:12 PM, Enrico Olivelli wrote: > Sorry > I wanted to reply to another message from Benedikt > Enrico > > Il dom 1 ott 2017, 16:17 Karl Heinz Marbaise ha scritto: > > > Hi Enrico, > > > > On 01/10/17 16:00, Enrico Olivelli wrote: > > > Benedikt, > > > did you try to update all of your maven plugins to latest version? > > > Can you share some stacktrace? This will give a first hint without having > > > to build jUDDI > > > > This is the wrong mailing list...Users list was the subject about jUDDI > > ;-).. > > > > Not related to Surefire and JUnit 5 ... > > > > Kind regards > > Karl Heinz Marbaise > > > Cheers > > > > > > Enrico > > > > > > Il sab 30 set 2017, 10:34 Benedikt Ritter ha > > scritto: > > > > > >> Hello, > > >> > > >> for over a year now I’m trying to help getting JUnit 5 support into > > Maven > > >> Surefire. This has been hard since Tibor seems to be the only one > > >> maintaining Maven Surefire and he had to come with other things. > > >> > > >> For this reason I’d like to ask other Maven maintainers to help with the > > >> JUnit 5 support. I’m happy to do the work, but I’m constantly blocked by > > >> obscure build failures which I’m unable to resolve myself or by lack of > > >> code review und merge of changes. > > >> > > >> - Work on JUnit5 support is currently done in the junit5 branch. > > >> - I have drafted a Provider Lookup implementation in the junit5 branch, > > >> but I don’t know whether it works because I can’t get the integration > > tests > > >> running > > >> - There is an open PR to merge the master branch back into junit5 > > branch, > > >> but it has build failures I don’t understand [1] > > >> > > >> Please help! > > >> Cheers, > > >> Benedikt > > > -- > > > -- Enrico Olivelli > > > > -- > Cheers > Tibor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: dependency:go-offline broken?
solver.MultipleArtifactsNotFoundException: Missing: [ERROR] -- [ERROR] 1) org.apache.maven.surefire:surefire-junit3:jar:2.12.4 [ERROR] [ERROR] Try downloading the file manually from the project website. [ERROR] [ERROR] Then, install it using the command: [ERROR] mvn install:install-file -DgroupId=org.apache.maven.surefire -DartifactId=surefire-junit3 -Dversion=2.12.4 -Dpackaging=jar -Dfile=/path/to/file [ERROR] [ERROR] Alternatively, if you host your own repository you can deploy the file there: [ERROR] mvn deploy:deploy-file -DgroupId=org.apache.maven.surefire -DartifactId=surefire-junit3 -Dversion=2.12.4 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] [ERROR] [ERROR] Path to dependency: [ERROR] 1) dummy:dummy:jar:1.0 [ERROR] 2) org.apache.maven.surefire:surefire-junit3:jar:2.12.4 [ERROR] [ERROR] -- [ERROR] 1 required artifact is missing. [ERROR] [ERROR] for artifact: [ERROR] dummy:dummy:jar:1.0 [ERROR] [ERROR] from the specified remote repositories: [ERROR] central (https://repo.maven.apache.org/maven2, releases=true, snapshots=false) [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException Since there are only a few dependencies missing, I will run test not in offline modus on my CI server. But I wonder whether this is a bug. Regards, Benedikt > > Regards, > > Hervé > > Le mercredi 20 septembre 2017, 22:48:15 CEST Benedikt Ritter a écrit : >> Hi, >> >> as far as I understand it should be possible to call mvn >> dependency:go-offline and from there on work in offline mode (mvn -o). >> I’ve put a minimal example together [1] that demonstrates that this >> currently does not work. Am I missing anything? >> >> Thank you! >> Benedikt >> >> [1] https://github.com/britter/dependency-plugin-bug >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: dependency:go-offline broken?
Hello Laird > Am 02.10.2017 um 18:42 schrieb Laird Nelson : > > On Wed, Sep 27, 2017 at 4:53 AM Benedikt Ritter wrote: > >> I have a CI Build in GitLab, where I want to define a job that downloads >> all the artifacts which are needed for the different lifecycle phases and >> plugin executions as well as all project dependencies. I only want to >> download all the stuff once and then copy the artifacts between the build >> stages. > > > Have you looked at the cache directive ( > https://docs.gitlab.com/ee/ci/yaml/#cache) and a custom settings.xml with a > element instead of using artifacts? There is no need for a custom settings.xml, since you can set the local repository using MAVEN_OPTS. This can be done with a top level variables declaration in .gitlab-ci.yaml. The cache directive won’t help you here, since it will cache dependencies between pipeline runs. I don’t think this is a good idea. I like my CI builds to run from a clean environment. However for one pipeline run, I want to download all dependencies upfront. But this does not seem to be possible. Cheers, Benedikt > > Best, > Laird - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: dependency:go-offline broken?
Hello Alex, > Am 01.10.2017 um 18:55 schrieb Alex O'Ree : > > This is what I use to get artifacts before dropping offline (it may or > may not help your scenario) > > mvn dependency:resolve -Dclassifier=javadoc dependency:sources > dependency:resolve-plugins -fn > > This gets sources, javadocs and plugins. This works in most cases, > however if you're using ant to download stuff or any other cases > where's there's declared dependencies that are only resolved by > running a specific phase or plugin, then you'll have to figure those > out, then put them in dependency management and the above should work I gave this a try: export MAVEN_OPTS=-Dmaven.repo.local=/path/to/my/project.m2 mvn dependency:resolve dependency:resolve-plugins mvn -o findbugs:check [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ tourenplanung-backend --- [WARNING] The POM for org.apache.maven:maven-project:jar:2.0.6 is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-core:jar:2.0.6 is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-artifact:jar:2.0.6 is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-settings:jar:2.0.6 is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-model:jar:2.0.6 is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-monitor:jar:2.0.6 is missing, no dependency information available [WARNING] The POM for org.apache.maven.shared:maven-filtering:jar:1.1 is missing, no dependency information available [WARNING] The POM for org.codehaus.plexus:plexus-interpolation:jar:1.13 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1.482 s [INFO] Finished at: 2017-10-02T18:30:37+02:00 [INFO] Final Memory: 22M/309M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:2.6:resources (default-resources) on project my-project: Execution default-resources of goal org.apache.maven.plugins:maven-resources-plugin:2.6:resources failed: Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact classworlds:classworlds:jar:1.1-alpha-2 has not been downloaded from it before. -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException So this still doesn’t work… Cheers, Benedikt > > > On Wed, Sep 27, 2017 at 5:59 PM, Brian Fox wrote: >> No, I don't think it will work. What you really need is a repository >> manager to cache things locally for you. That's the recommended solution >> any time you feel like you're going to be downloading components more than >> once...which is really in every instance. >> >> On Wed, Sep 27, 2017 at 7:53 AM, Benedikt Ritter wrote: >> >>> Hello Brain, >>> >>>> Am 26.09.2017 um 23:10 schrieb Brian Fox : >>>> >>>> On Mon, Sep 25, 2017 at 2:10 PM, Benedikt Ritter >>> wrote: >>>> >>>>> Hello Brian, >>>>> >>>>>> Am 20.09.2017 um 23:16 schrieb Brian Fox : >>>>>> >>>>>> It's been a really long time, but I recall that there were issues >>> getting >>>>>> the dependencies of plugins bound to the lifecycle. This looks to be >>> the >>>>>> same problem. I think the documentation talked about a way to do this >>>>>> effectively. >>>>> >>>>> I’ve looked through the documentation of the dependency plugin, but I >>> can >>>>> not find anything about this. Do you recall where you found that >>>>> documentation? >>>>> >>>>> >>>> Ha no, since I wrote that goal 10 years ago I'm scratching the depth of >>> my >>>> memory. Maybe I just intended to describe it ;-) >>> >>> Thank you for your response. Maybe I’ll just give a little more context >>> about what I’m trying to achieve. Maybe I’
Maven Surefire and JUnit 5
Hello, for over a year now I’m trying to help getting JUnit 5 support into Maven Surefire. This has been hard since Tibor seems to be the only one maintaining Maven Surefire and he had to come with other things. For this reason I’d like to ask other Maven maintainers to help with the JUnit 5 support. I’m happy to do the work, but I’m constantly blocked by obscure build failures which I’m unable to resolve myself or by lack of code review und merge of changes. - Work on JUnit5 support is currently done in the junit5 branch. - I have drafted a Provider Lookup implementation in the junit5 branch, but I don’t know whether it works because I can’t get the integration tests running - There is an open PR to merge the master branch back into junit5 branch, but it has build failures I don’t understand [1] Please help! Cheers, Benedikt [1] https://github.com/apache/maven-surefire/pull/165 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: dependency:go-offline broken?
Hello Brain, > Am 26.09.2017 um 23:10 schrieb Brian Fox : > > On Mon, Sep 25, 2017 at 2:10 PM, Benedikt Ritter wrote: > >> Hello Brian, >> >>> Am 20.09.2017 um 23:16 schrieb Brian Fox : >>> >>> It's been a really long time, but I recall that there were issues getting >>> the dependencies of plugins bound to the lifecycle. This looks to be the >>> same problem. I think the documentation talked about a way to do this >>> effectively. >> >> I’ve looked through the documentation of the dependency plugin, but I can >> not find anything about this. Do you recall where you found that >> documentation? >> >> > Ha no, since I wrote that goal 10 years ago I'm scratching the depth of my > memory. Maybe I just intended to describe it ;-) Thank you for your response. Maybe I’ll just give a little more context about what I’m trying to achieve. Maybe I’m just doing the wrong thing: I have a CI Build in GitLab, where I want to define a job that downloads all the artifacts which are needed for the different lifecycle phases and plugin executions as well as all project dependencies. I only want to download all the stuff once and then copy the artifacts between the build stages. I thought this would be possible with dependency:go-offline so that later steps can be run with mvn -o. Am I missing something or is this simply not possible at the moment? Regards, Benedikt > > >> Regards, >> Benedikt >> >>> >>> On Wed, Sep 20, 2017 at 4:48 PM, Benedikt Ritter >> wrote: >>> >>>> Hi, >>>> >>>> as far as I understand it should be possible to call mvn >>>> dependency:go-offline and from there on work in offline mode (mvn -o). >>>> I’ve put a minimal example together [1] that demonstrates that this >>>> currently does not work. Am I missing anything? >>>> >>>> Thank you! >>>> Benedikt >>>> >>>> [1] https://github.com/britter/dependency-plugin-bug >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: dependency:go-offline broken?
Hello Brian, > Am 20.09.2017 um 23:16 schrieb Brian Fox : > > It's been a really long time, but I recall that there were issues getting > the dependencies of plugins bound to the lifecycle. This looks to be the > same problem. I think the documentation talked about a way to do this > effectively. I’ve looked through the documentation of the dependency plugin, but I can not find anything about this. Do you recall where you found that documentation? Regards, Benedikt > > On Wed, Sep 20, 2017 at 4:48 PM, Benedikt Ritter wrote: > >> Hi, >> >> as far as I understand it should be possible to call mvn >> dependency:go-offline and from there on work in offline mode (mvn -o). >> I’ve put a minimal example together [1] that demonstrates that this >> currently does not work. Am I missing anything? >> >> Thank you! >> Benedikt >> >> [1] https://github.com/britter/dependency-plugin-bug >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
dependency:go-offline broken?
Hi, as far as I understand it should be possible to call mvn dependency:go-offline and from there on work in offline mode (mvn -o). I’ve put a minimal example together [1] that demonstrates that this currently does not work. Am I missing anything? Thank you! Benedikt [1] https://github.com/britter/dependency-plugin-bug - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [SUREFIRE] JUnit 5 support - current state and next steps
Hello Tibor, thank you for sharing your thoughts and thank you for the review. > Am 10.06.2017 um 12:48 schrieb Tibor Digana : > > Both branches are messy. > 3.0-rc1 is pretty old and not working properly because one IT fails. > I wanted to continue on 3.0 two years ago but could not because the plugin > was unstable and the 3.0 Extensions was undefined. The way to have > extensions is clear to me now. Currently now the plugin is able to work > with Maven 3 so the stability has higher preference. So I wanted release > 2.20.1 by the end of this week and then 2.20.2 with JDK 9. After this we > have nothing to fix in stability. > > The JUnit 5 should go to one branch. I do not know why I was so liberal to > accept pushing JUnit 5 provider to 3.0-rc1 branch. Anyway I do not want to > push branches junit5 and 3.0-rc1 directly to master now because it is > technically impossible. Instead I would like to create a patch from > 3.0-rc1, test it, apply the patch in another branch on the top of master > HEAD and commit consistent single commit to new branch 3.0-alpha1 and then > JUnit 5 patch to another branch. These branches will be used for code > review before pushing directly to master. This is usual process. Meanwhile > the branches will be in progress there will be no other activity due to > these are very big and merge conflicts should be avoided. > > So I would propose committing all code related to JUnit 5 to branch junit5 > include changes in AbstractSurefireMojo and add ITs which are necessary. > At the time when we prepare branch for code review we need to have tests to > make sure the code is not risky. > Okay, so let me propose this: I will create a new PR targeted at the junit5 branch, where I will cherry-pick to commits with the provider code. Then I create another PR to remove the provider code vom 3.0-rc1 branch again. This way we have the junit 5 code in a separate branch and can decide where we want to merge it to. Regards, Benedikt > > On Sat, Jun 10, 2017 at 11:24 AM, Tibor Digana-2 [via Maven] < > ml+s40175n5909755...@n5.nabble.com> wrote: > >> Pls give me time to read it. >> >> On Sat, Jun 10, 2017 at 11:06 AM, Benedikt Ritter <[hidden email] >> <http:///user/SendEmail.jtp?type=node&node=5909755&i=0>> >> wrote: >> >>> Hey guys, >>> >>> any thoughts on this? >>> >>> Benedikt >>> >>> Benedikt Ritter <[hidden email] >> <http:///user/SendEmail.jtp?type=node&node=5909755&i=1>> schrieb am Do. >> 8. Juni 2017 um 15:16: >>> >>>> Hello, >>>> >>>> first of all, I’d like to apologize for not being very active over the >>>> past few months. I’ve been busy at work and there was ApacheCON… so >> you >>>> know how it is :-) >>>> >>>> I’d like to take some time to review where we’re standing with JUnit 5 >>>> support and what we our next steps will be. Currently the whole thing >> is >>> a >>>> little bit messed up and I’m pretty much to blame for this: >>>> >>>> - we have a junit5 branch, where I started to implement some >> integration >>>> tests for JUnit 5 support. There are no code changes to Surefire >> itself >>> in >>>> this branch. It just tests that specifying the provider explicitly >> does >>>> work as shown in the JUnit docs. >>>> - then we have 3.0-rc1. We have merged the Provider code from the >> JUnit >>>> team into this branch. But we don’t have any tests there. >>>> - I’ve created a new PR to get work started on a ProviderInfo >>>> implementation to enable automatic provider lookup [1]. This way users >>>> don’t need to specify the provider explicitly anymore. >>>> >>>> So what should be our next steps? >>>> >>>> I think we should merge the junit5 branch into the 3.0-rc1 branch, so >>> that >>>> we have the existing integration tests we already implemented in place >>> for >>>> getting the work on the ProviderInfo started. >>>> Then we will need some time to clean up the integration test project. >> I >>>> think it need to be restructured a little bit to make it easier to >>>> understand and make it possible to run tests against several JUnit >>> versions. >>>> In the end we should be able to verify that all existing JUnit 4 also >>> work >>>> with the JUnit 5 provider. >>>> >>>> @Tibor: Can you merge the junit5 branch to 3.0-rc1 branch? O
Re: [SUREFIRE] JUnit 5 support - current state and next steps
Hey guys, any thoughts on this? Benedikt Benedikt Ritter schrieb am Do. 8. Juni 2017 um 15:16: > Hello, > > first of all, I’d like to apologize for not being very active over the > past few months. I’ve been busy at work and there was ApacheCON… so you > know how it is :-) > > I’d like to take some time to review where we’re standing with JUnit 5 > support and what we our next steps will be. Currently the whole thing is a > little bit messed up and I’m pretty much to blame for this: > > - we have a junit5 branch, where I started to implement some integration > tests for JUnit 5 support. There are no code changes to Surefire itself in > this branch. It just tests that specifying the provider explicitly does > work as shown in the JUnit docs. > - then we have 3.0-rc1. We have merged the Provider code from the JUnit > team into this branch. But we don’t have any tests there. > - I’ve created a new PR to get work started on a ProviderInfo > implementation to enable automatic provider lookup [1]. This way users > don’t need to specify the provider explicitly anymore. > > So what should be our next steps? > > I think we should merge the junit5 branch into the 3.0-rc1 branch, so that > we have the existing integration tests we already implemented in place for > getting the work on the ProviderInfo started. > Then we will need some time to clean up the integration test project. I > think it need to be restructured a little bit to make it easier to > understand and make it possible to run tests against several JUnit versions. > In the end we should be able to verify that all existing JUnit 4 also work > with the JUnit 5 provider. > > @Tibor: Can you merge the junit5 branch to 3.0-rc1 branch? Or should I > create a PR for this? > > Best regards, > Benedikt > > [1] https://github.com/apache/maven-surefire/pull/153 > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
[SUREFIRE] JUnit 5 support - current state and next steps
Hello, first of all, I’d like to apologize for not being very active over the past few months. I’ve been busy at work and there was ApacheCON… so you know how it is :-) I’d like to take some time to review where we’re standing with JUnit 5 support and what we our next steps will be. Currently the whole thing is a little bit messed up and I’m pretty much to blame for this: - we have a junit5 branch, where I started to implement some integration tests for JUnit 5 support. There are no code changes to Surefire itself in this branch. It just tests that specifying the provider explicitly does work as shown in the JUnit docs. - then we have 3.0-rc1. We have merged the Provider code from the JUnit team into this branch. But we don’t have any tests there. - I’ve created a new PR to get work started on a ProviderInfo implementation to enable automatic provider lookup [1]. This way users don’t need to specify the provider explicitly anymore. So what should be our next steps? I think we should merge the junit5 branch into the 3.0-rc1 branch, so that we have the existing integration tests we already implemented in place for getting the work on the ProviderInfo started. Then we will need some time to clean up the integration test project. I think it need to be restructured a little bit to make it easier to understand and make it possible to run tests against several JUnit versions. In the end we should be able to verify that all existing JUnit 4 also work with the JUnit 5 provider. @Tibor: Can you merge the junit5 branch to 3.0-rc1 branch? Or should I create a PR for this? Best regards, Benedikt [1] https://github.com/apache/maven-surefire/pull/153 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[SUREFIRE] JUnit 5 surefire provider code donation
Hi all, I’d like to give you an update about our progress with regards to the surefire support of JUnit 5. I didn’t have much time to work on this over the past couple of month, so please forgive me that it was quite quiet around this topic lately. I’ve talked to Tibor about the next steps in IRC. We’ve agreed to target the 3.0 release with JUnit 5 support. So we won’t work on JUnit 5 support for the 2.x line. Furthermore we agreed that I ask the JUnit team to officially donate their provider code to the maven project so that we can start working on the integration. Next I talked to Marc Philipp from the JUnit team and asked him what might be the best way for them to donate the code. We agreed that they will provide their code unchanged. I’ve created SUREFIRE-1330 [1] and Marc already uploaded a src archive of the provider code. The provider code is ALv2 license and all contributors agreed to the terms of the license [2]. So I think we can now start work on integrating the provider code. Best regards, Benedikt [1] https://issues.apache.org/jira/browse/SUREFIRE-1330 [2] https://github.com/junit-team/junit5/issues/541 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.
Hello, Christian Schulte schrieb am Di., 3. Jan. 2017 um 02:57 Uhr: > Am 01/02/17 um 21:01 schrieb Benson Margulies: > > On Mon, Jan 2, 2017 at 1:38 PM, Hervé BOUTEMY > wrote: > > > >> Christian, > >> > >> Please read Tibor's concerns: > >> - big change, > >> - near release (with parallel branches for JUnit 5) > >> And I'll add: noise, like addition of final, reordering of imports, > >> addition/ > >> suppression of empty lines > >> > >> Please follow Tibor's request, which tries to be as kind as possible: > >>> So now please revert last change [1] and let's start from the ground. > >>> We should again learn from the beginning and start communicating in the > >>> community; otherwise this is the end of the project. > >> > > > > In my uninteresting opinion, Tibor should formally veto the commit. > That's > > not un-nice, it's the way to express, clearly and crisply, his view that > > the change is not acceptable without further discussion and refinement. > On > > the other hand, I don't think that the remarks about 'playgrounds' or > > 'sandboxes' are appropriate or respectful. We should all assume good > intent > > and professional intent. We are running a CTR system here, and so we > should > > expect something like this to happen from time to time, where someone > > commits with the best of intentions and someone else feels strongly that > > more work is needed. > > > > Once Tibor has vetoed, Christian should revert, and then the process > should > > unfold from there. > > > > This part of the commit does not correct any exception suppressed > incorrectly, it really fixes a resource leak (lacking calls to close). > I think everybody should calm down for a moment and remember that we're all just trying to create some great software here :-) At the commons project we usually inform the mailing list when we start to work on components we don't work on a regular basis. Maybe this is the kind of transparency Tibor was asking about. I understand Tibor's point about the surefire codebase. I suspect he feels pretty much left alone. This is what I observed when I was working on the JUnit 5 integration. On the other hand I understand Christians motivation to try to make things better. Regards, Benedikt > > < > https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commitdiff;h=e5a6b9c8d4f514100a01dea2acf1fb059e294968#patch11 > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
[SUREFIRE] Bring more order in the integration tests project?
Hello, at the moment the integration test project has a directory containing almost all integration tests. The Jira issue related tests are located in a sub package. The test/resources directory contains all the test projects with no further ordering. This makes it hard to navigate through the project. I propose to bring more order to the integration test project, by grouping tests into sub packages (e.g. junit, testng, concurrent, ...). Further more the structure should be reflected in the src/test/resources directory so it becomes easier to find related test projects. Thoughts? Benedikt
Re: [SUREFIRE] Issues with classpath and module path
Hello, Robert Scholte schrieb am Do., 24. Nov. 2016 um 20:44 Uhr: > Hi Benedikt, > > I noticed a new thread on the jigsaw mailinglist[1]. > It is close related to the issue I have: you don't want to "patch" java > with arguments just to allow split packages for certain modules. I really > hope that by chaining classloaders we can prevent this. > Thank you Robert. I've also forwarded this to the JUnit team. Benedikt > > Robert > > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010233.html > > On Tue, 22 Nov 2016 20:51:44 +0100, Benedikt Ritter > wrote: > > > Hello again, > > > > Benedikt Ritter schrieb am Fr., 18. Nov. 2016 um > > 08:40 Uhr: > > > >> Hi, > >> > >> I had the pleasure to meet Robert Scholte and Herve Boutemy here at > >> ApacheCon in Seville. We talked al little bit about the progress of the > >> JUnit 5 integration. This let us to create two sample projects which may > >> indicate problems both within surefire and within JUnit. We're still > >> investigating whether this are really issues. I'm in contact with the > >> JUnit > >> team to find out what they might need to fix and I'm reaching out to the > >> Maven community to find out what we need to fix. > >> > >> The first sample project is https://github.com/britter/junit-cl > >> It uses the configuration described at > >> > http://junit.org/junit5/docs/snapshot/user-guide/#running-tests-build-maven-engines-configure > >> to > >> configure the JUnit Jupiter test engine to run some tests. What we want > >> to > >> find out is, whether the test class can see the classes of the test > >> engine > >> (which they should not) and whether the production classes can see the > >> test > >> classes or the test engine classes (which they should not). This is what > >> Robert called the "classpath problem", because everything in mangled > >> together in one classpath. This probably needs to be fixed inside JUnit. > >> Unfortunately currently the configuration described in the JUnit docs > >> does > >> not work. So instead of configuring the jupiter engine, it just reports > >> that it can not find any engines. > >> > > > > I've fixed the problem. The build now works an it fails for the right > > reason :-) > > > > I tried to explain this problem to Marc Philipp from JUnit but I failed > > to > > understand why this is an issue at all. I mean, okay it may be cleaner if > > we had separate classloaders, but what would be a really error scenario a > > user might encounter when the same Classloader loads production and test > > classes? > > > > > >> > >> The second example is https://github.com/britter/junit-java9 and it is > >> about JUnit and Java 9 modules. Robert was sure that there is a problem > >> with modules and that it needs to be fixed in surefire. However we did > >> not > >> get that example working at all, so Robert decided to investigate this > >> some > >> more when he is back home. > >> Here is what we expect to fail: Suppose we have a package com.example > >> with > >> some classes. Then we add some tests in src/test/java in the same > >> package. > >> When we compile this and execute the tests, Java 9 should report that > >> there > >> are several jars providing classes for the com.example package. > >> > > > > I've also applied the fix from above to the java9 example. > > > > Marc Philipp and I agreed upon tackling the Java 9 issue from both (maven > > and junit) sites. He will talk to Sam Brannen from the Spring project and > > ask them how they do reflection in Java 9. Furthermore he things about > > writing to the OpenJDK Mailing list. > > On the Maven site, Robert wanted to take a look into this. @Robert: Did > > you > > have some time to investigate this some more? > > > > Regards, > > Benedikt > > > > > >> > >> Hope I was able to give you a heads up on what we were talking about :-) > >> > >> Regards, > >> Benedikt > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [SUREFIRE] Issues with classpath and module path
Hello again, Benedikt Ritter schrieb am Fr., 18. Nov. 2016 um 08:40 Uhr: > Hi, > > I had the pleasure to meet Robert Scholte and Herve Boutemy here at > ApacheCon in Seville. We talked al little bit about the progress of the > JUnit 5 integration. This let us to create two sample projects which may > indicate problems both within surefire and within JUnit. We're still > investigating whether this are really issues. I'm in contact with the JUnit > team to find out what they might need to fix and I'm reaching out to the > Maven community to find out what we need to fix. > > The first sample project is https://github.com/britter/junit-cl > It uses the configuration described at > http://junit.org/junit5/docs/snapshot/user-guide/#running-tests-build-maven-engines-configure > to > configure the JUnit Jupiter test engine to run some tests. What we want to > find out is, whether the test class can see the classes of the test engine > (which they should not) and whether the production classes can see the test > classes or the test engine classes (which they should not). This is what > Robert called the "classpath problem", because everything in mangled > together in one classpath. This probably needs to be fixed inside JUnit. > Unfortunately currently the configuration described in the JUnit docs does > not work. So instead of configuring the jupiter engine, it just reports > that it can not find any engines. > I've fixed the problem. The build now works an it fails for the right reason :-) I tried to explain this problem to Marc Philipp from JUnit but I failed to understand why this is an issue at all. I mean, okay it may be cleaner if we had separate classloaders, but what would be a really error scenario a user might encounter when the same Classloader loads production and test classes? > > The second example is https://github.com/britter/junit-java9 and it is > about JUnit and Java 9 modules. Robert was sure that there is a problem > with modules and that it needs to be fixed in surefire. However we did not > get that example working at all, so Robert decided to investigate this some > more when he is back home. > Here is what we expect to fail: Suppose we have a package com.example with > some classes. Then we add some tests in src/test/java in the same package. > When we compile this and execute the tests, Java 9 should report that there > are several jars providing classes for the com.example package. > I've also applied the fix from above to the java9 example. Marc Philipp and I agreed upon tackling the Java 9 issue from both (maven and junit) sites. He will talk to Sam Brannen from the Spring project and ask them how they do reflection in Java 9. Furthermore he things about writing to the OpenJDK Mailing list. On the Maven site, Robert wanted to take a look into this. @Robert: Did you have some time to investigate this some more? Regards, Benedikt > > Hope I was able to give you a heads up on what we were talking about :-) > > Regards, > Benedikt >
[SUREFIRE] Issues with classpath and module path
Hi, I had the pleasure to meet Robert Scholte and Herve Boutemy here at ApacheCon in Seville. We talked al little bit about the progress of the JUnit 5 integration. This let us to create two sample projects which may indicate problems both within surefire and within JUnit. We're still investigating whether this are really issues. I'm in contact with the JUnit team to find out what they might need to fix and I'm reaching out to the Maven community to find out what we need to fix. The first sample project is https://github.com/britter/junit-cl It uses the configuration described at http://junit.org/junit5/docs/snapshot/user-guide/#running-tests-build-maven-engines-configure to configure the JUnit Jupiter test engine to run some tests. What we want to find out is, whether the test class can see the classes of the test engine (which they should not) and whether the production classes can see the test classes or the test engine classes (which they should not). This is what Robert called the "classpath problem", because everything in mangled together in one classpath. This probably needs to be fixed inside JUnit. Unfortunately currently the configuration described in the JUnit docs does not work. So instead of configuring the jupiter engine, it just reports that it can not find any engines. The second example is https://github.com/britter/junit-java9 and it is about JUnit and Java 9 modules. Robert was sure that there is a problem with modules and that it needs to be fixed in surefire. However we did not get that example working at all, so Robert decided to investigate this some more when he is back home. Here is what we expect to fail: Suppose we have a package com.example with some classes. Then we add some tests in src/test/java in the same package. When we compile this and execute the tests, Java 9 should report that there are several jars providing classes for the com.example package. Hope I was able to give you a heads up on what we were talking about :-) Regards, Benedikt
[SUREFIRE] Incorporating JUnit 5 surefire provider
Hello, as you might know, JUnit is EPL licensed. However there is currently an effort going on to relicense the surefire provider under ALv2 [1]. It looks like all contributors have accepted the relicensing, so we can incorporate the provider code soon. Would this be okay for the maven community or do we need to talk to the legal team to make this waterproof? Regards, Benedikt [1] https://github.com/junit-team/junit5/issues/541
Re: [SUREFIRE] JUnit 5 support - how to move things forward?
FYI: the JUnit team is working on relicensing their provider code under AL 2.0 so there should not be a problem for us to accept their contribution. https://github.com/junit-team/junit5/issues/541 BR, Benedikt Benedikt Ritter schrieb am Di. 4. Okt. 2016 um 19:41: > Hello Tibor, > > Tibor Digana schrieb am Di., 4. Okt. 2016 um > 02:14 Uhr: > > +1 to adopt JUnit 5 provider to Maven Surefire git branch. > You would have to extend AbstractSurefireMojo.java with JUnit 5 provider in > classpath builder. > > > I see, we would have to implement a ProviderInfo for JUnit 5. I think I > can work on thins. > > > Do we have to keep using other license? > > > JUnit is EPL. I talked to Marc and they asked all contributors to > explicitly state that they are donating the code under the terms of EPL. > I'm not sure how we would handle it. If they explicitly contribute the > code, it should be no problem. Or do we have to talk to legal? > > > Can we ask the JUnit team to continuously migrate stable changes to > Surefire? > > > I think there should be only one home for the provider. Either it is > maven-surefire or it's junit but not both. So if we decide to take over the > provider they will probably stop maintaining their own implementation > because it is not their scope. I've volunteered to help maintaining the > code since I'd like to get involved in the maven project and in junit. If > that's not enough, we have to find a different solution. > > Regards, > Benedikt > > > > > On Mon, Oct 3, 2016 at 7:39 PM, Benedikt Ritter [via Maven] < > ml-node+s40175n5882104...@n5.nabble.com> wrote: > > > Hi, > > > > now that we have a separate branch for the JUnit 5 support in the > surefire > > repo, I'm asking myself how to much things forward. I've added some > > additional IT implementations in my GitHub fork, but they all fail > because > > the 5.0.0-M2 release of junit-surefire-provider does not implement the > > desired features. > > > > At this point I'm pretty much blocked: I can not pick up the latest > > changes > > to the JUnit 5 provider, because the JUnit team has not released it. The > > JUnit team does not push the development of the provider further, since > > they don't have integration tests... > > Right now I think it would be best to start implementing a JUnit 5 > > provider > > ourself in the junit5 branch, so we can add the missing features and have > > it ready when JUnit 5 reaches GA. > > > > Thoughts? > > > > Benedikt > > > > > > -- > > If you reply to this email, your message will be added to the discussion > > below: > > http://maven.40175.n5.nabble.com/SUREFIRE-JUnit-5-support- > > how-to-move-things-forward-tp5882104.html > > To start a new topic under Maven Developers, email > > ml-node+s40175n142166...@n5.nabble.com > > To unsubscribe from Maven Developers, click here > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg== > > > > . > > NAML > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml > > > > > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Re-SUREFIRE-JUnit-5-support-how-to-move-things-forward-tp5882138.html > Sent from the Maven Developers mailing list archive at Nabble.com. > >
Re: [SUREFIRE] Parameterized Tests for Junit 4 and Junit 5? (Was: [SUREFIRE] JUnit 5 support - how to move things forward?)
Tibor Digana schrieb am Di., 11. Okt. 2016 um 10:01 Uhr: > Both old Jenkins builds [1] already use JDK 8. > So this should not be a problem. > Perfect! I have something put together in a local branch. I think you're going to like it :-) > > [1] > https://builds.apache.org/job/maven-surefire/ > https://builds.apache.org/job/maven-surefire-windows/ > > > On Mon, Oct 10, 2016 at 7:03 PM, Benedikt Ritter [via Maven] < > ml-node+s40175n5882750...@n5.nabble.com> wrote: > > > Hello again, > > > > Tibor Digana <[hidden email] > > <http:///user/SendEmail.jtp?type=node&node=5882750&i=0>> schrieb am Mi., > > 5. Okt. 2016 um > > 00:05 Uhr: > > > > > >>Or do we want to even share the test projects and work with profiles > > in > > > the test project pom? > > > > > > I mean this. > > > > > > It pretty depends on what we are going to test, either: > > > + features of surefire-junit5 provider, or > > > + features of junit5 itself. > > > > > > I would say the provider in the first phase, and in the second phase we > > > should identify junit5 features which do not exist in junit4 but may > > > influence, e.g. Surefire report. > > > > > > The main purpose of integration testing is the interoperability between > > the > > > main process of Maven and surefire (forked jvm or in-plugin process). > > > > > > This would lower the development time because you can already reuse > > > existing tests. > > > It would be nice to have profiles for vintage and jupiter. If we find > > out > > > difference between reports, this can be a subject to a discovered bug. > > > I think we can keep all IT projects and IT classes where they are and > we > > > can also keep sources using JUnit4 annotations together with JUnit5 > > > annotations. The best was that you split the JUni5 project into > > > junit-jupiter-api and the core modules. > > > If we just add junit-jupiter-api to the main section in > > > every POM, we do not break old tests because JUnit5 annotations do not > > > break JUnit4 runners. If we want to run JUnit5 tests, then the profiles > > > come into the role (one having junit-jupiter-engine > > > <https://github.com/junit-team/junit5/tree/master/junit-jupiter-engine > > > > > and > > > another profile with junit-vintage-engine > > > <https://github.com/junit-team/junit5/tree/master/junit-vintage-engine > >, > > > > > and finally profiles for old junit4 or 47). Unfortunately JUnit4 does > > not > > > have separate module with annotations only. Therefore we may use > > > to exclude it if really necessary, see > > > > > > http://maven.apache.org/surefire/maven-surefire- > > plugin/examples/configuring-classpath.html > > > Do you think this would work? > > > > > > > I found a way to this. I've modified the Junit4VersionIT again to run > > against JUnit 4 and JUnit 5. > > > > Drawbacks: > > - all tests have to be run on Java 8. Otherwise we can't have the JUnit 5 > > annotations > > - the profile for the jupiter engine also needs a dependency to junit > 4.x. > > Otherwise we get a compilation error because the old annotations are not > > available. > > > > I think this could be a starting point. After we have merged #126 from > > GitHub, I can build this on top the parameterized test. > > > > Regards, > > Benedikt > > > > > > > > > > Cheers > > > Tibor > > > > > > > > > On Tue, Oct 4, 2016 at 7:48 PM, Benedikt Ritter [via Maven] < > > > [hidden email] /user/SendEmail.jtp?type=node&node=5882750&i=1>> > > wrote: > > > > > > > Hello Tibor, > > > > > > > > Tibor Digana <[hidden email] > > > > <http:///user/SendEmail.jtp?type=node&node=5882181&i=0>> schrieb am > > Di., > > > > 4. Okt. 2016 um > > > > 02:29 Uhr: > > > > > > > > > Can you simplify and speed up writing integration tests in the way > > that > > > > you > > > > > would parameterize the existing JUnit 4 testing by adding Maven > > > profiles > > > > > (one default profile and junit5 profile) having another > dependencies > > > and > > > > > @RunWith(Parameterized.class)? > > > > > This would be cool because we can h
Re: [SUREFIRE] Hangout with Marc Philipp
Hello Tibor,
okay, I will prepare something, after we have integrated the parameterized
JUnit4VersionsIT into junit5 branch.
Tibor Digana schrieb am Di., 11. Okt. 2016 um
19:50 Uhr:
> Sorry for my typos, again:
> *Maybe we should setup second trigger in Jenkins build for junir5 branch
> and run ASF build if any change is pushed to ASF or JUnit Git repository.*
>
> On Tue, Oct 11, 2016 at 7:48 PM, Tibor Digana
> wrote:
>
> > We can follow already existing principle and declare JUnit5 version in
> [1].
> > There is already such good example:
> >
> >
> > ${project.version}
> > ${testng.version}
> >
> > [1] https://github.com/apache/maven-surefire/blob/master/
> > surefire-integration-tests/pom.xml
> >
> > Regarding Surefire JUnit5 Provider, you can integrate it right now since
> > the branch *junit5 *is apart of master.
> > I think this would be quite good signal sent outside as well.
> > The drawback is a little work in *AbstractSurefireMojo.java* at the
> > starting point when the provider is being moved.
> > I don't know how easy it would be to frequently migrate all changes but
> we
> > can have some intermediate step and that is surefire-junit5 provider as a
> > new module dependent on SNAPSHOT of JUnit5 provider. This means our
> provide
> > can be a kind of wrapper around real provider in JUnit5 project. This way
> > we have ITs and immediate reflection of changes in JUnit5 project. Maybe
> we
> > should setup second trigger in Jenkins build and run ASF build if any
> > change in pushed to ASF of JUnit Git repository.
> >
> >
> >
> >
> > On Tue, Oct 11, 2016 at 1:25 PM, Tibor Digana
> > wrote:
> >
> >> Hi Benedikt,
> >>
> >> I do not have any problem with SNAPSHOT version in the branch junit5.
> >> Even this can be very easily accomplished. Let's put property, e.g.
> >> version.junit5, into [1] and reference to this POM via parent
> declaration
> >> in your root POM of particular IT having JUnit5 tests.
> >> [1]
> >> https://github.com/apache/maven-surefire/blob/master/surefir
> >> e-integration-tests/src/test/resources/pom.xml
> >>
> >>
> >> On Mon, Oct 10, 2016 at 6:43 PM, Benedikt Ritter [via Maven] <
> >> ml-node+s40175n5882740...@n5.nabble.com> wrote:
> >>
> >> > Hi,
> >> >
> >> > I've had the chance to talk to Marc Philipp from the JUnit team again,
> >> and
> >> > I'd like to share with you some of our discussions.
> >> >
> >> > First we talked about the progress with the surefire provider:
> >> > Currently I've done not much. We have a junit5 branch with a single PR
> >> > merged (the JUnit5VersionsIT). Further more we have some pending PRs
> >> which
> >> > need to be reviewed/merged. We haven't done any "real" development
> yet.
> >> >
> >> > I told Marc that a problem with implementing the ITs at the moment is,
> >> > that
> >> > the JUnit 5.0.0-m2 provider implementation is very limited. So we
> >> thought
> >> > it may be a good thing to depend on the SNAPSHOT of JUnit5 in the
> junit5
> >> > as
> >> > long as we do not have our own implementation. This may be fragile,
> but
> >> we
> >> > can pick up the latest changes to the provider implementation.
> >> >
> >> > Then we talked about moving the provider code from junit to
> >> > maven-surefire.
> >> > This is clearly the preferred way to go for the junit team. From a
> user
> >> > perspective it would also be better to not have a junit provider and a
> >> > maven-surefire provider for junit5.
> >> >
> >> > The problem we identified may be when this code could be released at
> >> > maven-surefire. Currently JUnit 5 GA is expected sometime in early
> 2017.
> >> > If
> >> > the provider code is moved to maven-surefire there should be a release
> >> > very
> >> > soon after the JUnit 5 GA release. Otherwise nobody can use JUnit 5
> with
> >> > maven.
> >> > The alternative would be, that JUnit releases the provider
> >> implementation
> >> > when they go GA and after that the code is moved to surefire. The
> >> problem
> >> > with this approach is, that it may lead to confusion for the users.
> >> >
> >> > My personal view is, that it would be good t
Re: [SUREFIRE] Parameterized Tests for Junit 4 and Junit 5? (Was: [SUREFIRE] JUnit 5 support - how to move things forward?)
Hello again, Tibor Digana schrieb am Mi., 5. Okt. 2016 um 00:05 Uhr: > >>Or do we want to even share the test projects and work with profiles in > the test project pom? > > I mean this. > > It pretty depends on what we are going to test, either: > + features of surefire-junit5 provider, or > + features of junit5 itself. > > I would say the provider in the first phase, and in the second phase we > should identify junit5 features which do not exist in junit4 but may > influence, e.g. Surefire report. > > The main purpose of integration testing is the interoperability between the > main process of Maven and surefire (forked jvm or in-plugin process). > > This would lower the development time because you can already reuse > existing tests. > It would be nice to have profiles for vintage and jupiter. If we find out > difference between reports, this can be a subject to a discovered bug. > I think we can keep all IT projects and IT classes where they are and we > can also keep sources using JUnit4 annotations together with JUnit5 > annotations. The best was that you split the JUni5 project into > junit-jupiter-api and the core modules. > If we just add junit-jupiter-api to the main section in > every POM, we do not break old tests because JUnit5 annotations do not > break JUnit4 runners. If we want to run JUnit5 tests, then the profiles > come into the role (one having junit-jupiter-engine > <https://github.com/junit-team/junit5/tree/master/junit-jupiter-engine> > and > another profile with junit-vintage-engine > <https://github.com/junit-team/junit5/tree/master/junit-vintage-engine>, > and finally profiles for old junit4 or 47). Unfortunately JUnit4 does not > have separate module with annotations only. Therefore we may use > to exclude it if really necessary, see > > http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html > Do you think this would work? > I found a way to this. I've modified the Junit4VersionIT again to run against JUnit 4 and JUnit 5. Drawbacks: - all tests have to be run on Java 8. Otherwise we can't have the JUnit 5 annotations - the profile for the jupiter engine also needs a dependency to junit 4.x. Otherwise we get a compilation error because the old annotations are not available. I think this could be a starting point. After we have merged #126 from GitHub, I can build this on top the parameterized test. Regards, Benedikt > > Cheers > Tibor > > > On Tue, Oct 4, 2016 at 7:48 PM, Benedikt Ritter [via Maven] < > ml-node+s40175n5882181...@n5.nabble.com> wrote: > > > Hello Tibor, > > > > Tibor Digana <[hidden email] > > <http:///user/SendEmail.jtp?type=node&node=5882181&i=0>> schrieb am Di., > > 4. Okt. 2016 um > > 02:29 Uhr: > > > > > Can you simplify and speed up writing integration tests in the way that > > you > > > would parameterize the existing JUnit 4 testing by adding Maven > profiles > > > (one default profile and junit5 profile) having another dependencies > and > > > @RunWith(Parameterized.class)? > > > This would be cool because we can have identical assertion statements, > > > means behavior, for multiple providers. > > > > > > > I was already thinking about this, because right now I'm duplicating a > lot > > of the code from the ITs. This is definitely a good idea. But right know > I > > don't have a clear view of how we could implement that. Do we just share > > the test class and work with separate test projects? Or do we want to > even > > share the test projects and work with profiles in the test project pom? > > > > JUnit 5 also has support for running legacy tests (they call it > > "vintage"). > > To make a complete IT suite, we would have to run all the JUnit 4 tests > > against the JUnit 5 vintage engine as well. > > > > Lot a work ahead :-) > > > > Regards, > > Benedikt > > > > > > > > > > On Mon, Oct 3, 2016 at 7:38 PM, Benedikt Ritter <[hidden email] > > <http:///user/SendEmail.jtp?type=node&node=5882181&i=1>> > > > wrote: > > > > > > > Hi, > > > > > > > > now that we have a separate branch for the JUnit 5 support in the > > > surefire > > > > repo, I'm asking myself how to much things forward. I've added some > > > > additional IT implementations in my GitHub fork, but they all fail > > > because > > > > the 5.0.0-M2 release of junit-surefire-provider does not implement > the > > > > desired features. &g
[SUREFIRE] Hangout with Marc Philipp
Hi, I've had the chance to talk to Marc Philipp from the JUnit team again, and I'd like to share with you some of our discussions. First we talked about the progress with the surefire provider: Currently I've done not much. We have a junit5 branch with a single PR merged (the JUnit5VersionsIT). Further more we have some pending PRs which need to be reviewed/merged. We haven't done any "real" development yet. I told Marc that a problem with implementing the ITs at the moment is, that the JUnit 5.0.0-m2 provider implementation is very limited. So we thought it may be a good thing to depend on the SNAPSHOT of JUnit5 in the junit5 as long as we do not have our own implementation. This may be fragile, but we can pick up the latest changes to the provider implementation. Then we talked about moving the provider code from junit to maven-surefire. This is clearly the preferred way to go for the junit team. From a user perspective it would also be better to not have a junit provider and a maven-surefire provider for junit5. The problem we identified may be when this code could be released at maven-surefire. Currently JUnit 5 GA is expected sometime in early 2017. If the provider code is moved to maven-surefire there should be a release very soon after the JUnit 5 GA release. Otherwise nobody can use JUnit 5 with maven. The alternative would be, that JUnit releases the provider implementation when they go GA and after that the code is moved to surefire. The problem with this approach is, that it may lead to confusion for the users. My personal view is, that it would be good to integrate the provider code into maven-surefire as soon as possible, but I not yet firm enough with the code base the be really productive. I hope to get a better understanding of the codebase during the next few weeks. Regards, Benedikt
Re: [SUREFIRE] Jenkins job for junit5 branch
Hi Christopher, Christofer Dutz schrieb am Mo., 10. Okt. 2016 um 10:49 Uhr: > Hi Guys ... I just setup such a build with the Pipeline Plugin for the > Flex project ... is working nicely. I could help you with this, if you like? > I leave this to the maven guys :-) > > > Chris > > > Von: Tibor Digana > Gesendet: Montag, 10. Oktober 2016 08:15:25 > An: dev@maven.apache.org > Betreff: Re: [SUREFIRE] Jenkins job for junit5 branch > > Excellent! > > On Sun, Oct 9, 2016 at 2:16 PM, Benedikt Ritter [via Maven] < > ml-node+s40175n5882475...@n5.nabble.com> wrote: > > > Hello, > > > > I've created a build job for the junit5 branch [1]. It's a copy of the > > maven-surefire job with the only difference that it does not publish > build > > artifacts to the snapshots repository. It maybe possible to configure > this > > more elegantly by using the Jenkins Pipeline Plugin, but I don't know > how. > > I think this is good enough for a start. > > > > Regards, > > Benedikt > > > > [1] https://builds.apache.org/job/maven-surefire-junit5/ > > > > > > -- > > If you reply to this email, your message will be added to the discussion > > below: > > http://maven.40175.n5.nabble.com/SUREFIRE-Jenkins-job-for- > > junit5-branch-tp5882475.html > > To start a new topic under Maven Developers, email > > ml-node+s40175n142166...@n5.nabble.com > > To unsubscribe from Maven Developers, click here > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg== > > > > . > > NAML > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml > > > > > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Re-SUREFIRE-Jenkins-job-for-junit5-branch-tp5882626.html > Sent from the Maven Developers mailing list archive at Nabble.com. >
Re: [SUREFIRE] Parameterized Tests for Junit 4 and Junit 5? (Was: [SUREFIRE] JUnit 5 support - how to move things forward?)
Hello Tibor,
I've played around a bit with the idea and I think there is a problem:
If you want to compile and run test using JUnit 4 annotations using JUnit
5, you need the vintage enigne in your dependencies. Otherwise you get
compile errors, because neither jupiter engine nor jupiter api ship the old
annotations. So I end up with a dependency declaration like this:
org.junit.jupiter
junit-jupiter-engine
${junit.jupiter.version}
test
org.junit.vintage
junit-vintage-engine
${junit.vintage.version}
test
This will cause JUnit 5 to execute everything on the vintage engine. If we
want to share test code across JUnit versions, I need to also add the
jupiter API annotations to the test code. But I still need the vintage
engine in order to get it to compile.
Now I have a test like:
public class MixedTest
{
@org.junit.Test
@org.junit.api.jupiter.Test
public test()
{
// do something
}
}
Which engine will execute the test? No one knows... So I don't think it's a
good idea to share test classes.
Regards,
Benedikt
Benedikt Ritter schrieb am So., 9. Okt. 2016 um
14:25 Uhr:
> Hello Tibor,
>
> I think I understand what you're thinking of. I'll give it a try and see
> if I can come up with something useful :-)
>
> Regards,
> Benedikt
>
>
> Tibor Digana schrieb am Mi., 5. Okt. 2016
> um 00:18 Uhr:
>
> Instead of using in Surefire (may affect the
> ITs), there is a better trick.
> See the POM surefire-junit47.
> You will see the section of compiler endorsed classpath but Surefire has
> different one:
>
>
>
>
> maven-dependency-plugin
>
>
> main
> process-sources
>
> copy
>
>
>
> ${project.build.directory}/endorsed
> false
> true
>
>
> junit
> junit
> 4.7
> jar
>
>
>
>
>
> test
> process-sources
>
> copy
>
>
>
> ${project.build.directory}/endorsed-test
> false
> true
>
>
> junit
> junit
> 4.12
> jar
>
>
>
>
>
>
>
> maven-compiler-plugin
>
>
> ${project.build.directory}/endorsed
>
>
> ${project.build.directory}/endorsed-test
>
>
>
>
>
>
>
>
> On Tue, Oct 4, 2016 at 7:47 PM, Benedikt Ritter
> wrote:
>
> > Hello Tibor,
> >
> > Tibor Digana schrieb am Di., 4. Okt. 2016
> um
> > 02:29 Uhr:
> >
> > > Can you simplify and speed up writing integration tests in the way that
> > you
> > > would parameterize the existing JUnit 4 testing by adding Maven
> profiles
> > > (one default profile and junit5 profile) having another dependencies
> and
> > > @RunWith(Parameterized.class)?
> > > This would be cool because we can have identical assertion statements,
> > > means behavior, for multiple providers.
> > >
> >
> > I was already thinking about this, because right now I'm duplicating a
> lot
> > of the code from the ITs. This is definitely a good idea. But right know
> I
> > don't have a clear view of how we could implement that. Do we just share
> > the test class and work with separate test projects? Or do we want to
> even
> > share the test projects and work with profiles in the test project pom?
> >
> > JUnit 5 also has support for running legacy tests (they call it
> "vintage").
> > To make a complete IT suite, we would have to run all the JUnit 4 tests
> > against the JUnit 5 vintage engine as well.
> >
> > Lot a work ahead :-)
> >
> > Regards,
> > Benedikt
> >
> >
> > >
> > > On Mon, Oct 3, 2016 at 7:38 PM, Benedikt Ritter
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > now that we have a separate branch for the JUnit 5 support in the
> > > surefire
> > > > repo, I'm asking myself how to much things forward. I've added some
> > > > additional IT implementations in my GitHub fork, but they all fail
> > > because
> > > > the 5.0.0-M2 release of junit-surefire-provider does not implement
> the
> > > > desired features.
> > > >
> > > > At this point I'm pretty much blocked: I can not pick up the latest
> > > changes
> > > > to the JUnit 5 provider, because the JUnit team has not released it.
> > The
> > > > JUnit team does not push the development of the provider further,
> since
> > > > they don't have integration tests...
> > > > Right now I think it would be best to start implementing a JUnit 5
> > > provider
> > > > ourself in the junit5 branch, so we can add the missing features and
> > have
> > > > it ready when JUnit 5 reaches GA.
> > > >
> > > > Thoughts?
> > > >
> > > > Benedikt
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > > Tibor
> > >
> >
>
>
>
> --
> Cheers
> Tibor
>
>
Re: [SUREFIRE] Parameterized Tests for Junit 4 and Junit 5? (Was: [SUREFIRE] JUnit 5 support - how to move things forward?)
Hello Tibor,
I think I understand what you're thinking of. I'll give it a try and see if
I can come up with something useful :-)
Regards,
Benedikt
Tibor Digana schrieb am Mi., 5. Okt. 2016 um
00:18 Uhr:
> Instead of using in Surefire (may affect the
> ITs), there is a better trick.
> See the POM surefire-junit47.
> You will see the section of compiler endorsed classpath but Surefire has
> different one:
>
>
>
>
> maven-dependency-plugin
>
>
> main
> process-sources
>
> copy
>
>
>
> ${project.build.directory}/endorsed
> false
> true
>
>
> junit
> junit
> 4.7
> jar
>
>
>
>
>
> test
> process-sources
>
> copy
>
>
>
> ${project.build.directory}/endorsed-test
> false
> true
>
>
> junit
> junit
> 4.12
> jar
>
>
>
>
>
>
>
> maven-compiler-plugin
>
>
> ${project.build.directory}/endorsed
>
>
> ${project.build.directory}/endorsed-test
>
>
>
>
>
>
>
>
> On Tue, Oct 4, 2016 at 7:47 PM, Benedikt Ritter
> wrote:
>
> > Hello Tibor,
> >
> > Tibor Digana schrieb am Di., 4. Okt. 2016
> um
> > 02:29 Uhr:
> >
> > > Can you simplify and speed up writing integration tests in the way that
> > you
> > > would parameterize the existing JUnit 4 testing by adding Maven
> profiles
> > > (one default profile and junit5 profile) having another dependencies
> and
> > > @RunWith(Parameterized.class)?
> > > This would be cool because we can have identical assertion statements,
> > > means behavior, for multiple providers.
> > >
> >
> > I was already thinking about this, because right now I'm duplicating a
> lot
> > of the code from the ITs. This is definitely a good idea. But right know
> I
> > don't have a clear view of how we could implement that. Do we just share
> > the test class and work with separate test projects? Or do we want to
> even
> > share the test projects and work with profiles in the test project pom?
> >
> > JUnit 5 also has support for running legacy tests (they call it
> "vintage").
> > To make a complete IT suite, we would have to run all the JUnit 4 tests
> > against the JUnit 5 vintage engine as well.
> >
> > Lot a work ahead :-)
> >
> > Regards,
> > Benedikt
> >
> >
> > >
> > > On Mon, Oct 3, 2016 at 7:38 PM, Benedikt Ritter
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > now that we have a separate branch for the JUnit 5 support in the
> > > surefire
> > > > repo, I'm asking myself how to much things forward. I've added some
> > > > additional IT implementations in my GitHub fork, but they all fail
> > > because
> > > > the 5.0.0-M2 release of junit-surefire-provider does not implement
> the
> > > > desired features.
> > > >
> > > > At this point I'm pretty much blocked: I can not pick up the latest
> > > changes
> > > > to the JUnit 5 provider, because the JUnit team has not released it.
> > The
> > > > JUnit team does not push the development of the provider further,
> since
> > > > they don't have integration tests...
> > > > Right now I think it would be best to start implementing a JUnit 5
> > > provider
> > > > ourself in the junit5 branch, so we can add the missing features and
> > have
> > > > it ready when JUnit 5 reaches GA.
> > > >
> > > > Thoughts?
> > > >
> > > > Benedikt
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > > Tibor
> > >
> >
>
>
>
> --
> Cheers
> Tibor
>
[SUREFIRE] Jenkins job for junit5 branch
Hello, I've created a build job for the junit5 branch [1]. It's a copy of the maven-surefire job with the only difference that it does not publish build artifacts to the snapshots repository. It maybe possible to configure this more elegantly by using the Jenkins Pipeline Plugin, but I don't know how. I think this is good enough for a start. Regards, Benedikt [1] https://builds.apache.org/job/maven-surefire-junit5/
[SUREFIRE] Parameterized Tests for Junit 4 and Junit 5? (Was: [SUREFIRE] JUnit 5 support - how to move things forward?)
Hello Tibor, Tibor Digana schrieb am Di., 4. Okt. 2016 um 02:29 Uhr: > Can you simplify and speed up writing integration tests in the way that you > would parameterize the existing JUnit 4 testing by adding Maven profiles > (one default profile and junit5 profile) having another dependencies and > @RunWith(Parameterized.class)? > This would be cool because we can have identical assertion statements, > means behavior, for multiple providers. > I was already thinking about this, because right now I'm duplicating a lot of the code from the ITs. This is definitely a good idea. But right know I don't have a clear view of how we could implement that. Do we just share the test class and work with separate test projects? Or do we want to even share the test projects and work with profiles in the test project pom? JUnit 5 also has support for running legacy tests (they call it "vintage"). To make a complete IT suite, we would have to run all the JUnit 4 tests against the JUnit 5 vintage engine as well. Lot a work ahead :-) Regards, Benedikt > > On Mon, Oct 3, 2016 at 7:38 PM, Benedikt Ritter > wrote: > > > Hi, > > > > now that we have a separate branch for the JUnit 5 support in the > surefire > > repo, I'm asking myself how to much things forward. I've added some > > additional IT implementations in my GitHub fork, but they all fail > because > > the 5.0.0-M2 release of junit-surefire-provider does not implement the > > desired features. > > > > At this point I'm pretty much blocked: I can not pick up the latest > changes > > to the JUnit 5 provider, because the JUnit team has not released it. The > > JUnit team does not push the development of the provider further, since > > they don't have integration tests... > > Right now I think it would be best to start implementing a JUnit 5 > provider > > ourself in the junit5 branch, so we can add the missing features and have > > it ready when JUnit 5 reaches GA. > > > > Thoughts? > > > > Benedikt > > > > > > -- > Cheers > Tibor >
Re: [SUREFIRE] JUnit 5 support - how to move things forward?
Hello Tibor, Tibor Digana schrieb am Di., 4. Okt. 2016 um 02:14 Uhr: > +1 to adopt JUnit 5 provider to Maven Surefire git branch. > You would have to extend AbstractSurefireMojo.java with JUnit 5 provider in > classpath builder. > I see, we would have to implement a ProviderInfo for JUnit 5. I think I can work on thins. > Do we have to keep using other license? > JUnit is EPL. I talked to Marc and they asked all contributors to explicitly state that they are donating the code under the terms of EPL. I'm not sure how we would handle it. If they explicitly contribute the code, it should be no problem. Or do we have to talk to legal? > Can we ask the JUnit team to continuously migrate stable changes to > Surefire? > I think there should be only one home for the provider. Either it is maven-surefire or it's junit but not both. So if we decide to take over the provider they will probably stop maintaining their own implementation because it is not their scope. I've volunteered to help maintaining the code since I'd like to get involved in the maven project and in junit. If that's not enough, we have to find a different solution. Regards, Benedikt > > > On Mon, Oct 3, 2016 at 7:39 PM, Benedikt Ritter [via Maven] < > ml-node+s40175n5882104...@n5.nabble.com> wrote: > > > Hi, > > > > now that we have a separate branch for the JUnit 5 support in the > surefire > > repo, I'm asking myself how to much things forward. I've added some > > additional IT implementations in my GitHub fork, but they all fail > because > > the 5.0.0-M2 release of junit-surefire-provider does not implement the > > desired features. > > > > At this point I'm pretty much blocked: I can not pick up the latest > > changes > > to the JUnit 5 provider, because the JUnit team has not released it. The > > JUnit team does not push the development of the provider further, since > > they don't have integration tests... > > Right now I think it would be best to start implementing a JUnit 5 > > provider > > ourself in the junit5 branch, so we can add the missing features and have > > it ready when JUnit 5 reaches GA. > > > > Thoughts? > > > > Benedikt > > > > > > -- > > If you reply to this email, your message will be added to the discussion > > below: > > http://maven.40175.n5.nabble.com/SUREFIRE-JUnit-5-support- > > how-to-move-things-forward-tp5882104.html > > To start a new topic under Maven Developers, email > > ml-node+s40175n142166...@n5.nabble.com > > To unsubscribe from Maven Developers, click here > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg== > > > > . > > NAML > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml > > > > > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Re-SUREFIRE-JUnit-5-support-how-to-move-things-forward-tp5882138.html > Sent from the Maven Developers mailing list archive at Nabble.com.
[SUREFIRE] JUnit 5 support - how to move things forward?
Hi, now that we have a separate branch for the JUnit 5 support in the surefire repo, I'm asking myself how to much things forward. I've added some additional IT implementations in my GitHub fork, but they all fail because the 5.0.0-M2 release of junit-surefire-provider does not implement the desired features. At this point I'm pretty much blocked: I can not pick up the latest changes to the JUnit 5 provider, because the JUnit team has not released it. The JUnit team does not push the development of the provider further, since they don't have integration tests... Right now I think it would be best to start implementing a JUnit 5 provider ourself in the junit5 branch, so we can add the missing features and have it ready when JUnit 5 reaches GA. Thoughts? Benedikt
Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?
Hi,
sorry for the late reply... :-)
Stephen Connolly schrieb am Mo., 26. Sep.
2016 um 12:03 Uhr:
> Well another question is how much longer will we support Java 7 anyway...
> what we have said in the past is the next release line after JDK9 is
> released will only support Java 8+... now we could change that, but that is
> *currently* what we have currently stated. I suspect that a bump to Java 8
> by commons-lang would have a corresponding major version bump... would that
> also include a package name relocation (ala commons-lang3) to indicate
> breaking API changes?
>
Not necessarily. If we just add new API for example for dealing with
java.util.function.Function, we would consider this a compatible change and
not bump the major version number.
If we decide to do a major version number bump, we would change maven and
package coordinates.
But TBH, I don't see Commons Lang 4.0 any time soon, simply because we
don't have enough man power.
>
> Would the commons PMC object to us looking for maintenance releases on the
> old line (perhaps even with us committing the fixes to the maintenance line
> if necessary... IIUI commons is "open commit" so any Maven committer
> *should* have a commit bit on commons... we'd just need the commons PMC to
> assist getting releases out)?
>
Traditionally we just maintain two release lines. For Commons Lang we still
provide the 2.x release line but the main development line is 3.x. TBH
there has been no development/fixes in the 2.x line for ages. But
theoretically we could push out a new 2.x release if anything critical
shows up.
So we would usually not maintain, say 3.4.x and 3.4+, because we don't have
enough resources.
Yes Commons is open for all Apache Committers and we invite every Apache
Committer to come and collaborate at Apache Commons. So if any Maven
Committer wants to push out a Maintenance release of Component XY, we're
happy to help with that.
When it comes to releases, at the moment only the Commons PMC LDAP group
can deploy to our group ID. But if anybody shows serious interest in
pushing a release we simply grant the necessary karma.
>
> I suspect the answers to the above are all favourable... in which case I
> say "don't let us hold you back"
>
Okay, I still think it will take some time until we seriously consider
moving to Java 8 (we're currently Java 6), but it's good to get some
feedback early.
Thank you!
Benedikt
>
> On 25 September 2016 at 15:20, Robert Scholte
> wrote:
>
> > On Sun, 25 Sep 2016 16:11:22 +0200, Benedikt Ritter
> > wrote:
> >
> > Hello Robert,
> >>
> >> just watched your JavaOne presentation. Very interesting :-)
> >>
> >
> > thanks!
> >
> >
> >> Robert Scholte schrieb am So., 25. Sep. 2016 um
> >> 13:48 Uhr:
> >>
> >> It depends. If you are changing existing methods to only work with
> Java8,
> >>> that would be a problem (read: we cannot upgrade). If you have both
> Java8
> >>> and pre-Java8 implementations, either by reflection or proper
> >>> encapsulated
> >>> code it'll work for us.
> >>> We do it ourselves too[1]
> >>>
> >>> for us it would be nice if the target is still 1.7
> >>>
> >>> if ( isJava8() )
> >>> { // do java8 stuff }
> >>> else
> >>> { do classic stuff } )
> >>>
> >>> if the java8 stuff uses reflection, you can build it with JDK7,
> otherwise
> >>> you must use JDK8
> >>>
> >>>
> >> We're thinking about adding APIs for dealing with e.g. Functions. So
> >> maven.compiler.source and maven.compiler.target would be 1.8. This would
> >> require downstream user to also compile with Java 8. If I understand
> >> correctly, this would be a problem for Maven, right?
> >>
> >
> > As long as we say that users can run Maven with Java7, then yes it would
> > block us from upgrading. Is that a problem? Maybe, as long as we don't
> hit
> > a bug commons-lang.
> >
> > Robert
> >
> >
> >
> >> Regards,
> >> Benedikt
> >>
> >>
> >>
> >>> Robert
> >>>
> >>> [1]
> >>>
> >>> https://maven.apache.org/shared/maven-shared-utils/xref/org/
> >>> apache/maven/shared/utils/io/FileUtils.html#L831
> >>>
> >>> On Sun, 25 Sep 2016 09:48:56 +0200, Benedikt Ritter <
> brit...@apache.org>
> >>> wrote:
> >>>
> >>> > Hi,
> >>> >
> >>> > at the Apache Commons Pr
Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?
Hello Robert,
just watched your JavaOne presentation. Very interesting :-)
Robert Scholte schrieb am So., 25. Sep. 2016 um
13:48 Uhr:
> It depends. If you are changing existing methods to only work with Java8,
> that would be a problem (read: we cannot upgrade). If you have both Java8
> and pre-Java8 implementations, either by reflection or proper encapsulated
> code it'll work for us.
> We do it ourselves too[1]
>
> for us it would be nice if the target is still 1.7
>
> if ( isJava8() )
> { // do java8 stuff }
> else
> { do classic stuff } )
>
> if the java8 stuff uses reflection, you can build it with JDK7, otherwise
> you must use JDK8
>
We're thinking about adding APIs for dealing with e.g. Functions. So
maven.compiler.source and maven.compiler.target would be 1.8. This would
require downstream user to also compile with Java 8. If I understand
correctly, this would be a problem for Maven, right?
Regards,
Benedikt
>
> Robert
>
> [1]
>
> https://maven.apache.org/shared/maven-shared-utils/xref/org/apache/maven/shared/utils/io/FileUtils.html#L831
>
> On Sun, 25 Sep 2016 09:48:56 +0200, Benedikt Ritter
> wrote:
>
> > Hi,
> >
> > at the Apache Commons Project we're currently discussing where we can
> > host
> > utility classes for working with the features introduced in Java 8. One
> > proposal add this to Commons Lang [1]. Since Apache Maven makes use of
> > Commons Lang, I would like to know whether it would be a problem for you
> > if
> > Commons Lang would require Java 8.
> >
> > Thank you,
> > Benedikt
> >
> > [1] http://markmail.org/message/ecxc4brpxufamuzu
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?
Hello Tibor, Tibor Digana schrieb am So., 25. Sep. 2016 um 10:27 Uhr: > What a new API is needed from commons-lang:3.7 in Maven? > Do we need to have something from the latest commons-lang and latest JDK ? > Benedikt, can you provide us with API changes on the web so that we would > better understand. > I understand that commons might be needed in the integration test classes > in Surefire project but Maven is compiles with Java 1.7. If we compiled > Maven with Java 1.8 then we forced the users to change their CI jobs and > infrastructure. > We don't have any concrete plans yet. We're just thinking about it. So I can't give you any examples yet. Regards, Benedikt > > Cheers > Tibor > > > > On Sun, Sep 25, 2016 at 9:49 AM, Benedikt Ritter [via Maven] < > ml-node+s40175n5881450...@n5.nabble.com> wrote: > > > Hi, > > > > at the Apache Commons Project we're currently discussing where we can > host > > utility classes for working with the features introduced in Java 8. One > > proposal add this to Commons Lang [1]. Since Apache Maven makes use of > > Commons Lang, I would like to know whether it would be a problem for you > > if > > Commons Lang would require Java 8. > > > > Thank you, > > Benedikt > > > > [1] http://markmail.org/message/ecxc4brpxufamuzu > > > > > > -- > > If you reply to this email, your message will be added to the discussion > > below: > > http://maven.40175.n5.nabble.com/Would-Commons-Lang-on- > > Java-8-be-a-problem-for-the-Apache-Maven-project-tp5881450.html > > To start a new topic under Maven Developers, email > > ml-node+s40175n142166...@n5.nabble.com > > To unsubscribe from Maven Developers, click here > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg== > > > > . > > NAML > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml > > > > > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Would-Commons-Lang-on-Java-8-be-a-problem-for-the-Apache-Maven-project-tp5881450p5881451.html > Sent from the Maven Developers mailing list archive at Nabble.com.
Would Commons Lang on Java 8 be a problem for the Apache Maven project?
Hi, at the Apache Commons Project we're currently discussing where we can host utility classes for working with the features introduced in Java 8. One proposal add this to Commons Lang [1]. Since Apache Maven makes use of Commons Lang, I would like to know whether it would be a problem for you if Commons Lang would require Java 8. Thank you, Benedikt [1] http://markmail.org/message/ecxc4brpxufamuzu
Re: [SUREFIRE] Branch for JUnit 5 integration?
Hello, the branch with the first JUnit 5 IT is ready for reintegration. My proposal is to create a separate branch for working on JUnit 5 so that we can merge it to master only when all work on JUnit 5 support is done. Regards, Benedikt Tibor Digana schrieb am Mo., 12. Sep. 2016 um 01:13 Uhr: > ok, go on with the branch but then please create CI job in > https://builds.apache.org/job/maven-surefire/. > We will nicely see how the branch is still in green. > I want to be brief. I understand that this work takes private time, I was > idle for cca 5 months in Surefire and recovered recently. Many colleagues > in Maven are idle for years and only send some emails but these emails move > us ahead which is positive as well. > > On Sat, Sep 10, 2016 at 2:49 PM, Benedikt Ritter [via Maven] < > ml-node+s40175n5880358...@n5.nabble.com> wrote: > > > Hi, > > > > I'm currently a bit stuck with the JUnit 5 integration, because I don't > > really know where it should be going. At first I thought we should just > > merge the Integration tests I'm about to write directly to master. But > > maybe that's not the best idea. But I don't want to implement the whole > > thing in my fork as well since this will lead to a unmanagable huge > change > > set when it will be reintegrated. So my proposal is to create a separate > > branch in the maven-surefire repo I can open PRs against. This way I can > > iteratively add more stuff in small chucks but is does not land directly > > on > > master. > > > > WDYT? > > > > Regards, > > Benedikt > > > > > > -- > > If you reply to this email, your message will be added to the discussion > > below: > > http://maven.40175.n5.nabble.com/SUREFIRE-Branch-for-JUnit- > > 5-integration-tp5880358.html > > To start a new topic under Maven Developers, email > > ml-node+s40175n142166...@n5.nabble.com > > To unsubscribe from Maven Developers, click here > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg== > > > > . > > NAML > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml > > > > > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Re-SUREFIRE-Branch-for-JUnit-5-integration-tp5880473.html > Sent from the Maven Developers mailing list archive at Nabble.com.
[SUREFIRE] Branch for JUnit 5 integration?
Hi, I'm currently a bit stuck with the JUnit 5 integration, because I don't really know where it should be going. At first I thought we should just merge the Integration tests I'm about to write directly to master. But maybe that's not the best idea. But I don't want to implement the whole thing in my fork as well since this will lead to a unmanagable huge change set when it will be reintegrated. So my proposal is to create a separate branch in the maven-surefire repo I can open PRs against. This way I can iteratively add more stuff in small chucks but is does not land directly on master. WDYT? Regards, Benedikt
Re: Code Style for IntelliJ 2016.2
Hello Tibor, that file does not seem to work with IntelliJ 2016.2 :-( I think I will have to configure the code style myself. Benedikt Tibor Digana schrieb am Fr., 9. Sep. 2016 um 15:00 Uhr: > Sorry I did not get notice this email. You need to configure your IDE for > you pending PR in GitHub, right? :) > I use IntelliJ IDEA 14.1.7. The code style for IDEA: > https://maven.apache.org/developers/maven-idea-codestyle.xml > https://maven.apache.org/developers/conventions/code.html > > On Wed, Sep 7, 2016 at 9:04 PM, Benedikt Ritter [via Maven] < > ml-node+s40175n5880158...@n5.nabble.com> wrote: > > > Hi maven devs, > > > > which code style file do you use for IntelliJ 2016.2? I've imported the > > file from http://maven.apache.org/developers/committer-environment.html > but > > > > is does not work properly (for example is does not place curly braces on > > new lines) > > > > Thank you! > > Benedikt > > > > > > -- > > If you reply to this email, your message will be added to the discussion > > below: > > http://maven.40175.n5.nabble.com/Code-Style-for-IntelliJ- > > 2016-2-tp5880158.html > > To start a new topic under Maven Developers, email > > ml-node+s40175n142166...@n5.nabble.com > > To unsubscribe from Maven Developers, click here > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg== > > > > . > > NAML > > < > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml > > > > > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Code-Style-for-IntelliJ-2016-2-tp5880158p5880283.html > Sent from the Maven Developers mailing list archive at Nabble.com.
Re: [SUREFIRE] How does Junit4VersionsIT work?
Hello Tibor,
thank you for solving the mistery :-) I will put together a PR to fix the
IT.
Regards,
Benedikt
Tibor Digana schrieb am Do., 8. Sep. 2016 um 22:08:
> This is obviously a bug and junit.version should be used.
> If you type "unpack().debugLogging()." in the IT you will see that the
> classpath contains junit-4.4 instead of the providing one.
> There are several such cases but not all ITs alter the version.
>
> On Wed, Sep 7, 2016 at 9:10 PM, Benedikt Ritter [via Maven] <
> ml-node+s40175n5880159...@n5.nabble.com> wrote:
>
> > Hi surefire devs,
> >
> > I don't understand how the Junit4VersionsIT sets the JUnit version to use
> > during testing. The version is set as sysProp "junit.version" on
> > mavenLauncher, but the test pom.xml in the resources/junit4 folder
> > uses ${junitVersion} to set the JUnit version. How does this work? Does
> > maven automatically convert between the two property keys?
> >
> > Regards,
> > Benedikt
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> http://maven.40175.n5.nabble.com/SUREFIRE-How-does-Junit4VersionsIT-work-
> > tp5880159.html
> > To start a new topic under Maven Developers, email
> > ml-node+s40175n142166...@n5.nabble.com
> > To unsubscribe from Maven Developers, click here
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==
> >
> > .
> > NAML
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Re-SUREFIRE-How-does-Junit4VersionsIT-work-tp5880204.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
[SUREFIRE] How does Junit4VersionsIT work?
Hi surefire devs,
I don't understand how the Junit4VersionsIT sets the JUnit version to use
during testing. The version is set as sysProp "junit.version" on
mavenLauncher, but the test pom.xml in the resources/junit4 folder
uses ${junitVersion} to set the JUnit version. How does this work? Does
maven automatically convert between the two property keys?
Regards,
Benedikt
Code Style for IntelliJ 2016.2
Hi maven devs, which code style file do you use for IntelliJ 2016.2? I've imported the file from http://maven.apache.org/developers/committer-environment.html but is does not work properly (for example is does not place curly braces on new lines) Thank you! Benedikt
Re: MNG-5889 fix available
Hello Robert, you can either create a git diff and attach it as txt file to the jira issue or you submit a pull request using the GitHub mirror at https://github.com/apache/maven. Regards, Benedikt Robert Patrick schrieb am Mi., 7. Sep. 2016 um 00:04 Uhr: > I have fixed for Bug HYPERLINK " > https://issues.apache.org/jira/browse/MNG-5889"MNG-5889. How should I > submit the fix? > > > > > > -- > > Robert Patrick mailto:robert.patr...@oracle.com"; > robert.patr...@oracle.com> > > VP, OPC Development, Oracle Corporation > > 7460 Warren Pkwy, Ste. 300 Office: +1.972.963.2872 > > Frisco, TX 75034, USA Mobile: +1.469.556.9450 > > > > HYPERLINK " > http://www.amazon.com/Professional-Oracle-WebLogic-Server-Patrick/dp/0470484306/"Professional > Oracle WebLogic Server > > by Robert Patrick, Gregory Nyberg, and Philip Aston > > with Josh Bregman and Paul Done > > Book Home Page: HYPERLINK " > http://www.wrox.com/WileyCDA/WroxTitle/Professional-Oracle-WebLogic-Server.productCd-0470484306.html > "http://www.wrox.com/ > > Kindle Version: HYPERLINK " > http://www.amazon.com/Professional-Oracle-WebLogic-Server-ebook/dp/B004HD69J2/ > "http://www.amazon.com/ > > > > >
Re: [GitHub] maven-plugins pull request #91: MCHANGES-373
Hello Mikael, Michael Osipov has asked two times why the change set shows the whole class as changed. So there has been feedback. Regards, Benedikt Mikael Petterson schrieb am Mi., 7. Sep. 2016 um 08:08 Uhr: > Hi, > > Is there no one that can help out with my pull request or is the > maven-changes plugin "dead"? > We really need this fix to be able to use the plugin. And also we want to > be able to help out. > It is a bit frustrating when nothing happens > > //mikael > > > -Original Message- > From: Mikael Petterson [mailto:mikael.petter...@ericsson.com] > Sent: den 5 september 2016 14:48 > To: Maven Developers List > Subject: RE: [GitHub] maven-plugins pull request #91: MCHANGES-373 > > Hi, > > Just a friendly reminder to review code and if ok commit. > > Br, > > //mikael > > -Original Message- > From: mpet [mailto:g...@git.apache.org] > Sent: den 29 augusti 2016 13:51 > To: dev@maven.apache.org > Subject: [GitHub] maven-plugins pull request #91: MCHANGES-373 > > GitHub user mpet opened a pull request: > > https://github.com/apache/maven-plugins/pull/91 > > MCHANGES-373 > > > > You can merge this pull request into a Git repository by running: > > $ git pull https://github.com/mpet/maven-plugins MCHANGES-373 > > Alternatively you can review and apply these changes as the patch at: > > https://github.com/apache/maven-plugins/pull/91.patch > > To close this pull request, make a commit to your master/trunk branch with > (at least) the following in the commit message: > > This closes #91 > > > commit 699dd3bf3649c150913a0dd1eda25966bc6f6f1c > Author: mike > Date: 2016-08-29T11:39:24Z > > MCHANGES-373 > > > > > --- > If your project is set up for it, you can reply to this email and have > your reply appear on GitHub as well. If your project does not have this > feature enabled and wishes so, or if the feature is enabled but not > working, please contact infrastructure at infrastruct...@apache.org or > file a JIRA ticket with INFRA. > --- > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional > commands, e-mail: dev-h...@maven.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional > commands, e-mail: dev-h...@maven.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [SUREFIRE] Surefire provider for JUnit 5?
Hello Tibor, good idea! I've talked to Marc Philipp from the JUnit team and he want's to join us, so we can make a plan how to move things forward. When would you be available for a chat on freenode? Best Regards, Benedikt Tibor Digana schrieb am Di., 30. Aug. 2016 um 22:46 Uhr: > Benedikt, let's go to IRC freenode.net for developers. > > On Tue, Aug 30, 2016 at 10:44 PM, Tibor Digana > wrote: > > > I would like to help you but currently I can't because I am in hurry with > > release and few issues and then I have to fix one IT in Surefire 3.0 > which > > fails because of unresolved transitive dependencies. So this may take > some > > time for me. > > > > On Tue, Aug 30, 2016 at 10:06 PM, Benedikt Ritter [via Maven] < > > ml-node+s40175n587945...@n5.nabble.com> wrote: > > > > > Hello Tibor, > > > > > > Tibor Digana <[hidden email] > > > <http:///user/SendEmail.jtp?type=node&node=5879457&i=0>> schrieb am > Mo., > > > 29. Aug. 2016 um > > > 12:56 Uhr: > > > > > > > Hi Benedikt, > > > > > > > > I found out that JUNit 5 was release with ALPHA version in Maven > > > Central. > > > > I guess there is no need to rush in Surefire yet. > > > > The JUnit team should contribute in JUnit code line in the artifact > > > > project org.junit.surefire-junit5 and test that provider. AFter the > it > > > > is stable with non-alpha and non-beta version we can take over, but > > > > the next question would be license of JUnit 5. > > > > > > > > > > I think the team has enough to do with getting JUnit 5 out of the door. > > > That's why they would be happy if the provider would be moved to the > > maven > > > project. > > > > > > > > > > JUnit 5 is developed with license Eclipse Public License v1.0. > > > > We can accept ASF 2.0 license. > > > > See http://repo1.maven.org/maven2/org/junit/surefire-junit5/ > > > > > > > > > > > EPL falls under the category of weak-copy left licenses. So this may be > > an > > > issue [1]. Would probably be best to check with legal before importing > > any > > > code. > > > > > > Regards, > > > Benedikt > > > > > > [1] http://www.apache.org/legal/resolved.html#category-b > > > > > > > > > > -- > > > > Cheers > > > > Tibor > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > > > http://maven.40175.n5.nabble.com/SUREFIRE-Surefire- > > provider-for-JUnit-5- > > > tp5879054p5879245.html > > > > Sent from the Maven Developers mailing list archive at Nabble.com. > > > > > > > > > -- > > > If you reply to this email, your message will be added to the > discussion > > > below: > > > > http://maven.40175.n5.nabble.com/SUREFIRE-Surefire-provider-for-JUnit-5- > > > tp5879054p5879457.html > > > To start a new topic under Maven Developers, email > > > ml-node+s40175n142166...@n5.nabble.com > > > To unsubscribe from Maven Developers, click here > > > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp? > > macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3 > > wxNDIxNjZ8LTI4OTQ5MjEwMg==> > > > . > > > NAML > > > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp? > > macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml& > > base=nabble.naml.namespaces.BasicNamespace-nabble.view. > > web.template.NabbleNamespace-nabble.view.web.template. > > NodeNamespace&breadcrumbs=notify_subscribers%21nabble% > > 3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_ > > instant_email%21nabble%3Aemail.naml> > > > > > > > > > > > > > -- > > View this message in context: http://maven.40175.n5.nabble. > > com/SUREFIRE-Surefire-provider-for-JUnit-5-tp5879054p5879471.html > > Sent from the Maven Developers mailing list archive at Nabble.com. > > >
Re: [SUREFIRE] Surefire provider for JUnit 5?
Hello Tibor, Tibor Digana schrieb am Mo., 29. Aug. 2016 um 12:56 Uhr: > Hi Benedikt, > > I found out that JUNit 5 was release with ALPHA version in Maven Central. > I guess there is no need to rush in Surefire yet. > The JUnit team should contribute in JUnit code line in the artifact > project org.junit.surefire-junit5 and test that provider. AFter the it > is stable with non-alpha and non-beta version we can take over, but > the next question would be license of JUnit 5. > I think the team has enough to do with getting JUnit 5 out of the door. That's why they would be happy if the provider would be moved to the maven project. > JUnit 5 is developed with license Eclipse Public License v1.0. > We can accept ASF 2.0 license. > See http://repo1.maven.org/maven2/org/junit/surefire-junit5/ > > EPL falls under the category of weak-copy left licenses. So this may be an issue [1]. Would probably be best to check with legal before importing any code. Regards, Benedikt [1] http://www.apache.org/legal/resolved.html#category-b > -- > Cheers > Tibor > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/SUREFIRE-Surefire-provider-for-JUnit-5-tp5879054p5879245.html > Sent from the Maven Developers mailing list archive at Nabble.com.
Re: [SUREFIRE] Surefire provider for JUnit 5?
Hello Tibor, Tibor Digana schrieb am Sa., 27. Aug. 2016 um 22:48 Uhr: > The JUnit5 team create junit5-provider which might be nice to have a > look inside. I don't know if this provider has all features Surefire > provided through surefire-junit47-provider, I know for certain that > junit5-provider converts JUnit 5 Executor to JUnit 4 Runners and > that's the way to support all features again. > Their idea was to contribute the code of the junit5-provider to the maven project. So there would be a new provider sub module for JUnit 5. Given the fact that they changed the whole architecture of JUnit in the Jupiter release, I think it makes sense to have a new provider for this. Who do you feel about that? Regards, Benedikt > On 8/27/16, Tibor Digana wrote: > > hm, you know, I don't like new provider because it's a lot of work to > > support all the features we had in surefire-junit47. This may always > > go with bugs and finally more work for you, integration tests, ... > > > > On 8/27/16, Benedikt Ritter wrote: > >> Tibor Digana schrieb am Sa., 27. Aug. > 2016 > >> um > >> 15:01 Uhr: > >> > >>> I won't ha ve much time for JUnit 5 provider because I am preparing > >>> Version 2.19.2 to release and next release with blocker and critical > >>> fix, then 3.0-RC1. > >>> > >>> Feel free to open pull request in GitHub for JUnit 5 provider. > >>> > >> > >> Great, I'll review what has already be implemented at the JUnit project > >> and > >> then create a PR for integrating it into the surefire code base. > >> > >> Best regards, > >> Benedikt > >> > >> > >>> > >>> > >>> On 8/27/16, Kristian Rosenvold wrote: > >>> > Hi, Benedikt :) > >>> > > >>> > JUnit 5 provider is cool, yes please :) > >>> > > >>> > Providers have different language levels (the different modules have > >>> > different language levels), and I am sure we can build with jdk8. > jdk8 > >>> > still supports the target 1.6, right ? > >>> > > >>> > Kristian > >>> > > >>> > > >>> > > >>> > > >>> > 2016-08-27 11:23 GMT+02:00 Benedikt Ritter : > >>> >> Hi, > >>> >> > >>> >> I'm currently at SoCraTes 2016 [1] and I got a chance to talk to > Marc > >>> >> Philipp [2], who is one of the maintainers of the JUnit project. As > >>> >> you > >>> >> might know, the JUnit team is currently working on the next major > >>> release > >>> >> of JUnit (JUnit 5 a.k.a Jupiter) [3]. Quite a lot will change in > >>> >> JUnit > >>> >> 5 > >>> >> and Marc gave me a kick start about the new architecture. The JUnit > >>> >> team > >>> >> already implemented a rudimentary surefire provider for JUnit 5 [4] > >>> >> and > >>> >> they eventually like to donate it to the maven project. This is > where > >>> >> I > >>> >> come into play, since I know Marc know and I'm a member of the ASF > >>> >> and > >>> >> I > >>> >> though it would be good to help with this. > >>> >> > >>> >> What I'd like to find out is how we can move this forward. So here > >>> >> are > >>> >> two > >>> >> questions to get us started: > >>> >> - is the maven community interested in a donation of a surefire > >>> >> provider > >>> >> for JUnit 5? (I volunteer to drive that and maintain the code > >>> afterwards) > >>> >> - JUnit 5 is Java 8. Will this be a blocker? > >>> >> > >>> >> Looking forward to hearing from you, > >>> >> Benedikt > >>> >> > >>> >> [1] http://socrates-conference.de/ > >>> >> [2] https://twitter.com/marcphilipp > >>> >> [3] http://junit.org/junit5/ > >>> >> [4] > >>> >> > >>> > https://github.com/junit-team/junit5/tree/master/junit-platform-surefire-provider > >>> > > >>> > - > >>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> > For additional commands, e-mail: dev-h...@maven.apache.org > >>> > > >>> > > >>> > >>> > >>> -- > >>> Cheers > >>> Tibor > >>> > >> > > > > > > -- > > Cheers > > Tibor > > > > > -- > Cheers > Tibor > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [SUREFIRE] Surefire provider for JUnit 5?
Tibor Digana schrieb am Sa., 27. Aug. 2016 um 15:01 Uhr: > I won't ha ve much time for JUnit 5 provider because I am preparing > Version 2.19.2 to release and next release with blocker and critical > fix, then 3.0-RC1. > > Feel free to open pull request in GitHub for JUnit 5 provider. > Great, I'll review what has already be implemented at the JUnit project and then create a PR for integrating it into the surefire code base. Best regards, Benedikt > > > On 8/27/16, Kristian Rosenvold wrote: > > Hi, Benedikt :) > > > > JUnit 5 provider is cool, yes please :) > > > > Providers have different language levels (the different modules have > > different language levels), and I am sure we can build with jdk8. jdk8 > > still supports the target 1.6, right ? > > > > Kristian > > > > > > > > > > 2016-08-27 11:23 GMT+02:00 Benedikt Ritter : > >> Hi, > >> > >> I'm currently at SoCraTes 2016 [1] and I got a chance to talk to Marc > >> Philipp [2], who is one of the maintainers of the JUnit project. As you > >> might know, the JUnit team is currently working on the next major > release > >> of JUnit (JUnit 5 a.k.a Jupiter) [3]. Quite a lot will change in JUnit 5 > >> and Marc gave me a kick start about the new architecture. The JUnit team > >> already implemented a rudimentary surefire provider for JUnit 5 [4] and > >> they eventually like to donate it to the maven project. This is where I > >> come into play, since I know Marc know and I'm a member of the ASF and I > >> though it would be good to help with this. > >> > >> What I'd like to find out is how we can move this forward. So here are > >> two > >> questions to get us started: > >> - is the maven community interested in a donation of a surefire provider > >> for JUnit 5? (I volunteer to drive that and maintain the code > afterwards) > >> - JUnit 5 is Java 8. Will this be a blocker? > >> > >> Looking forward to hearing from you, > >> Benedikt > >> > >> [1] http://socrates-conference.de/ > >> [2] https://twitter.com/marcphilipp > >> [3] http://junit.org/junit5/ > >> [4] > >> > https://github.com/junit-team/junit5/tree/master/junit-platform-surefire-provider > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > -- > Cheers > Tibor >
[SUREFIRE] Surefire provider for JUnit 5?
Hi, I'm currently at SoCraTes 2016 [1] and I got a chance to talk to Marc Philipp [2], who is one of the maintainers of the JUnit project. As you might know, the JUnit team is currently working on the next major release of JUnit (JUnit 5 a.k.a Jupiter) [3]. Quite a lot will change in JUnit 5 and Marc gave me a kick start about the new architecture. The JUnit team already implemented a rudimentary surefire provider for JUnit 5 [4] and they eventually like to donate it to the maven project. This is where I come into play, since I know Marc know and I'm a member of the ASF and I though it would be good to help with this. What I'd like to find out is how we can move this forward. So here are two questions to get us started: - is the maven community interested in a donation of a surefire provider for JUnit 5? (I volunteer to drive that and maintain the code afterwards) - JUnit 5 is Java 8. Will this be a blocker? Looking forward to hearing from you, Benedikt [1] http://socrates-conference.de/ [2] https://twitter.com/marcphilipp [3] http://junit.org/junit5/ [4] https://github.com/junit-team/junit5/tree/master/junit-platform-surefire-provider
Introducing myself
Hello maven community, I'm Benedikt Ritter, 30 years old from Neuss (Germany). I'm committer and member of the project management committee of the Apache Commons project. I just wanted to introduce myself, since I'd like to contribute to maven (more on that in a separate mail). Looking forward to working with you! Best regards, Benedikt
