[GitHub] [maven-surefire] Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559317708 @t-8ch We have a similar issue [SUREFIRE-1688](https://issues.apache.org/jira/browse/SUREFIRE-1688) which happens when the method annotated by `@BeforeAll` throws an exception. It is similar to this issue but it is not identical. You can leave your comment, maybe you have opinion about the change needed. It looks simple. IMO the fix should be placed at the [line](https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java#L121) so I would like to work on it and satisfy given unit test in the pullrequest #255 . This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6793) Sharing local repo for dependencies and a separate local repo for project
[
https://issues.apache.org/jira/browse/MNG-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984063#comment-16984063
]
Daniel Qian commented on MNG-6793:
--
Thanks [~khmarbaise] , {{verify}} works, I thought I had to {{install}} when I
build a multi-module project, I was wrong.
> Sharing local repo for dependencies and a separate local repo for project
> -
>
> Key: MNG-6793
> URL: https://issues.apache.org/jira/browse/MNG-6793
> Project: Maven
> Issue Type: Wish
> Components: Bootstrap Build
>Reporter: Daniel Qian
>Priority: Minor
> Labels: features
>
> When I use Jenkins to build project I have to make each Job to use its own
> local repo (a local dir in the workspace) to prevent concurrent build error:
> {{withMaven(}}
> {{ mavenLocalRepo: '.local-m2-repo'}}
> {{) {}}
> {{ sh 'mvn clean install -P docker,integration-test'}}
> {{ }}}
> Besides, I have to cleanup workspace after build to save disk space.
> So every time the build starts it have to download all the dependencies and
> that really cost a lot of time.
> So I think it will be nice If maven could share a local repo for dependencies
> and a separate local repo for current built project.
> Then we can save time of download dependencies and also provide isolation to
> prevent concurrent build error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJAVADOC-609) Include jars for which module name cannot be determined on the classpath
[
https://issues.apache.org/jira/browse/MJAVADOC-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983989#comment-16983989
]
Christopher Tubbs commented on MJAVADOC-609:
The pull request to fix MJAVADOC-620
(https://github.com/apache/maven-javadoc-plugin/pull/35) is basically what I
would have come up with to fix this issue, if fixing it at the plugin level, so
it probably is a duplicate of this issue, after all.
> Include jars for which module name cannot be determined on the classpath
>
>
> Key: MJAVADOC-609
> URL: https://issues.apache.org/jira/browse/MJAVADOC-609
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Phil Clay
>Priority: Major
>
> In maven-javadoc-plugin v3.1.0, dependency jars for which the module name
> cannot be determined are not included on the classpath when running the
> javadoc command. This leads to ClassNotFoundExceptions when running javadoc.
> Here is a concrete example:
> When developing features on feature branches, some developers include jira
> issue names in the version of artifacts... e.g. {{ABC-1234-SNAPSHOT}}. This
> leads to jar file names in the form {{foo-ABC-1234-SNAPSHOT.jar}}.
> Unfortunately, an automatic module name cannot be determined from the
> filename of this jar according to the rules of
> [ModuleFinder|https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-].
> When attempting to determine the module name of this jar, the following
> exception is encountered:
> {code:java}
> java.lang.module.FindException: Unable to derive module descriptor for
> C:\Users\foo\.m2\repository\com\bar\foo\ABC-1234-SNAPSHOT\foo-ABC-1234-SNAPSHOT.jar
> at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:647)
> at
> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:330)
> at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:236)
> at
> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:189)
> at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:165)
> at ModuleTest.test(ModuleTest.java:14)
> ... snip
> Caused by: java.lang.IllegalArgumentException: foo.ABC.1234.SNAPSHOT: Invalid
> module name: '1234' is not a Java identifier
> at
> java.base/jdk.internal.module.Checks.requireModuleName(Checks.java:52)
> at
> java.base/java.lang.module.ModuleDescriptor$Builder.(ModuleDescriptor.java:1550)
> at
> java.base/java.lang.module.ModuleDescriptor.newAutomaticModule(ModuleDescriptor.java:2438)
> at
> java.base/jdk.internal.module.ModulePath.deriveModuleDescriptor(ModulePath.java:507)
> at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:643)
> ... 44 more
> {code}
> The maven-javadoc-plugin will swallow this exception (without logging), and
> won't include the jar on the classpath.
> More specifically:
> # [{{AbstractJavadocMojo}} calls
> {{locationManager.resolvePaths(request)}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5144]
> # The returned {{ResolvePathsResult result}} contains the swallowed
> exception in {{result.getPathExceptions()}}. The result does not include the
> file in [{{getModulepathElements()}} or
> {{getClasspathElements()}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5146-L5148]
> # The {{AbstractJavadocMojo}} ignores the path exceptions
> # Therefore, the files that have path exceptions do not get included in the
> classpath or module path
> # Later, this results in ClassNotFoundExceptions when running javadoc
> One workaround is to _not_ use the jira issue name in the version. However,
> this practice is extremely baked into our workflow (there is automation
> around it), and therefore would be very difficult to change.
> I would like the maven-javadoc-plugin to include jars for which the automatic
> module name cannot be determined on the classpath.
> Potential solutions:
> This could potentially be solved in
> [plexus-java|https://github.com/codehaus-plexus/plexus-languages/blob/879376946165679eb3bb980ddaf8db68ab2031d4/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L356],
> by having {{LocationManager.resolvePaths}} return jars for which the
> automatic module name cannot be determined as part of
> {{result.getClasspathElements()}}
> Or, it could be solved it maven-javadoc-plugin by having
> {{AbstractJavadocMojo}} include any
[jira] [Commented] (MJAVADOC-620) Maven Javadoc Plugin fails to resolve the dependencies when used with Java 11
[ https://issues.apache.org/jira/browse/MJAVADOC-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983988#comment-16983988 ] Christopher Tubbs commented on MJAVADOC-620: At first I wouldn't have thought so, because the description of this issue seems more complicated than the one in MJAVADOC-609, but based on the pull request that fixes the issue, it appears this is a duplicate of MJAVADOC-609. Even if it is describing a slightly different issue, the pull request appears like it would fix MJAVADOC-609. > Maven Javadoc Plugin fails to resolve the dependencies when used with Java 11 > - > > Key: MJAVADOC-620 > URL: https://issues.apache.org/jira/browse/MJAVADOC-620 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.1.0, 3.1.1 > Environment: Mageia Linux 7, AdoptOpenJDK 11.0.1 >Reporter: Julien Gouesse >Priority: Major > Attachments: BuildMeFirst.zip, MavenTest.zip, ThenBuildThisSite.zip > > Time Spent: 10m > Remaining Estimate: 0h > > Maven Javadoc Plugin fails to resolve the dependencies that are inherited by > all sub-modules in the parent pom file and the dependencies specific to some > sub-modules if and only if it's used with Java 11 whereas it works flawlessly > with Java 8. This bug is reproducible with this project: > [https://jogamp.org/cgit/ardor3d.git/tree/] > Enter "mvn site" and you'll get the following error message: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site) on > project ardor3d: Error generating maven-javadoc-plugin:3.1.1:aggregate > report: [ERROR] Exit code: 1 - > Ardor3D/ardor3d-swt/src/test/java/com/ardor3d/input/swt/TestSwtMouseWrapper.java:23: > error: package org.eclipse.swt.events does not exist > Note that "mvn install" works with Java 11, this problem of dependency > management only occurs while generating the Java API documentation with Java > 11. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-6699) Inherit dependencies from a WAR type dependency.
[
https://issues.apache.org/jira/browse/MNG-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983987#comment-16983987
]
Frederik Boster edited comment on MNG-6699 at 11/27/19 10:49 PM:
-
While that is true for a Jar project context it is not in a WAR file context.
WAR overlays are a very valid use-case in my opinion to support dependency
resolution in case a WAR references another WAR to create an overlay.
Additionally a WAR can be referenced by another WAR at runtime according to the
JavaEE spec.
It should be the responsibility of the maven-war-plugin to correctly set
bundled jars as "provided" in the deployable POM and the responsibility of
Maven to support resolution of declared dependencies in the POM according to
the same rules as for Jars.
If fat-jars are supported in this way why are WARs not? They are semantically
the same.
was (Author: frederik.boster):
While that is true for a Jar project context it is not in a WAR file context.
WAR overlays are a very valid use-case in my opinion to support dependency
resolution in case a WAR references another WAR to create an overlay.
Additionally a WAR can be referenced by another WAR at runtime according to the
JavaEE spec.
It should be the responsibility of the maven-war-plugin to correctly set
bundled jars as "provided" in the deployable POM and the responsibility of
Maven to support resolution of declared dependencies in the POM according to
the same rules as for Jars.
> Inherit dependencies from a WAR type dependency.
>
>
> Key: MNG-6699
> URL: https://issues.apache.org/jira/browse/MNG-6699
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Frederik Boster
>Priority: Major
>
> Given we have a Maven project, which produces a WAR overlay:
> {code:java}
>
> [...]
> war
> [...]
>
>
> com.example
> my-base-war
> war
>
>
> [...]
>
> {code}
> The dependency and dependency management declarations of
> com.example:my-base-war are not inherited by the overlay.
> The use-case is to create a WAR for Tomcat (as base war) and to enhance it
> with additional Jars for specific cloud providers like Azure and AWS via
> overlays.
> The missing inheritance of dependencies and dependency management results in:
> * maven-war-plugin fails with error "webxml attribute is required", because
> the servlet-api dependency is missing
> ** Workaround: specify `failOnMissingWebXml = false` in maven-war-plugin
> * Dependency Jars being packaged multiple times in different versions
> although already provided by the base war
> ** Workaround: Setting those dependencies to `provided` in the overlay.
> In my opinion the dependencies and dependency management of a WAR shall be
> taken into account by Maven in the same way as for Jars (i.e. fat-jars) to
> provide a coherent inheritance concept.
> Related Issues:
> * MWAR-253
> * MNG-1991
> * MNG-6162
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6699) Inherit dependencies from a WAR type dependency.
[
https://issues.apache.org/jira/browse/MNG-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983987#comment-16983987
]
Frederik Boster commented on MNG-6699:
--
While that is true for a Jar project context it is not in a WAR file context.
WAR overlays are a very valid use-case in my opinion to support dependency
resolution in case a WAR references another WAR to create an overlay.
Additionally a WAR can be referenced by another WAR at runtime according to the
JavaEE spec.
It should be the responsibility of the maven-war-plugin to correctly set
bundled jars as "provided" in the deployable POM and the responsibility of
Maven to support resolution of declared dependencies in the POM according to
the same rules as for Jars.
> Inherit dependencies from a WAR type dependency.
>
>
> Key: MNG-6699
> URL: https://issues.apache.org/jira/browse/MNG-6699
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Frederik Boster
>Priority: Major
>
> Given we have a Maven project, which produces a WAR overlay:
> {code:java}
>
> [...]
> war
> [...]
>
>
> com.example
> my-base-war
> war
>
>
> [...]
>
> {code}
> The dependency and dependency management declarations of
> com.example:my-base-war are not inherited by the overlay.
> The use-case is to create a WAR for Tomcat (as base war) and to enhance it
> with additional Jars for specific cloud providers like Azure and AWS via
> overlays.
> The missing inheritance of dependencies and dependency management results in:
> * maven-war-plugin fails with error "webxml attribute is required", because
> the servlet-api dependency is missing
> ** Workaround: specify `failOnMissingWebXml = false` in maven-war-plugin
> * Dependency Jars being packaged multiple times in different versions
> although already provided by the base war
> ** Workaround: Setting those dependencies to `provided` in the overlay.
> In my opinion the dependencies and dependency management of a WAR shall be
> taken into account by Maven in the same way as for Jars (i.e. fat-jars) to
> provide a coherent inheritance concept.
> Related Issues:
> * MWAR-253
> * MNG-1991
> * MNG-6162
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6670) Resolve the maven dependencies based on a custom property
[ https://issues.apache.org/jira/browse/MNG-6670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNG-6670. Resolution: Cannot Reproduce Unfortunately no feedback. > Resolve the maven dependencies based on a custom property > - > > Key: MNG-6670 > URL: https://issues.apache.org/jira/browse/MNG-6670 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Rama >Priority: Major > Fix For: waiting-for-feedback > > > My objective is to resolve the dependencies based on a given custom property > I have a settings.xml file pointing to my corporate Jfrog Artifactory > repositories. > The libraries in repositories having the custom property "releaseid" > I would like to download the dependencies only if the custom property and > value matches to the given custom property and value. > Custom property and value should be provided from settings.xml or system > properties. > Ex: mvn install -Dreleaseid=2.0 > Do we have any plugin available to accomplish this requirement? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6699) Inherit dependencies from a WAR type dependency.
[
https://issues.apache.org/jira/browse/MNG-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983983#comment-16983983
]
Karl Heinz Marbaise commented on MNG-6699:
--
A war is an artifact (Web Archive) which is a deployable unit on a servlet
engine/application server but can not be used for being used on classpath in
contradiction to a jar file (this is also true for the module path).
> Inherit dependencies from a WAR type dependency.
>
>
> Key: MNG-6699
> URL: https://issues.apache.org/jira/browse/MNG-6699
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Frederik Boster
>Priority: Major
>
> Given we have a Maven project, which produces a WAR overlay:
> {code:java}
>
> [...]
> war
> [...]
>
>
> com.example
> my-base-war
> war
>
>
> [...]
>
> {code}
> The dependency and dependency management declarations of
> com.example:my-base-war are not inherited by the overlay.
> The use-case is to create a WAR for Tomcat (as base war) and to enhance it
> with additional Jars for specific cloud providers like Azure and AWS via
> overlays.
> The missing inheritance of dependencies and dependency management results in:
> * maven-war-plugin fails with error "webxml attribute is required", because
> the servlet-api dependency is missing
> ** Workaround: specify `failOnMissingWebXml = false` in maven-war-plugin
> * Dependency Jars being packaged multiple times in different versions
> although already provided by the base war
> ** Workaround: Setting those dependencies to `provided` in the overlay.
> In my opinion the dependencies and dependency management of a WAR shall be
> taken into account by Maven in the same way as for Jars (i.e. fat-jars) to
> provide a coherent inheritance concept.
> Related Issues:
> * MWAR-253
> * MNG-1991
> * MNG-6162
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1728) maven.test.failure.ignore: differentiate between test failure and timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated SUREFIRE-1728:
---
Description:
On a build server like Jenkins, people typically set
{{-Dmaven.test.failure.ignore=true}} to get the maximum number of test results
instead of failing the build after the first module with test failures.
Unfortunately, timeouts are also ignored when this property is activated,
leaving the Jenkins JUnit plugin no chance to detect that something went wrong
(because a timeout is not reported in a txt or xml report).
See also [JENKINS-46553|https://issues.jenkins-ci.org/browse/JENKINS-46553].
The two cases should be differentiated.
Due to backward compatibility reasons, I am not sure whether it would be wise
to simply exclude timeout cases.
One backward compatible solution might be to extend the value range of
{{maven.test.failure.ignore}} from just {{true}} XOR {{false}} to something
like:
{{true}}/{{all}} XOR {{failure}} XOR {{false}}.
The alternative would be to introduce yet another property...
was:
On a build server like Jenkins, people typically set
{{-Dmaven.test.failure.ignore=true}} to get the maximum number of test results
instead of failing the build after the first module with test failures.
Unfortunately, timeouts are also ignored when this property is activated,
leaving the Jenkins JUnit plugin no chance to detect that something went wrong
(because a timeout is not reported in a txt or xml report).
See also [JENKINS-46553|https://issues.jenkins-ci.org/browse/JENKINS-46553].
The two cases should be differentiated.
Due to backward compatibility reasons, I am not sure whether it would be wise
to simply exclude timeout cases.
One backward compatible solution might be to extend the value range of
{{maven.test.failure.ignore}} from just {{true}} XOR {{false}} to something
like:
{{true}}/{{all}} XOR {{failure}} XOR {{false}}.
The alternative would be to introduce yet another property...
> maven.test.failure.ignore: differentiate between test failure and timeout
> -
>
> Key: SUREFIRE-1728
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1728
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.22.2, 3.0.0-M3
> Environment: Maven 3.6.2
>Reporter: Falko Modler
>Priority: Major
>
> On a build server like Jenkins, people typically set
> {{-Dmaven.test.failure.ignore=true}} to get the maximum number of test
> results instead of failing the build after the first module with test
> failures.
> Unfortunately, timeouts are also ignored when this property is activated,
> leaving the Jenkins JUnit plugin no chance to detect that something went
> wrong (because a timeout is not reported in a txt or xml report).
> See also [JENKINS-46553|https://issues.jenkins-ci.org/browse/JENKINS-46553].
> The two cases should be differentiated.
> Due to backward compatibility reasons, I am not sure whether it would be wise
> to simply exclude timeout cases.
> One backward compatible solution might be to extend the value range of
> {{maven.test.failure.ignore}} from just {{true}} XOR {{false}} to something
> like:
> {{true}}/{{all}} XOR {{failure}} XOR {{false}}.
> The alternative would be to introduce yet another property...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6727) Using version range in parent and CI Friendly Version fails
[
https://issues.apache.org/jira/browse/MNG-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983979#comment-16983979
]
Karl Heinz Marbaise edited comment on MNG-6727 at 11/27/19 10:29 PM:
-
Based on MNG-2199 this has been fixed with Maven 3.5.0-alpha,3.5.0. The error
message looks like using an older version of Maven not one which able to handle
revision property for version tags?.
was (Author: khmarbaise):
Based on MNG-2199 this has been fixed. The error message looks like using an
older version of Maven not one which able to handle revision property for
version tags?.
> Using version range in parent and CI Friendly Version fails
> ---
>
> Key: MNG-6727
> URL: https://issues.apache.org/jira/browse/MNG-6727
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation, POM, Reactor and workspace
>Affects Versions: 3.6.1
>Reporter: Tom Kiemes
>Priority: Major
>
> We would like to pass a [version
> range|https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html] to
> the parent which should be possible since 3.5.0
> At the same time, we would like to use [CI friendly
> versions|https://maven.apache.org/maven-ci-friendly.html] for the artifact
> itself.
> Both on their own work well, but combined they don't.
> {{}}
> {{http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> }}{{xsi:schemaLocation="[http://maven.apache.org/POM/4.0.0]
> [http://maven.apache.org/xsd/maven-4.0.0.xsd];>}}
> {{ 4.0.0}}
> {{ }}
> {{ org.springframework.boot}}
> {{ spring-boot-starter-parent}}
> {{ [2.1,3.0)}}
> {{ }}
> {{ com.example}}
> {{ test}}
> {{ ${revision}}}
> {{ pom}}
> {{ }}
> {{ 0.0.1}}
> {{ }}
> {{}}
>
> The resulting error is:
> {{The project com.example:test:${revision} (/Users/d045390/scratch/test.pom)
> has 1 error}}
> {{[ERROR] Version must be a constant @ line 13, column 12}}
>
> Changing the version range of the parent to a fixed version e.g.
> \{{2.1.5.Release}}, building works.
> Changing the artifact version from ${revision} to a fixed version e.g. 0.0.1
> without using the {{properties}} works as well.
> So it somehow must be the combination of both features which are actually not
> really related or am I missing something?
> PS: I left the modules out for abbreviation purpose. The pom itself can still
> be used to reproduced
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6727) Using version range in parent and CI Friendly Version fails
[
https://issues.apache.org/jira/browse/MNG-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983979#comment-16983979
]
Karl Heinz Marbaise commented on MNG-6727:
--
Based on MNG-2199 this has been fixed. The error message looks like using an
older version of Maven not one which able to handle revision property for
version tags?.
> Using version range in parent and CI Friendly Version fails
> ---
>
> Key: MNG-6727
> URL: https://issues.apache.org/jira/browse/MNG-6727
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation, POM, Reactor and workspace
>Affects Versions: 3.6.1
>Reporter: Tom Kiemes
>Priority: Major
>
> We would like to pass a [version
> range|https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html] to
> the parent which should be possible since 3.5.0
> At the same time, we would like to use [CI friendly
> versions|https://maven.apache.org/maven-ci-friendly.html] for the artifact
> itself.
> Both on their own work well, but combined they don't.
> {{}}
> {{http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> }}{{xsi:schemaLocation="[http://maven.apache.org/POM/4.0.0]
> [http://maven.apache.org/xsd/maven-4.0.0.xsd];>}}
> {{ 4.0.0}}
> {{ }}
> {{ org.springframework.boot}}
> {{ spring-boot-starter-parent}}
> {{ [2.1,3.0)}}
> {{ }}
> {{ com.example}}
> {{ test}}
> {{ ${revision}}}
> {{ pom}}
> {{ }}
> {{ 0.0.1}}
> {{ }}
> {{}}
>
> The resulting error is:
> {{The project com.example:test:${revision} (/Users/d045390/scratch/test.pom)
> has 1 error}}
> {{[ERROR] Version must be a constant @ line 13, column 12}}
>
> Changing the version range of the parent to a fixed version e.g.
> \{{2.1.5.Release}}, building works.
> Changing the artifact version from ${revision} to a fixed version e.g. 0.0.1
> without using the {{properties}} works as well.
> So it somehow must be the combination of both features which are actually not
> really related or am I missing something?
> PS: I left the modules out for abbreviation purpose. The pom itself can still
> be used to reproduced
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SUREFIRE-1728) maven.test.failure.ignore: differentiate between test failure and timeout
Falko Modler created SUREFIRE-1728:
--
Summary: maven.test.failure.ignore: differentiate between test
failure and timeout
Key: SUREFIRE-1728
URL: https://issues.apache.org/jira/browse/SUREFIRE-1728
Project: Maven Surefire
Issue Type: Improvement
Affects Versions: 3.0.0-M3, 2.22.2
Environment: Maven 3.6.2
Reporter: Falko Modler
On a build server like Jenkins, people typically set
{{-Dmaven.test.failure.ignore=true}} to get the maximum number of test results
instead of failing the build after the first module with test failures.
Unfortunately, timeouts are also ignored when this property is activated,
leaving the Jenkins JUnit plugin no chance to detect that something went wrong
(because a timeout is not reported in a txt or xml report).
See also [JENKINS-46553|https://issues.jenkins-ci.org/browse/JENKINS-46553].
The two cases should be differentiated.
Due to backward compatibility reasons, I am not sure whether it would be wise
to simply exclude timeout cases.
One backward compatible solution might be to extend the value range of
{{maven.test.failure.ignore}} from just {{true}} XOR {{false}} to something
like:
{{true}}/{{all}} XOR {{failure}} XOR {{false}}.
The alternative would be to introduce yet another property...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6730) When a ../ relative path is used for the sourceDirectory it is added twice resulting in the compiler reporting duplicate classes
[ https://issues.apache.org/jira/browse/MNG-6730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983976#comment-16983976 ] Karl Heinz Marbaise commented on MNG-6730: -- The related issue has been done with Maven 3.6.2 can you check that again if this solve or not? > When a ../ relative path is used for the sourceDirectory it is added twice > resulting in the compiler reporting duplicate classes > > > Key: MNG-6730 > URL: https://issues.apache.org/jira/browse/MNG-6730 > Project: Maven > Issue Type: Bug >Affects Versions: 3.6.1 > Environment: Linux >Reporter: Peter Lawrey >Priority: Minor > > When using a relative path to pull in source from another module the source > root is added twice in this situation. This doesn't happen with 3.6.0 > ../another-module/src/main/java > With -X you see > Source roots: > base-directory/this-module/../another-module/src/main/java > *and* > base-directory/another-module/src/main/java > making every class appear twice. > > Workaround: use 3.5.x or 3.6.0 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6730) When a ../ relative path is used for the sourceDirectory it is added twice resulting in the compiler reporting duplicate classes
[ https://issues.apache.org/jira/browse/MNG-6730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6730: - Fix Version/s: waiting-for-feedback > When a ../ relative path is used for the sourceDirectory it is added twice > resulting in the compiler reporting duplicate classes > > > Key: MNG-6730 > URL: https://issues.apache.org/jira/browse/MNG-6730 > Project: Maven > Issue Type: Bug >Affects Versions: 3.6.1 > Environment: Linux >Reporter: Peter Lawrey >Priority: Minor > Fix For: waiting-for-feedback > > > When using a relative path to pull in source from another module the source > root is added twice in this situation. This doesn't happen with 3.6.0 > ../another-module/src/main/java > With -X you see > Source roots: > base-directory/this-module/../another-module/src/main/java > *and* > base-directory/another-module/src/main/java > making every class appear twice. > > Workaround: use 3.5.x or 3.6.0 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6741) Modules aggregation from parent does not work
[
https://issues.apache.org/jira/browse/MNG-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983975#comment-16983975
]
Karl Heinz Marbaise commented on MNG-6741:
--
So first my strong recommendation is against a profile in relationship with
modules. This will result in many problems/issues etc. not describes in the
smartics article. Also see
https://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/
If you really have different release cycles for different modules this is a
strong indicator for separating those into separate projects.
Apart from that based on your example project if you give {{mvn -f
parent/pom.xml clean}} you will see something like this:
{code}
MNG-6741$ mvn -f parent/pom.xml clean
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] parent [pom]
[INFO] math [jar]
[INFO]
[INFO] < modules.demo:parent >-
[INFO] Building parent 1.0.0-SNAPSHOT [1/2]
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ parent ---
[INFO]
[INFO] -< modules.demo:math >--
[INFO] Building math 1.0.0-SNAPSHOT [2/2]
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ math ---
[INFO]
[INFO] Reactor Summary for parent 1.0.0-SNAPSHOT:
[INFO]
[INFO] parent . SUCCESS [ 0.137 s]
[INFO] math ... SUCCESS [ 0.003 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.256 s
[INFO] Finished at: 2019-11-27T23:16:28+01:00
[INFO]
{code}
If you just give {{mvn -f build/pom.xml clean}} you will address only a single
pom file which has a parent. This pom does NOT contain any module definition
which means it will try to find other modules as you already seen.
You seemed to expect that giving a parent automatically means it will use its
content as a kind of include file, but it's content is only use to inherit from
and so the modules part is simply ignored. This results in what you have
described.
The question is: Should Maven allow so usage? Allow a parent which contains
module definitions? I would say this should fail the build.
> Modules aggregation from parent does not work
> -
>
> Key: MNG-6741
> URL: https://issues.apache.org/jira/browse/MNG-6741
> Project: Maven
> Issue Type: Bug
>Reporter: Thomas Lehmann
>Priority: Major
> Attachments: demo-maven-modules.zip
>
>
> Hi Maven Team,
> for testing purpose I have a simple setup:
> * three modules in parallel
> ** one for the "build" with a relative path to the "parent"
> ** one for the "parent" with the modules section having "../math" as one
> module
> (for now without any profile)
> ** one for the "math" with a relative path to the "parent"
> * I'm running in the root *Maven 3.6.1* with *mvn -f build clean*
> My expectation:
> * I would like to see "math" in the reactor build order and summary (which
> is not the case)
>
> Of course using " ... " just in the build/pom.xml works
> fine.
> My intention was to split up modules definitions of a real project into
> different profiles in the parent pom being surprised that no module were
> suddently recognized when trying to build.
> That link does describes my intention so I assumed it just work fine:
> https://www.smartics.eu/confluence/display/BLOG/2013/07/22/Using+Aggregate+and+Parent+POMs
> I can say that it also doesn't work with 3.3.9.
> Maybe I missed a certain instruction being required ... then I'm sorry and
> asking you ... please let me know.
> Kind Regards,
> Thomas
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6741) Modules aggregation from parent does not work
[ https://issues.apache.org/jira/browse/MNG-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6741: - Fix Version/s: waiting-for-feedback > Modules aggregation from parent does not work > - > > Key: MNG-6741 > URL: https://issues.apache.org/jira/browse/MNG-6741 > Project: Maven > Issue Type: Bug >Reporter: Thomas Lehmann >Priority: Major > Fix For: waiting-for-feedback > > Attachments: demo-maven-modules.zip > > > Hi Maven Team, > for testing purpose I have a simple setup: > * three modules in parallel > ** one for the "build" with a relative path to the "parent" > ** one for the "parent" with the modules section having "../math" as one > module > (for now without any profile) > ** one for the "math" with a relative path to the "parent" > * I'm running in the root *Maven 3.6.1* with *mvn -f build clean* > My expectation: > * I would like to see "math" in the reactor build order and summary (which > is not the case) > > Of course using " ... " just in the build/pom.xml works > fine. > My intention was to split up modules definitions of a real project into > different profiles in the parent pom being surprised that no module were > suddently recognized when trying to build. > That link does describes my intention so I assumed it just work fine: > https://www.smartics.eu/confluence/display/BLOG/2013/07/22/Using+Aggregate+and+Parent+POMs > I can say that it also doesn't work with 3.3.9. > Maybe I missed a certain instruction being required ... then I'm sorry and > asking you ... please let me know. > Kind Regards, > Thomas -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6745) Dependencies from active profiles should be prepended to project main dependencies
[ https://issues.apache.org/jira/browse/MNG-6745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983966#comment-16983966 ] Karl Heinz Marbaise commented on MNG-6745: -- Can you please create an full working example and either attach to this ticket or create on github and add a link to this ticket? > Dependencies from active profiles should be prepended to project main > dependencies > -- > > Key: MNG-6745 > URL: https://issues.apache.org/jira/browse/MNG-6745 > Project: Maven > Issue Type: Bug > Components: Dependencies >Reporter: ryenus >Priority: Major > > In a project with dependencies coming from activated profiles, I saw those > profile dependencies are appended after project dependencies. > Meanwhile I believe profile dependencies should be prepended before project > dependencies, so that they have a chance to impact the classpath when > conflicting classes exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6746) Maven 3.6.1 does not resolve ${revision} if defined within parent section and when parent pom is externally sourced
[
https://issues.apache.org/jira/browse/MNG-6746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983965#comment-16983965
]
Karl Heinz Marbaise commented on MNG-6746:
--
The resolution for the given property is only done for modules within the same
reactor not outside this means you can use that for a parent entry in the root
module of your multi module build.
> Maven 3.6.1 does not resolve ${revision} if defined within parent section and
> when parent pom is externally sourced
> ---
>
> Key: MNG-6746
> URL: https://issues.apache.org/jira/browse/MNG-6746
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vasiliy
>Priority: Major
> Labels: features
>
> *Current Behavior*
> Create a parent maven project "top" pom (corporate pom) with version
> "1.0.0-SNAPSHOT" like this:
>
> {code:java}
> com.test
> top
> ${revision}
> {code}
>
> Execute the following
> {code:java}
> mvn -Drevision=1.0.0-SNAPSHOT install{code}
> Create another mvn project "child-repo" and provide the pom like this:
>
> {code:java}
> com.test
> child-repo
> ${revision}
>
> com.test
> top
> ${revision}
>
>
> {code}
>
>
> I get an error
> {noformat}
> Non-resolvable parent POM for com.test:top:${revision}: Could not transfer
> artifact com.test:top:pom:${revision} from/to nexus
> ($NEXUS)URL/content/groups/public): Failed to transfer file
> $NEXUS_URL/com/test/top/$%7Brevision%7D/top$%7Brevision%7D.pom with status
> code 400 and 'parent.relativePath' points at wrong local POM @ line 12,
> column 10 -> {noformat}
> The only way to resolve is to also checkout the "top" project and keep at the
> same level as "child-repo" project and add the following to child-repo's
> parent section.
> {code:java}
> ../top{code}
> *Expected Result*
> I would like Maven to resolve the "top" repo from the mvn repository directly
> instead of having it refer it via relativePath.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6751) Warning on empty version of reporting plugins
[
https://issues.apache.org/jira/browse/MNG-6751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6751:
-
Fix Version/s: waiting-for-feedback
> Warning on empty version of reporting plugins
> -
>
> Key: MNG-6751
> URL: https://issues.apache.org/jira/browse/MNG-6751
> Project: Maven
> Issue Type: Task
> Components: Documentation: General
>Affects Versions: 3.6.1
>Reporter: Radek Antoniuk
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> Per [https://maven.apache.org/plugins/maven-site-plugin/maven-3.html]
> _When used with Maven 3, a report plugin version can be empty (like build
> plugins)__._
> but I'm still getting a warning on _mvn site_
> {noformat}
> [WARNING] Report plugin
> org.apache.maven.plugins:maven-project-info-reports-plugin has an empty
> version.
> [WARNING] Report plugin org.owasp:dependency-check-maven has an empty
> version. {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6751) Warning on empty version of reporting plugins
[
https://issues.apache.org/jira/browse/MNG-6751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983962#comment-16983962
]
Karl Heinz Marbaise commented on MNG-6751:
--
Can you please create an example project which shows the behaviour on Github or
simply attach that project to this ticket?
> Warning on empty version of reporting plugins
> -
>
> Key: MNG-6751
> URL: https://issues.apache.org/jira/browse/MNG-6751
> Project: Maven
> Issue Type: Task
> Components: Documentation: General
>Affects Versions: 3.6.1
>Reporter: Radek Antoniuk
>Priority: Minor
>
> Per [https://maven.apache.org/plugins/maven-site-plugin/maven-3.html]
> _When used with Maven 3, a report plugin version can be empty (like build
> plugins)__._
> but I'm still getting a warning on _mvn site_
> {noformat}
> [WARNING] Report plugin
> org.apache.maven.plugins:maven-project-info-reports-plugin has an empty
> version.
> [WARNING] Report plugin org.owasp:dependency-check-maven has an empty
> version. {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6806) Provide Maven BOM
Robert Scholte created MNG-6806: --- Summary: Provide Maven BOM Key: MNG-6806 URL: https://issues.apache.org/jira/browse/MNG-6806 Project: Maven Issue Type: Improvement Reporter: Robert Scholte Fix For: 3.7.0-candidate Maven libraries should always have the same version to ensure they work as expected, hence the preferred way to manage that is with a bom. Let's introduce the maven-bom. See https://www.baeldung.com/spring-maven-bom about how to write and use the bom. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6762) Multimodule project with .mvn/settings.xml not working properly
[
https://issues.apache.org/jira/browse/MNG-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983950#comment-16983950
]
Karl Heinz Marbaise commented on MNG-6762:
--
If you want to build only modules of a multi module project you should use
{{mvn -pl MyModule1 clean package}} instead which means to execute always from
the root of the multi module project. This means in result you could use {{mvn
-s .mvn/settings.xml -pl MyModule1 clean package}}. Also this should work to
execute from the root with the given {{.mvn/maven.config}} which should result
in {{mvn -pl MyModule1 clean package}} in the end.
> Multimodule project with .mvn/settings.xml not working properly
> ---
>
> Key: MNG-6762
> URL: https://issues.apache.org/jira/browse/MNG-6762
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.4
>Reporter: Morten Minke
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I have a project with the following setup:
>
> {noformat}
> - MyProject
> |- .mvn
> | |- maven.config
> | |- settings.xml
> |- MyModule1
> | |- pom.xml
> |- MyModule2
> | |- pom.xml
> |- pom.xml{noformat}
>
> The .mvn/maven.config file contains the following:
> {noformat}
> ..
> --settings .mvn/settings.xml{noformat}
> With this setup, I cannot build the modules separately because it cannot find
> the .mvn/settings.xml file in the MyModule1 directory.
>
> I looked into the code and saw that in the mvn script, the .mvn folder is
> searched for in the parent folders. If it is found, that folder is marked as
> the 'maven.multiModuleProjectDirectory'.
>
> However, as soon as the configuration is loaded, this
> multiModuleProjectDirectory is not used anymore for the interpretation of the
> --settings property, therefor maven tries to find the .mvn/settings.xml file
> inside the MyModule1 folder where it is not found.
> This results in an Exception and termination of Maven.
>
> I thought of a couple of ways this could be solved:
> * Allow for a variable substitution to work in the maven.config file and
> thus reference something like:
> {noformat}
> ..
> --settings ${baseDir}/.mvn/settings.xml{noformat}
> * When the maven.multiModuleProjectDirectory is configured and the
> --settings flag is a relative directory, than use the
> maven.multiModuleProjectDirectory as the root to obtain the settings.xml file.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983941#comment-16983941
]
Karl Heinz Marbaise commented on MNG-6763:
--
The updatePolicy is only for SNAPSHOT dependencies (or more accurate for
snapshot repositories) but not for releases. This can be circumvented by using
`mvn -U ..` on command line to force an update check on a repository if there
are newer SNAPSHOT versions available. Furthermore releases which already have
been downloaded will not checked on the repository manager again (based on the
updatePolicy which is usually set to {{never}} for releases).
Furthermore should your repository manager configured to pull the missing
dependencies from central repository...but this depends on the corporate
policy...
> Restrict repositories to specific groupIds
> --
>
> Key: MNG-6763
> URL: https://issues.apache.org/jira/browse/MNG-6763
> Project: Maven
> Issue Type: New Feature
>Reporter: dennis lucero
>Priority: Major
>
> It should be possible to restrict the repositories specified in settings.xml
> to specific groupIds. Looking at
> [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository],
> it seems this is currently not the case.
> Background: We use Nexus to host our own artifacts. The settings.xml contains
> our Nexus repository with always because
> sometimes a project is built while a dependency is not yet in our Nexus repo
> – without updatePolicy, it would take 24 hours or manual deletion of metadata
> to make Maven re-check for the missing dependency.
> Additionally, we use versions-maven-plugin:2.7:display-dependency-updates in
> our build process.
> This results in lots of queries (more than 300 in a simple Dropwizard
> project) to our repo which will never succeed. If we could specify that our
> repo only supplies groupIds beginning with org.example, Maven could skip
> update checks for groupIds starting with com.fasterxml.jackson and so on,
> speeding up the build process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6766) when i use maven 3.6.2 to replace idea default maven tool,it make error
[ https://issues.apache.org/jira/browse/MNG-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983936#comment-16983936 ] Karl Heinz Marbaise commented on MNG-6766: -- So based on the comment of Matt Nelson I will close this issue. > when i use maven 3.6.2 to replace idea default maven tool,it make error > --- > > Key: MNG-6766 > URL: https://issues.apache.org/jira/browse/MNG-6766 > Project: Maven > Issue Type: Bug >Affects Versions: 3.6.2 > Environment: idea community edition 2019.1.1 > Apache maven 3.6.2 >Reporter: xing zhangfan >Priority: Major > > # when i use maven 3.6.2 to replace idea default maven tool,it make error > the error is show me > 2019-09-16 11:17:03,172 [3662125] ERROR - #org.jetbrains.idea.maven - > IntelliJ IDEA 2019.1.1 Build #IC-191.6707.61 2019-09-16 11:17:03,172 > [3662125] ERROR - #org.jetbrains.idea.maven - IntelliJ IDEA 2019.1.1 > Build #IC-191.6707.61 2019-09-16 11:17:03,173 [3662126] ERROR - > #org.jetbrains.idea.maven - JDK: 1.8.0_202-release; VM: OpenJDK 64-Bit Server > VM; Vendor: JetBrains s.r.o 2019-09-16 11:17:03,173 [3662126] ERROR - > #org.jetbrains.idea.maven - OS: Windows 10 2019-09-16 11:17:03,177 [3662130] > ERROR - #org.jetbrains.idea.maven - Last Action: Maven.Reimport > 2019-09-16 11:17:03,747 [3662700] INFO - mponents.impl.stores.StoreUtil - > saveProjectsAndApp took 119 ms 2019-09-16 11:17:13,030 [3671983] INFO - > mponents.impl.stores.StoreUtil - saveProjectsAndApp took 40 ms 2019-09-16 > 11:17:52,141 [3711094] INFO - mponents.impl.stores.StoreUtil - > saveProjectsAndApp took 43 ms 2019-09-16 11:18:36,280 [3755233] INFO - > mponents.impl.stores.StoreUtil - saveProjectsAndApp took 55 ms 2019-09-16 > 11:18:42,547 [3761500] INFO - mponents.impl.stores.StoreUtil - > saveProjectsAndApp took 34 ms 2019-09-16 11:19:15,884 [3794837] INFO - > rationStore.ComponentStoreImpl - Saving Project > 'E:\work-repo\coocaa-tsp-load-data-station-service' > coocaa-tsp-load-data-station-serviceCompilerConfiguration took 16 ms > 2019-09-16 11:19:16,212 [3795165] INFO - ution.rmi.RemoteProcessSupport - > Terminating: 61054/Maven3ServerImpl87a98b1f 2019-09-16 11:19:16,842 [3795795] > INFO - stubs.SerializationManagerImpl - START StubSerializationManager > SHUTDOWN 2019-09-16 11:19:16,842 [3795795] INFO - > stubs.SerializationManagerImpl - END StubSerializationManager SHUTDOWN > 2019-09-16 11:19:16,842 [3795795] INFO - il.indexing.FileBasedIndexImpl - > START INDEX SHUTDOWN 2019-09-16 11:19:17,571 [3796524] INFO - > il.indexing.FileBasedIndexImpl - END INDEX SHUTDOWN 2019-09-16 11:19:17,634 > [3796587] INFO - org.jetbrains.io.BuiltInServer - web server stopped > 2019-09-16 11:19:17,634 [3796587] INFO - Types.impl.FileTypeManagerImpl - > FileTypeManager: 1031 auto-detected filesElapsed time on auto-detect: 1361 ms > 2019-09-16 11:19:17,665 [3796618] INFO - pl.local.NativeFileWatcherImpl - > Watcher terminated with exit code 0 2019-09-16 11:19:17,665 [3796618] INFO > - newvfs.persistent.PersistentFS - VFS dispose started 2019-09-16 > 11:19:17,681 [3796634] INFO - newvfs.persistent.PersistentFS - VFS dispose > completed 2019-09-16 11:19:17,681 [3796634] INFO - > #com.intellij.idea.Main - > -- IDE SHUTDOWN > -- 2019-09-16 > 11:19:17,681 [3796634] INFO - org.jetbrains.io.BuiltInServer - web server > stopped 2019-09-16 11:20:26,931 [ 0] INFO - > #com.intellij.idea.Main - > -- IDE STARTED > -- 2019-09-16 > 11:20:27,083 [ 152] INFO - #com.intellij.idea.Main - IDE: > IntelliJ IDEA (build #IC-191.6707.61, 16 Apr 2019 23:39) 2019-09-16 > 11:20:27,083 [ 152] INFO - #com.intellij.idea.Main - OS: Windows > 10 (10.0, amd64) 2019-09-16 11:20:27,083 [ 152] INFO - > #com.intellij.idea.Main - JRE: 1.8.0_202-release-1483-b44 (JetBrains s.r.o) > 2019-09-16 11:20:27,083 [ 152] INFO - #com.intellij.idea.Main - > JVM: 25.202-b44 (OpenJDK 64-Bit Server VM) 2019-09-16 11:20:27,095 [ 164] > INFO - #com.intellij.idea.Main - JVM Args: -Xms128m -Xmx750m > -XX:ReservedCodeCacheSize=240m -XX:+UseConcMarkSweepGC > -XX:SoftRefLRUPolicyMSPerMB=50 -ea -Dsun.io.useCanonCaches=false > -Djava.net.preferIPv4Stack=true -Djdk.http.auth.tunneling.disabledSchemes="" > -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow > -Djb.vmOptionsFile=D:\IntelliJ IDEA Community Edition > 2019.1.1\bin\idea64.exe.vmoptions -Didea.platform.prefix=Idea > -Didea.jre.check=true
[jira] [Closed] (MNG-6766) when i use maven 3.6.2 to replace idea default maven tool,it make error
[ https://issues.apache.org/jira/browse/MNG-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNG-6766. Resolution: Not A Problem > when i use maven 3.6.2 to replace idea default maven tool,it make error > --- > > Key: MNG-6766 > URL: https://issues.apache.org/jira/browse/MNG-6766 > Project: Maven > Issue Type: Bug >Affects Versions: 3.6.2 > Environment: idea community edition 2019.1.1 > Apache maven 3.6.2 >Reporter: xing zhangfan >Priority: Major > > # when i use maven 3.6.2 to replace idea default maven tool,it make error > the error is show me > 2019-09-16 11:17:03,172 [3662125] ERROR - #org.jetbrains.idea.maven - > IntelliJ IDEA 2019.1.1 Build #IC-191.6707.61 2019-09-16 11:17:03,172 > [3662125] ERROR - #org.jetbrains.idea.maven - IntelliJ IDEA 2019.1.1 > Build #IC-191.6707.61 2019-09-16 11:17:03,173 [3662126] ERROR - > #org.jetbrains.idea.maven - JDK: 1.8.0_202-release; VM: OpenJDK 64-Bit Server > VM; Vendor: JetBrains s.r.o 2019-09-16 11:17:03,173 [3662126] ERROR - > #org.jetbrains.idea.maven - OS: Windows 10 2019-09-16 11:17:03,177 [3662130] > ERROR - #org.jetbrains.idea.maven - Last Action: Maven.Reimport > 2019-09-16 11:17:03,747 [3662700] INFO - mponents.impl.stores.StoreUtil - > saveProjectsAndApp took 119 ms 2019-09-16 11:17:13,030 [3671983] INFO - > mponents.impl.stores.StoreUtil - saveProjectsAndApp took 40 ms 2019-09-16 > 11:17:52,141 [3711094] INFO - mponents.impl.stores.StoreUtil - > saveProjectsAndApp took 43 ms 2019-09-16 11:18:36,280 [3755233] INFO - > mponents.impl.stores.StoreUtil - saveProjectsAndApp took 55 ms 2019-09-16 > 11:18:42,547 [3761500] INFO - mponents.impl.stores.StoreUtil - > saveProjectsAndApp took 34 ms 2019-09-16 11:19:15,884 [3794837] INFO - > rationStore.ComponentStoreImpl - Saving Project > 'E:\work-repo\coocaa-tsp-load-data-station-service' > coocaa-tsp-load-data-station-serviceCompilerConfiguration took 16 ms > 2019-09-16 11:19:16,212 [3795165] INFO - ution.rmi.RemoteProcessSupport - > Terminating: 61054/Maven3ServerImpl87a98b1f 2019-09-16 11:19:16,842 [3795795] > INFO - stubs.SerializationManagerImpl - START StubSerializationManager > SHUTDOWN 2019-09-16 11:19:16,842 [3795795] INFO - > stubs.SerializationManagerImpl - END StubSerializationManager SHUTDOWN > 2019-09-16 11:19:16,842 [3795795] INFO - il.indexing.FileBasedIndexImpl - > START INDEX SHUTDOWN 2019-09-16 11:19:17,571 [3796524] INFO - > il.indexing.FileBasedIndexImpl - END INDEX SHUTDOWN 2019-09-16 11:19:17,634 > [3796587] INFO - org.jetbrains.io.BuiltInServer - web server stopped > 2019-09-16 11:19:17,634 [3796587] INFO - Types.impl.FileTypeManagerImpl - > FileTypeManager: 1031 auto-detected filesElapsed time on auto-detect: 1361 ms > 2019-09-16 11:19:17,665 [3796618] INFO - pl.local.NativeFileWatcherImpl - > Watcher terminated with exit code 0 2019-09-16 11:19:17,665 [3796618] INFO > - newvfs.persistent.PersistentFS - VFS dispose started 2019-09-16 > 11:19:17,681 [3796634] INFO - newvfs.persistent.PersistentFS - VFS dispose > completed 2019-09-16 11:19:17,681 [3796634] INFO - > #com.intellij.idea.Main - > -- IDE SHUTDOWN > -- 2019-09-16 > 11:19:17,681 [3796634] INFO - org.jetbrains.io.BuiltInServer - web server > stopped 2019-09-16 11:20:26,931 [ 0] INFO - > #com.intellij.idea.Main - > -- IDE STARTED > -- 2019-09-16 > 11:20:27,083 [ 152] INFO - #com.intellij.idea.Main - IDE: > IntelliJ IDEA (build #IC-191.6707.61, 16 Apr 2019 23:39) 2019-09-16 > 11:20:27,083 [ 152] INFO - #com.intellij.idea.Main - OS: Windows > 10 (10.0, amd64) 2019-09-16 11:20:27,083 [ 152] INFO - > #com.intellij.idea.Main - JRE: 1.8.0_202-release-1483-b44 (JetBrains s.r.o) > 2019-09-16 11:20:27,083 [ 152] INFO - #com.intellij.idea.Main - > JVM: 25.202-b44 (OpenJDK 64-Bit Server VM) 2019-09-16 11:20:27,095 [ 164] > INFO - #com.intellij.idea.Main - JVM Args: -Xms128m -Xmx750m > -XX:ReservedCodeCacheSize=240m -XX:+UseConcMarkSweepGC > -XX:SoftRefLRUPolicyMSPerMB=50 -ea -Dsun.io.useCanonCaches=false > -Djava.net.preferIPv4Stack=true -Djdk.http.auth.tunneling.disabledSchemes="" > -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow > -Djb.vmOptionsFile=D:\IntelliJ IDEA Community Edition > 2019.1.1\bin\idea64.exe.vmoptions -Didea.platform.prefix=Idea > -Didea.jre.check=true -Dide.native.launcher=true > -Didea.paths.selector=IdeaIC2019.1 >
[GitHub] [maven] rfscholte commented on issue #287: [MNG-6065] - Log fail-level option.
rfscholte commented on issue #287: [MNG-6065] - Log fail-level option. URL: https://github.com/apache/maven/pull/287#issuecomment-559255764 We probably need 2 loggers, as `MavenFailLevelLogger` comes with some overhead and logging is quite expensive, it should be as fast as possible. Also keep in mind that we now require Java8, so we could optimize the code with that syntax and APIs. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MNG-6768) Support inheritable multiple settings
[ https://issues.apache.org/jira/browse/MNG-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6768: - Fix Version/s: waiting-for-feedback > Support inheritable multiple settings > - > > Key: MNG-6768 > URL: https://issues.apache.org/jira/browse/MNG-6768 > Project: Maven > Issue Type: Improvement > Components: Settings >Reporter: Marco Brandizi >Priority: Minor > Fix For: waiting-for-feedback > > > As far as I know, the --settings option supports just one settings file. > Worse, when it is used, user settings in ~/.m2/settings.xml are ignored (not > tried, but I suspect global settings are too). > To me, this is rather poor. It would be much better if > # user and global settings were inherited and possibly overridden by the > further settings file. > # multiple --settings could be specified and a merge of settings > could be composed by maven (eg, blocks would come from multiple > files, would be overridden, considering the order in the command > line). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6770) Custom mojo changing project version but mavenSession doesn't get updated
[ https://issues.apache.org/jira/browse/MNG-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983933#comment-16983933 ] Karl Heinz Marbaise commented on MNG-6770: -- The thing is first if you like to change the version in your pom file you can of course use `versions-maven-plugin` but this will not work if you execute it within your pom which means to bind it to the life cycle (as you already realised). If you like to have a more flexible way to change the version in your pom or even run without a version in your pom at all I recommend to check out https://maven.apache.org/maven-ci-friendly.html. Furthermore if you have in particular a spring boot application you usually use either the spring-boot-parent (or use a BOM file; than you handle the plugins versions yourself which should be done via corporate pom) which already configures all plugins and also defines the versions of plugins and also defines the versions of artifacts offered by spring boot which should not being changed except the direct dependencies in your own project. I have taken a look into the project you have given as an example. The part for plugins looks more or less the same as the http://takari.io/book/40-lifecycle.html it combines the execution of plugins into a single one. > Custom mojo changing project version but mavenSession doesn't get updated > -- > > Key: MNG-6770 > URL: https://issues.apache.org/jira/browse/MNG-6770 > Project: Maven > Issue Type: Wish >Reporter: Yuna Morgenstern >Priority: Minor > > I am using a custom maven plugin which helps me to preset the other plugins. > When I change my pom version (with > org.codehaus.mojo:versions-maven-plugin:2.7) > and execute the maven-deploy-plugin afterwords, than the plugin is getting my > old version from somewhere in the session. As I am unable to debug through, > it would be great if someone could help me to fix this issue. where are these > properties coming from: "artifact", "projectArtifact", "finalName" > "project.build.finalName", "attachedArtifacts"... > Every plugin seems to work fine except the maven-deploy-plugin which is using > the project version from somewhere. > After versioning, I am changing the project in the MavenProject session as > well without success of effect for the next plugin. The only way is currently > to run my plugin twice. one for deployment and before everything else. > My application is doing following in order: > * Cleaning > * Resolving Plugins & Dependencies > * Updates Plugins & Dependencies > * Updates Project Semantic Version > * Compiles Main & Test > * Builds Javadoc > * Builds Sources > * Builds Artifact file > * Signs files with GPG > * Tagging > * Deployment > Oh and I can't change the Settings xml data in the session, it doesn't have > an effect to the maven-deploy-plugin as well. seems that the deploy plugin > reads the settings file again. can I switch the settings file location in the > mavenSession somehow? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] MartinKanters commented on issue #287: [MNG-6065] - Log fail-level option.
MartinKanters commented on issue #287: [MNG-6065] - Log fail-level option. URL: https://github.com/apache/maven/pull/287#issuecomment-559253285 I'm also wondering whether we should not just go to one Logger, instead of having two (MavenSimpleLogger and MavenFailLevelLogger). It could reduce the complexity in `MavenLoggerFactory`. If we then always supply a `LogLevelRecorder`, either with or without a threshold, we can remove a lot of null-checks as well. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MNG-6389) Move the toolchains model to a separate artifactId
[ https://issues.apache.org/jira/browse/MNG-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6389: Labels: up-for-grabs (was: ) > Move the toolchains model to a separate artifactId > -- > > Key: MNG-6389 > URL: https://issues.apache.org/jira/browse/MNG-6389 > Project: Maven > Issue Type: Improvement > Components: Toolchains >Affects Versions: 3.5.3 >Reporter: George Gastaldi >Priority: Major > Labels: up-for-grabs > Fix For: 3.7.0-candidate > > Time Spent: 10m > Remaining Estimate: 0h > > Just as maven-model and maven-settings, it would be nice to have a > maven-toolchains artifactId containing only the model. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] MartinKanters commented on a change in pull request #287: [MNG-6065] - Log fail-level option.
MartinKanters commented on a change in pull request #287: [MNG-6065] - Log
fail-level option.
URL: https://github.com/apache/maven/pull/287#discussion_r351496658
##
File path:
maven-slf4j-provider/src/main/java/org/slf4j/impl/MavenFailLevelLoggerState.java
##
@@ -19,29 +19,32 @@
* under the License.
*/
-import org.slf4j.Logger;
+import org.slf4j.event.Level;
/**
- * MavenSimpleLoggerFactory
+ * Responsible for keeping state of whether the threshold of the --fail-level
flag has been hit.
*/
-public class MavenSimpleLoggerFactory
-extends SimpleLoggerFactory
+class MavenFailLevelLoggerState
{
-/**
- * Return an appropriate {@link MavenSimpleLogger} instance by name.
- */
-public Logger getLogger( String name )
+private final Level logThreshold;
+private boolean thresholdHit = false;
+
+MavenFailLevelLoggerState( Level logLevel )
{
-Logger simpleLogger = loggerMap.get( name );
-if ( simpleLogger != null )
-{
-return simpleLogger;
-}
-else
+assert logLevel != null;
+this.logThreshold = logLevel;
+}
+
+void recordLogLevel( Level logLevel )
+{
+if ( !thresholdHit && logLevel.toInt() >= logThreshold.toInt() )
{
-Logger newInstance = new MavenSimpleLogger( name );
-Logger oldInstance = loggerMap.putIfAbsent( name, newInstance );
-return oldInstance == null ? newInstance : oldInstance;
+thresholdHit = true;
}
}
+
+boolean threwLogsOfBreakingLevel()
Review comment:
The LogLevel being the threshold? Currently this class holds state whether
the threshold has been hit or not, would you rather like to see that in the
MavenLoggerFactory class?
Personally I would like to see as little as possible loggingLevelThreshold
in the MavenLoggerFactory and encapsulate that into the LogLevelRecorder
possibly.
Now that I think of it, what do you think of only making `LogLevelRecorder`
a field inside `MavenLoggerFactory` with just a getter on the
`MavenSlf4jWrapperFactory` interface?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven] MartinKanters commented on a change in pull request #287: [MNG-6065] - Log fail-level option.
MartinKanters commented on a change in pull request #287: [MNG-6065] - Log fail-level option. URL: https://github.com/apache/maven/pull/287#discussion_r351494913 ## File path: maven-slf4j-provider/src/main/java/org/slf4j/impl/MavenFailLevelLoggerState.java ## @@ -19,29 +19,32 @@ * under the License. */ -import org.slf4j.Logger; +import org.slf4j.event.Level; /** - * MavenSimpleLoggerFactory + * Responsible for keeping state of whether the threshold of the --fail-level flag has been hit. */ -public class MavenSimpleLoggerFactory -extends SimpleLoggerFactory +class MavenFailLevelLoggerState Review comment: I guess GitHub messed up the diff, I can't explain the renaming otherwise. -- I like the name LogLevelRecorder, but currently it also holds state whether the threshold has been hit, so it might not fully describe it's intention. What do you think? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MNG-6770) Custom mojo changing project version but mavenSession doesn't get updated
[ https://issues.apache.org/jira/browse/MNG-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6770: - Issue Type: Wish (was: Bug) > Custom mojo changing project version but mavenSession doesn't get updated > -- > > Key: MNG-6770 > URL: https://issues.apache.org/jira/browse/MNG-6770 > Project: Maven > Issue Type: Wish >Reporter: Yuna Morgenstern >Priority: Minor > > I am using a custom maven plugin which helps me to preset the other plugins. > When I change my pom version (with > org.codehaus.mojo:versions-maven-plugin:2.7) > and execute the maven-deploy-plugin afterwords, than the plugin is getting my > old version from somewhere in the session. As I am unable to debug through, > it would be great if someone could help me to fix this issue. where are these > properties coming from: "artifact", "projectArtifact", "finalName" > "project.build.finalName", "attachedArtifacts"... > Every plugin seems to work fine except the maven-deploy-plugin which is using > the project version from somewhere. > After versioning, I am changing the project in the MavenProject session as > well without success of effect for the next plugin. The only way is currently > to run my plugin twice. one for deployment and before everything else. > My application is doing following in order: > * Cleaning > * Resolving Plugins & Dependencies > * Updates Plugins & Dependencies > * Updates Project Semantic Version > * Compiles Main & Test > * Builds Javadoc > * Builds Sources > * Builds Artifact file > * Signs files with GPG > * Tagging > * Deployment > Oh and I can't change the Settings xml data in the session, it doesn't have > an effect to the maven-deploy-plugin as well. seems that the deploy plugin > reads the settings file again. can I switch the settings file location in the > mavenSession somehow? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] MartinKanters commented on a change in pull request #287: [MNG-6065] - Log fail-level option.
MartinKanters commented on a change in pull request #287: [MNG-6065] - Log fail-level option. URL: https://github.com/apache/maven/pull/287#discussion_r351494913 ## File path: maven-slf4j-provider/src/main/java/org/slf4j/impl/MavenFailLevelLoggerState.java ## @@ -19,29 +19,32 @@ * under the License. */ -import org.slf4j.Logger; +import org.slf4j.event.Level; /** - * MavenSimpleLoggerFactory + * Responsible for keeping state of whether the threshold of the --fail-level flag has been hit. */ -public class MavenSimpleLoggerFactory -extends SimpleLoggerFactory +class MavenFailLevelLoggerState Review comment: I guess GitHub messed up the diff, I can't explain the renaming otherwise. -- I like the name LogLevelRecorder, but currently it also holds state whether the threshold has been hit, so it might not fully describe it's intention. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] MartinKanters commented on a change in pull request #287: [MNG-6065] - Log fail-level option.
MartinKanters commented on a change in pull request #287: [MNG-6065] - Log fail-level option. URL: https://github.com/apache/maven/pull/287#discussion_r351494913 ## File path: maven-slf4j-provider/src/main/java/org/slf4j/impl/MavenFailLevelLoggerState.java ## @@ -19,29 +19,32 @@ * under the License. */ -import org.slf4j.Logger; +import org.slf4j.event.Level; /** - * MavenSimpleLoggerFactory + * Responsible for keeping state of whether the threshold of the --fail-level flag has been hit. */ -public class MavenSimpleLoggerFactory -extends SimpleLoggerFactory +class MavenFailLevelLoggerState Review comment: I guess GitHub messed up the diff, I can't explain the renaming otherwise. -- I like the name LogLevelRecorder, but currently it also holds state whether the threshold has been hit, so it might not fully describe it's intention. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6793) Sharing local repo for dependencies and a separate local repo for project
[
https://issues.apache.org/jira/browse/MNG-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983897#comment-16983897
]
Karl Heinz Marbaise commented on MNG-6793:
--
The first thing is as Michal already suggested is to use a repository manager
during the build on your Jenkins will tremendously speed up the download of
artifacts. Furthermore why do you need to delete the local workspace? Yes might
safe some diskspace which is in 2019 not really an issue (or better should not
be). Now compare the costs for diskspace vs. build time (meaning feedback
time). Furthermore you should not do {{install}} in your build better would be
to use {{verfiy}}. If you consume the artifacts from your build you need to do
{{deploy}}.
Furthermore the local repository was never designed to be used by several
running processes (concurrent access). This would result in a rewrite of that
code (which is not easy). Furthermore the teams has several ideas for [Maven
4.X|https://cwiki.apache.org/confluence/display/MAVEN/Local+Repository+Separation].
> Sharing local repo for dependencies and a separate local repo for project
> -
>
> Key: MNG-6793
> URL: https://issues.apache.org/jira/browse/MNG-6793
> Project: Maven
> Issue Type: Wish
> Components: Bootstrap Build
>Reporter: Daniel Qian
>Priority: Minor
> Labels: features
>
> When I use Jenkins to build project I have to make each Job to use its own
> local repo (a local dir in the workspace) to prevent concurrent build error:
> {{withMaven(}}
> {{ mavenLocalRepo: '.local-m2-repo'}}
> {{) {}}
> {{ sh 'mvn clean install -P docker,integration-test'}}
> {{ }}}
> Besides, I have to cleanup workspace after build to save disk space.
> So every time the build starts it have to download all the dependencies and
> that really cost a lot of time.
> So I think it will be nice If maven could share a local repo for dependencies
> and a separate local repo for current built project.
> Then we can save time of download dependencies and also provide isolation to
> prevent concurrent build error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Moved] (MNGSITE-384) 30 min guide first command doesn't work in commandline windows
[
https://issues.apache.org/jira/browse/MNGSITE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise moved MNG-6796 to MNGSITE-384:
--
Key: MNGSITE-384 (was: MNG-6796)
Project: Maven Project Web Site (was: Maven)
> 30 min guide first command doesn't work in commandline windows
> --
>
> Key: MNGSITE-384
> URL: https://issues.apache.org/jira/browse/MNGSITE-384
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment: windows command line
>Reporter: Roman Korver
>Priority: Trivial
>
> I tried to walk through the 30 min guide:
> [https://maven.apache.org/guides/getting-started/index.html]
> And stumbled on an issue after entering the first ":generate" command
> # mvn -B archetype:generate \
> # -DarchetypeGroupId=org.apache.maven.archetypes \
> # -DgroupId=com.mycompany.app \
> # -DartifactId=my-app
> I entered it (without the numbers of course), in the windows command line.
> C:\Users\rkorver\Documents\GitHub\maven-practice>mvn -B archetype:generate \
> -DarchetypeGroupID=org.apache.maven.archetypes \ -DgroupID=com.mycompany.app
> \ -DartifactId=my-app
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.123 s
> [INFO] Finished at: 2019-10-28T16:30:18+01:00
> [INFO]
>
> [ERROR] The goal you specified requires a project to execute but there is no
> POM in this directory (C:\Users\rkorver\Documents\GitHub\maven-practice).
> Please verify you invoked Maven from the correct directory. -> [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/MissingProjectException
> (this ^ link is not helpful in this case)
>
> * This command, in the 5 min guide works fine however!
> mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DinteractiveMode=false
>
> A hint I found in one of my tries:
> [WARNING] Property groupId is missing. Add -DgroupId=someValue
> {color:#FF}[WARNING] Property package is missing. Add
> -Dpackage=someValue{color}
> {color:#172b4d}could that last one be the real issue?{color}
> {color:#172b4d}*As a* beginner user of Maven, {color}
> *Want* the beginner guide fixed
> *So* other beginner Maven users aren't unnecessarily frustrated.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] gastaldi commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module
gastaldi commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module URL: https://github.com/apache/maven/pull/162#issuecomment-559227659 Hi @rfscholte I'm afraid I won't have time to work on this anymore. I'm closing it for the time being. Thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] gastaldi closed pull request #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module
gastaldi closed pull request #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module URL: https://github.com/apache/maven/pull/162 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] rfscholte commented on a change in pull request #287: [MNG-6065] - Log fail-level option.
rfscholte commented on a change in pull request #287: [MNG-6065] - Log
fail-level option.
URL: https://github.com/apache/maven/pull/287#discussion_r351448177
##
File path:
maven-slf4j-provider/src/main/java/org/slf4j/impl/MavenFailLevelLoggerState.java
##
@@ -19,29 +19,32 @@
* under the License.
*/
-import org.slf4j.Logger;
+import org.slf4j.event.Level;
/**
- * MavenSimpleLoggerFactory
+ * Responsible for keeping state of whether the threshold of the --fail-level
flag has been hit.
*/
-public class MavenSimpleLoggerFactory
-extends SimpleLoggerFactory
+class MavenFailLevelLoggerState
{
-/**
- * Return an appropriate {@link MavenSimpleLogger} instance by name.
- */
-public Logger getLogger( String name )
+private final Level logThreshold;
+private boolean thresholdHit = false;
+
+MavenFailLevelLoggerState( Level logLevel )
{
-Logger simpleLogger = loggerMap.get( name );
-if ( simpleLogger != null )
-{
-return simpleLogger;
-}
-else
+assert logLevel != null;
+this.logThreshold = logLevel;
+}
+
+void recordLogLevel( Level logLevel )
Review comment:
maybe `record( Level logLevel)` is enough
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven] rfscholte commented on a change in pull request #287: [MNG-6065] - Log fail-level option.
rfscholte commented on a change in pull request #287: [MNG-6065] - Log
fail-level option.
URL: https://github.com/apache/maven/pull/287#discussion_r351447660
##
File path:
maven-slf4j-provider/src/main/java/org/slf4j/impl/MavenFailLevelLoggerState.java
##
@@ -19,29 +19,32 @@
* under the License.
*/
-import org.slf4j.Logger;
+import org.slf4j.event.Level;
/**
- * MavenSimpleLoggerFactory
+ * Responsible for keeping state of whether the threshold of the --fail-level
flag has been hit.
*/
-public class MavenSimpleLoggerFactory
-extends SimpleLoggerFactory
+class MavenFailLevelLoggerState
{
-/**
- * Return an appropriate {@link MavenSimpleLogger} instance by name.
- */
-public Logger getLogger( String name )
+private final Level logThreshold;
+private boolean thresholdHit = false;
+
+MavenFailLevelLoggerState( Level logLevel )
{
-Logger simpleLogger = loggerMap.get( name );
-if ( simpleLogger != null )
-{
-return simpleLogger;
-}
-else
+assert logLevel != null;
+this.logThreshold = logLevel;
+}
+
+void recordLogLevel( Level logLevel )
+{
+if ( !thresholdHit && logLevel.toInt() >= logThreshold.toInt() )
{
-Logger newInstance = new MavenSimpleLogger( name );
-Logger oldInstance = loggerMap.putIfAbsent( name, newInstance );
-return oldInstance == null ? newInstance : oldInstance;
+thresholdHit = true;
}
}
+
+boolean threwLogsOfBreakingLevel()
Review comment:
I can image that we need something more dynamic in the future, so I'd prefer
to pass the LogLevel here. And let's find a shorter method name (without threw).
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven] rfscholte commented on a change in pull request #287: [MNG-6065] - Log fail-level option.
rfscholte commented on a change in pull request #287: [MNG-6065] - Log fail-level option. URL: https://github.com/apache/maven/pull/287#discussion_r351443708 ## File path: apache-maven/src/test/java/org/slf4j/impl/MavenLoggerFactoryTest.java ## @@ -0,0 +1,99 @@ +package org.slf4j.impl; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.junit.Test; +import org.slf4j.Logger; + +import static org.hamcrest.CoreMatchers.instanceOf; +import static org.junit.Assert.*; Review comment: No wildcard imports please This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] rfscholte commented on a change in pull request #287: [MNG-6065] - Log fail-level option.
rfscholte commented on a change in pull request #287: [MNG-6065] - Log fail-level option. URL: https://github.com/apache/maven/pull/287#discussion_r351445265 ## File path: maven-slf4j-provider/src/main/java/org/slf4j/impl/MavenFailLevelLoggerState.java ## @@ -19,29 +19,32 @@ * under the License. */ -import org.slf4j.Logger; +import org.slf4j.event.Level; /** - * MavenSimpleLoggerFactory + * Responsible for keeping state of whether the threshold of the --fail-level flag has been hit. */ -public class MavenSimpleLoggerFactory -extends SimpleLoggerFactory +class MavenFailLevelLoggerState Review comment: Rename `MavenSimpleLoggerFactory` to `MavenFailLevelLoggerState`? That's weird, right? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] rfscholte commented on a change in pull request #287: [MNG-6065] - Log fail-level option.
rfscholte commented on a change in pull request #287: [MNG-6065] - Log fail-level option. URL: https://github.com/apache/maven/pull/287#discussion_r351446754 ## File path: maven-slf4j-provider/src/main/java/org/slf4j/impl/MavenFailLevelLoggerState.java ## @@ -19,29 +19,32 @@ * under the License. */ -import org.slf4j.Logger; +import org.slf4j.event.Level; /** - * MavenSimpleLoggerFactory + * Responsible for keeping state of whether the threshold of the --fail-level flag has been hit. */ -public class MavenSimpleLoggerFactory -extends SimpleLoggerFactory +class MavenFailLevelLoggerState Review comment: I don't see any Maven related code. How about renaming the class to `LogLevelRecorder`? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] rfscholte commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module
rfscholte commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module URL: https://github.com/apache/maven/pull/162#issuecomment-559204590 @gastaldi can you update your PR, we should be able to merge this soon. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559186761 no problem. Question: this change you have made includes also the name of method too? So when I see the native report in your JIRA description of the issue there is also the method. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] t-8ch commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
t-8ch commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559185351 @Tibor17 I just overrode the PR with a new patch. WDYT? If it looks ok, I'll add tests tomorrow. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 edited a comment on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559184403 Maybe keep this PR for the future motivation in SUREFIRE-1724 and open a new one for SUREFIRE-1727. oki? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559184403 Maybe keep this PR for the future motivation in SUREFIRE-1724 and open a new one PR for SUREFIRE-1727. oki? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 edited a comment on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559183371 @t-8ch I want to make sure that we are on the same line. Is Cucumber exotic hierarchy for you? If it is then we can make a workaround here and then a good and complex fix in SUREFIRE-1724. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 edited a comment on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559183371 @t-8ch I want to make sure that we are on the same line. Is Cucumber exotic hierarchy for you? If it is then we can make a workaround here and then a godd and complex fix in SUREFIRE-1724. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559183371 @t-8ch I want to make sure that we are on the same line. Is Cucumber exotic engine for you? If it is then we can make a workaround here and then a godd and complex fix in SUREFIRE-1724. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] t-8ch commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
t-8ch commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559182989 Ah, ok. This make sense. I'll try this tomorrow. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 edited a comment on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559181429 Now i know what you mean but this is the same in JUnit4. It works there. Suppose that the Runner of JUnit4 fails and the test constructor fails too. See the JUnit4Provider, there we fire an event with the only testFailed with class name but no method name. I think this would be the way. Maybe not nice but having the unit tests will guide us to make it better in SUREFIRE-1724. My guess with the workflow. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559181429 Now i know what you mean but this is the same in JUnit4. It works there. Suppose that the Runner of JUnit4 fails and the test constructor fails too. See the JUnit4Provider, there we fire an event with the only testFailed with class anme but no method name. I think this would be the way. Maybe not nice but having the unit tests will guide us to make it better in SUREFIRE-1724. My guess with the workflow. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] t-8ch commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
t-8ch commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559181197 I fear that even if we find a specific workaround for this one case by for example reporting it onto the class instead of the factory method this will break down as soon as more exotic test hierarchies are used. (Also I will have to read the ticket you linked) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] t-8ch commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
t-8ch commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559180407 @Tibor17 The problem is that currently there is no entity in surefire to report the error on. The error is generated by an container. But surefire only cares about errors from tests. Also it has no way of representing a test that does not belong to a class. So the idea was to first expose all containers to surefire and then allow the reporting of errors on them. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] t-8ch edited a comment on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
t-8ch edited a comment on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559180407 @Tibor17 The problem is that currently there is no entity in surefire to report the error on. The error is generated by a container. But surefire only cares about errors from tests. Also it has no way of representing a test that does not belong to a class. So the idea was to first expose all containers to surefire and then allow the reporting of errors on them. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] t-8ch commented on a change in pull request #257: [SUREFIRE-1727] junitplatform: handle all containers
t-8ch commented on a change in pull request #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#discussion_r351411023 ## File path: surefire-providers/surefire-junit-platform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java ## @@ -410,11 +410,19 @@ public void allDiscoveredTestsAreInvokedForNullArgument() InOrder inOrder = inOrder( runListener ); ArgumentCaptor report = ArgumentCaptor.forClass( SimpleReportEntry.class ); -inOrder.verify( runListener ) +inOrder.verify( runListener, times( 2 ) ) Review comment: The engine container. In theory one testplan can contain both the normal Jupiter engine and also the "Vintage" engine (which will execute Junit4 tests). Also more engines can be written by users. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559179089 @t-8ch but your requirement to support all engines is covered already in https://issues.apache.org/jira/browse/SUREFIRE-1724 I thought that you want to fix only `Failures during test template creation are ignored` as it is in JIRA. So now i do not know why we have another title in this PR with same Jira ID. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] t-8ch commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
t-8ch commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559178053 > Which containers are not class/method based? Do we have those in our integration tests? > If not, let's add those. All subclasses of `TestSource`. And I think in theory its possible to discover your tests and containers completely dynamically, without any backing source. > The `ReportEntry` does not have the terminology like class nor method. It has `getSourceName` and `getName`, so it can be really anything, any source, even a script or cucumber feature or spec. Ah, yes that makes sense. I somehow interpreted it as sourcefile This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on a change in pull request #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#discussion_r351409529 ## File path: surefire-providers/surefire-junit-platform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java ## @@ -410,11 +410,19 @@ public void allDiscoveredTestsAreInvokedForNullArgument() InOrder inOrder = inOrder( runListener ); ArgumentCaptor report = ArgumentCaptor.forClass( SimpleReportEntry.class ); -inOrder.verify( runListener ) +inOrder.verify( runListener, times( 2 ) ) .testSetStarting( report.capture() ); -Assertions.assertThat( report.getValue().getSourceName() ) + +SimpleReportEntry engine = report.getAllValues().get( 0 ); +Assertions.assertThat( engine.getSourceName() ) +.isEqualTo( "JUnit Jupiter" ); Review comment: Due to this we should chceck the XML reports. This may appear in the report and that's wrong because it is an engine and not a class. We have another issue for the Cucumber where the ReportEntry has to be updated. But still not sure if this is needed to transfer engine name in this issue we have here. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on a change in pull request #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#discussion_r351408327 ## File path: surefire-providers/surefire-junit-platform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java ## @@ -410,11 +410,19 @@ public void allDiscoveredTestsAreInvokedForNullArgument() InOrder inOrder = inOrder( runListener ); ArgumentCaptor report = ArgumentCaptor.forClass( SimpleReportEntry.class ); -inOrder.verify( runListener ) +inOrder.verify( runListener, times( 2 ) ) Review comment: What was the second call of `testSetStarting`? I just want to understand it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #257: WIP: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on issue #257: WIP: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559172902 The `ReportEntry` does not have the terminology like class nor method. It has `getSourceName` and `getName`, so it can be really anything, any source, even a script or cucumber feature or spec. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #257: WIP: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on issue #257: WIP: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559171408 Which containers are not class/method based? Do we have those in our integration tests? If not, let's add those. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #257: WIP: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on issue #257: WIP: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559169777 yes surefire will upgrade the ReportEntry with the container name(s) but i hope it is not mandatory in this PR. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] t-8ch commented on issue #257: WIP: [SUREFIRE-1727] junitplatform: handle all containers
t-8ch commented on issue #257: WIP: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559126535 It's more of a work in progress. Currently the reporting is weird, because surefire expects the all entries to be Class/Mathod based. This will need a policy decision whether surefire will change its internal APIs to be more generic or if there be a more complex mapping from Junit5 concepts to surefire entries. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-wagon] michael-o commented on issue #57: WAGON-567: support retry on server side errors
michael-o commented on issue #57: WAGON-567: support retry on server side errors URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-559119817 @ColinHebert Please have a look at https://github.com/apache/httpcomponents-client/pull/178. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1727) Failures during test template creation are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983594#comment-16983594
]
Thomas Weißschuh commented on SUREFIRE-1727:
[~tibordigana], good timing: https://github.com/apache/maven-surefire/pull/257
Its only feature so far is the handling of the full junit 5 container hierarchy.
I am not sure that the cause of this issue itself is actually fixed (so far).
Also I am not sure the integration tests will succeed, because they fail
mysteriously on my machine.
> Failures during test template creation are ignored
> --
>
> Key: SUREFIRE-1727
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M4
>Reporter: Thomas Weißschuh
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Junit5 allows dynamic creation of tests via {{ @TestTemplate }} and
> {{TestTemplateInvocationContextProvider}}.
> If the {{TestTemplateInvocationContextProvider}} fails with an exception
> itself or Junit itself rejects it then surefire still marks the test as
> successful.
> Both Intellij IDEA and the junit 5 console launcher mark the test method as
> failed.
> Examples:
> {code:java}
> package surefirebug;
> import java.util.stream.Stream;
> import org.junit.jupiter.api.extension.ExtensionContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContextProvider;
> public class FailingTestTemplateInvocationContextProvider
> implements TestTemplateInvocationContextProvider {
> @Override
> public boolean supportsTestTemplate(ExtensionContext context) {
> return true;
> }
> @Override
> public Stream
> provideTestTemplateInvocationContexts(
> ExtensionContext context) {
> //throw new IllegalStateException(""); // throw a custom exception
> return Stream.of(); // this will be rejected by Junit itself with a
> PreconditionViolationException
> }
> }
> {code}
> {code:java}
> package surefirebug;
> import org.junit.jupiter.api.TestTemplate;
> import org.junit.jupiter.api.extension.ExtendWith;
> @ExtendWith(FailingTestTemplateInvocationContextProvider.class)
> class DemonstrationTest {
> @TestTemplate
> void testOne() {
> System.out.println("testOne");
> }
> }
> {code}
> Display in surefire:
> {noformat}
> ...
> [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ amps-utils ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running surefirebug.DemonstrationTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> s - in surefirebug.DemonstrationTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Display in the console runner:
> {noformat}
> ╷
> ├─ JUnit Jupiter ✔
> │ └─ DemonstrationTest ✔
> │ └─ testOne() ✘ No supporting TestTemplateInvocationContextProvider
> provided an invocation context
> └─ JUnit Vintage ✔
> Failures (1):
> JUnit Jupiter:DemonstrationTest:testOne()
> MethodSource [className = 'surefirebug.DemonstrationTest', methodName =
> 'testOne', methodParameterTypes = '']
> => org.junit.platform.commons.PreconditionViolationException: No
> supporting TestTemplateInvocationContextProvider provided an invocation
> context
>
> org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.validateWasAtLeastInvokedOnce(TestTemplateTestDescriptor.java:142)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:108)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
>
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
>
>
[GitHub] [maven-surefire] sormuras commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
sormuras commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-559119518 Interesting small change set for that generalization. Did you check that reports still work with "all containers", especially those, that are not class/method based? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] t-8ch opened a new pull request #257: [SUREFIRE-1727] junitplatform: handle all containers
t-8ch opened a new pull request #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257 Junit 5 can nest test containers arbitrarily deep. They also do not have to relate to classes or methods. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (SUREFIRE-1727) Failures during test template creation are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983587#comment-16983587
]
Tibor Digana edited comment on SUREFIRE-1727 at 11/27/19 2:42 PM:
--
[~t-8ch]
Can you write a PR? This helps a lot. I am overloaded with job interviews,
preparation for them and cannot much concentrate on this.
was (Author: tibor17):
[~t-8ch]
Can you write a PR. This helps a lot? I am overloaded with job interviews,
preparation for them and cannot much concentrate on this.
> Failures during test template creation are ignored
> --
>
> Key: SUREFIRE-1727
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M4
>Reporter: Thomas Weißschuh
>Priority: Major
>
> Junit5 allows dynamic creation of tests via {{ @TestTemplate }} and
> {{TestTemplateInvocationContextProvider}}.
> If the {{TestTemplateInvocationContextProvider}} fails with an exception
> itself or Junit itself rejects it then surefire still marks the test as
> successful.
> Both Intellij IDEA and the junit 5 console launcher mark the test method as
> failed.
> Examples:
> {code:java}
> package surefirebug;
> import java.util.stream.Stream;
> import org.junit.jupiter.api.extension.ExtensionContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContextProvider;
> public class FailingTestTemplateInvocationContextProvider
> implements TestTemplateInvocationContextProvider {
> @Override
> public boolean supportsTestTemplate(ExtensionContext context) {
> return true;
> }
> @Override
> public Stream
> provideTestTemplateInvocationContexts(
> ExtensionContext context) {
> //throw new IllegalStateException(""); // throw a custom exception
> return Stream.of(); // this will be rejected by Junit itself with a
> PreconditionViolationException
> }
> }
> {code}
> {code:java}
> package surefirebug;
> import org.junit.jupiter.api.TestTemplate;
> import org.junit.jupiter.api.extension.ExtendWith;
> @ExtendWith(FailingTestTemplateInvocationContextProvider.class)
> class DemonstrationTest {
> @TestTemplate
> void testOne() {
> System.out.println("testOne");
> }
> }
> {code}
> Display in surefire:
> {noformat}
> ...
> [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ amps-utils ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running surefirebug.DemonstrationTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> s - in surefirebug.DemonstrationTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Display in the console runner:
> {noformat}
> ╷
> ├─ JUnit Jupiter ✔
> │ └─ DemonstrationTest ✔
> │ └─ testOne() ✘ No supporting TestTemplateInvocationContextProvider
> provided an invocation context
> └─ JUnit Vintage ✔
> Failures (1):
> JUnit Jupiter:DemonstrationTest:testOne()
> MethodSource [className = 'surefirebug.DemonstrationTest', methodName =
> 'testOne', methodParameterTypes = '']
> => org.junit.platform.commons.PreconditionViolationException: No
> supporting TestTemplateInvocationContextProvider provided an invocation
> context
>
> org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.validateWasAtLeastInvokedOnce(TestTemplateTestDescriptor.java:142)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:108)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
>
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
>
>
[jira] [Commented] (SUREFIRE-1727) Failures during test template creation are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983587#comment-16983587
]
Tibor Digana commented on SUREFIRE-1727:
[~t-8ch]
Can you write a PR. This helps a lot? I am overloaded with job interviews,
preparation for them and cannot much concentrate on this.
> Failures during test template creation are ignored
> --
>
> Key: SUREFIRE-1727
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M4
>Reporter: Thomas Weißschuh
>Priority: Major
>
> Junit5 allows dynamic creation of tests via {{ @TestTemplate }} and
> {{TestTemplateInvocationContextProvider}}.
> If the {{TestTemplateInvocationContextProvider}} fails with an exception
> itself or Junit itself rejects it then surefire still marks the test as
> successful.
> Both Intellij IDEA and the junit 5 console launcher mark the test method as
> failed.
> Examples:
> {code:java}
> package surefirebug;
> import java.util.stream.Stream;
> import org.junit.jupiter.api.extension.ExtensionContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContextProvider;
> public class FailingTestTemplateInvocationContextProvider
> implements TestTemplateInvocationContextProvider {
> @Override
> public boolean supportsTestTemplate(ExtensionContext context) {
> return true;
> }
> @Override
> public Stream
> provideTestTemplateInvocationContexts(
> ExtensionContext context) {
> //throw new IllegalStateException(""); // throw a custom exception
> return Stream.of(); // this will be rejected by Junit itself with a
> PreconditionViolationException
> }
> }
> {code}
> {code:java}
> package surefirebug;
> import org.junit.jupiter.api.TestTemplate;
> import org.junit.jupiter.api.extension.ExtendWith;
> @ExtendWith(FailingTestTemplateInvocationContextProvider.class)
> class DemonstrationTest {
> @TestTemplate
> void testOne() {
> System.out.println("testOne");
> }
> }
> {code}
> Display in surefire:
> {noformat}
> ...
> [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ amps-utils ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running surefirebug.DemonstrationTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> s - in surefirebug.DemonstrationTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Display in the console runner:
> {noformat}
> ╷
> ├─ JUnit Jupiter ✔
> │ └─ DemonstrationTest ✔
> │ └─ testOne() ✘ No supporting TestTemplateInvocationContextProvider
> provided an invocation context
> └─ JUnit Vintage ✔
> Failures (1):
> JUnit Jupiter:DemonstrationTest:testOne()
> MethodSource [className = 'surefirebug.DemonstrationTest', methodName =
> 'testOne', methodParameterTypes = '']
> => org.junit.platform.commons.PreconditionViolationException: No
> supporting TestTemplateInvocationContextProvider provided an invocation
> context
>
> org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.validateWasAtLeastInvokedOnce(TestTemplateTestDescriptor.java:142)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:108)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
>
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>[...]
> Test run finished after 40 ms
> [ 4 containers found ]
> [ 0 containers skipped]
> [ 4 containers started]
> [ 0
[jira] [Commented] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4
[
https://issues.apache.org/jira/browse/WAGON-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983580#comment-16983580
]
Michael Osipov commented on WAGON-568:
--
Brilliant, simply briliant, point 7 was missing in my equation. The server
waits here for 14 bytes.
I will need to reconsider the entire {{PUT}} retry handling. It completely
suffice to check whether the entity is repeatable before a new {{PUT}} is
issued. I will look into this next months. Again, thank you! See also WAGON-572.
> Fail to deploy on Sonatype OSS since maven 3.5.4
>
>
> Key: WAGON-568
> URL: https://issues.apache.org/jira/browse/WAGON-568
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.3
> Environment: 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14
> PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
> openjdk version "1.8.0_202"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)
>Reporter: Stephane Landelle
>Priority: Major
>
> I've been trying to release AsyncHttpClient for days and deployment was
> always super slow until it ultimately failed or completely stalled.
> The issue seems to be that maven-deploy-plugin wants to upload checksum
> files. I have no idea where those would come from, as far as I know, those
> are generated by the maven repository.
>
> {code:java}
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
> async-http-client-project ---
> Uploading to sonatype-nexus-staging:
> http://oss.sonatype.org/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom
> [WARNING] Failed to upload checksum
> org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom.sha1:
> null{code}
>
>
> For each actual file, maven-deploy-plugin tries to upload a sha1 and a md5
> files and this takes forever to ultimately fail.
> I tried upgrading plugins but nothing worked.
> I finally found [this
> ticket|[https://issues.sonatype.org/browse/OSSRH-43371?focusedCommentId=610865=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-610865]]
> against Sonatype OSS describing the exact same behavior and stating
> downgrading to maven 3.5.3 fixed the issue.
> Indeed, downgrading did the trick!
> I'm opening an issue here and not against OSS Sonatype as it looks like a
> maven regression to me.
> * maven 3.6.2: fails
> * maven 3.5.4: fails
> * maven 3.5.3: works like a charm
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4
[
https://issues.apache.org/jira/browse/WAGON-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983551#comment-16983551
]
Oleg Kalnichevski commented on WAGON-568:
-
[~michael-o] Basically the redirect handling of PUT requests is broken. This is
what happens:
# HttpWagon uses HttpClient to execute a PUT method with a content entity
backed by an InputStream
# HttpClient transmits`Content-Length: n` header, reads `n` bytes from the
source InputStream and writes them out into socket OutputStream
# The origin server reads `n` bytes of content and responds with status 303
# HttpClient passes the 303 response to HttpWagon (automatic redirect handling
is disabled)
# HttpWagon repeats the same request to the new location with the *same*
content entity backed by the *same* InputStream
# HttpClient transmits`Content-Length: n` header, reads -1 bytes from the
source InputStream and writes nothing to the socket OutputStream
# The origin server awaits `n` bytes of content that are never transmitted
# The message exchange is stuck
# Grief and sorrow.
Oleg
> Fail to deploy on Sonatype OSS since maven 3.5.4
>
>
> Key: WAGON-568
> URL: https://issues.apache.org/jira/browse/WAGON-568
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.3
> Environment: 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14
> PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
> openjdk version "1.8.0_202"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)
>Reporter: Stephane Landelle
>Priority: Major
>
> I've been trying to release AsyncHttpClient for days and deployment was
> always super slow until it ultimately failed or completely stalled.
> The issue seems to be that maven-deploy-plugin wants to upload checksum
> files. I have no idea where those would come from, as far as I know, those
> are generated by the maven repository.
>
> {code:java}
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
> async-http-client-project ---
> Uploading to sonatype-nexus-staging:
> http://oss.sonatype.org/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom
> [WARNING] Failed to upload checksum
> org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom.sha1:
> null{code}
>
>
> For each actual file, maven-deploy-plugin tries to upload a sha1 and a md5
> files and this takes forever to ultimately fail.
> I tried upgrading plugins but nothing worked.
> I finally found [this
> ticket|[https://issues.sonatype.org/browse/OSSRH-43371?focusedCommentId=610865=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-610865]]
> against Sonatype OSS describing the exact same behavior and stating
> downgrading to maven 3.5.3 fixed the issue.
> Indeed, downgrading did the trick!
> I'm opening an issue here and not against OSS Sonatype as it looks like a
> maven regression to me.
> * maven 3.6.2: fails
> * maven 3.5.4: fails
> * maven 3.5.3: works like a charm
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4
[
https://issues.apache.org/jira/browse/WAGON-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983517#comment-16983517
]
Michael Osipov commented on WAGON-568:
--
Well, the code has been there before I have engaged with the project, but my
best guesses are:
* One was unaware of the redirect strategy
* WebDAV {{PUT}} might fail if an intermediate collection is not present
There are a few bugs anyway, e.g, the auth info for the potentional location
might not be set at all.
To be honest, I consider throwing it away with the next major, rely solely on
HttpClient redirect strategy.
> Fail to deploy on Sonatype OSS since maven 3.5.4
>
>
> Key: WAGON-568
> URL: https://issues.apache.org/jira/browse/WAGON-568
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.3
> Environment: 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14
> PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
> openjdk version "1.8.0_202"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)
>Reporter: Stephane Landelle
>Priority: Major
>
> I've been trying to release AsyncHttpClient for days and deployment was
> always super slow until it ultimately failed or completely stalled.
> The issue seems to be that maven-deploy-plugin wants to upload checksum
> files. I have no idea where those would come from, as far as I know, those
> are generated by the maven repository.
>
> {code:java}
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
> async-http-client-project ---
> Uploading to sonatype-nexus-staging:
> http://oss.sonatype.org/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom
> [WARNING] Failed to upload checksum
> org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom.sha1:
> null{code}
>
>
> For each actual file, maven-deploy-plugin tries to upload a sha1 and a md5
> files and this takes forever to ultimately fail.
> I tried upgrading plugins but nothing worked.
> I finally found [this
> ticket|[https://issues.sonatype.org/browse/OSSRH-43371?focusedCommentId=610865=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-610865]]
> against Sonatype OSS describing the exact same behavior and stating
> downgrading to maven 3.5.3 fixed the issue.
> Indeed, downgrading did the trick!
> I'm opening an issue here and not against OSS Sonatype as it looks like a
> maven regression to me.
> * maven 3.6.2: fails
> * maven 3.5.4: fails
> * maven 3.5.3: works like a charm
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4
[
https://issues.apache.org/jira/browse/WAGON-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983495#comment-16983495
]
Oleg Kalnichevski commented on WAGON-568:
-
[~michael-o] I have an idea what is happening. I have a question first, though.
What is the reason HttpWagon implementations disable automatic redirect handing?
Oleg
> Fail to deploy on Sonatype OSS since maven 3.5.4
>
>
> Key: WAGON-568
> URL: https://issues.apache.org/jira/browse/WAGON-568
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.3
> Environment: 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14
> PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
> openjdk version "1.8.0_202"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)
>Reporter: Stephane Landelle
>Priority: Major
>
> I've been trying to release AsyncHttpClient for days and deployment was
> always super slow until it ultimately failed or completely stalled.
> The issue seems to be that maven-deploy-plugin wants to upload checksum
> files. I have no idea where those would come from, as far as I know, those
> are generated by the maven repository.
>
> {code:java}
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
> async-http-client-project ---
> Uploading to sonatype-nexus-staging:
> http://oss.sonatype.org/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom
> [WARNING] Failed to upload checksum
> org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom.sha1:
> null{code}
>
>
> For each actual file, maven-deploy-plugin tries to upload a sha1 and a md5
> files and this takes forever to ultimately fail.
> I tried upgrading plugins but nothing worked.
> I finally found [this
> ticket|[https://issues.sonatype.org/browse/OSSRH-43371?focusedCommentId=610865=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-610865]]
> against Sonatype OSS describing the exact same behavior and stating
> downgrading to maven 3.5.3 fixed the issue.
> Indeed, downgrading did the trick!
> I'm opening an issue here and not against OSS Sonatype as it looks like a
> maven regression to me.
> * maven 3.6.2: fails
> * maven 3.5.4: fails
> * maven 3.5.3: works like a charm
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1727) Failures during test template creation are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983453#comment-16983453
]
Thomas Weißschuh edited comment on SUREFIRE-1727 at 11/27/19 12:29 PM:
---
Also Junit 5 wraps everything in an engine container of which multiple may
exist. This is also currently discarded.
was (Author: t-8ch):
Also Junit 5 wraps everything in an engine container of which may exist
multiple. This is also currently discarded.
> Failures during test template creation are ignored
> --
>
> Key: SUREFIRE-1727
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M4
>Reporter: Thomas Weißschuh
>Priority: Major
>
> Junit5 allows dynamic creation of tests via {{ @TestTemplate }} and
> {{TestTemplateInvocationContextProvider}}.
> If the {{TestTemplateInvocationContextProvider}} fails with an exception
> itself or Junit itself rejects it then surefire still marks the test as
> successful.
> Both Intellij IDEA and the junit 5 console launcher mark the test method as
> failed.
> Examples:
> {code:java}
> package surefirebug;
> import java.util.stream.Stream;
> import org.junit.jupiter.api.extension.ExtensionContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContextProvider;
> public class FailingTestTemplateInvocationContextProvider
> implements TestTemplateInvocationContextProvider {
> @Override
> public boolean supportsTestTemplate(ExtensionContext context) {
> return true;
> }
> @Override
> public Stream
> provideTestTemplateInvocationContexts(
> ExtensionContext context) {
> //throw new IllegalStateException(""); // throw a custom exception
> return Stream.of(); // this will be rejected by Junit itself with a
> PreconditionViolationException
> }
> }
> {code}
> {code:java}
> package surefirebug;
> import org.junit.jupiter.api.TestTemplate;
> import org.junit.jupiter.api.extension.ExtendWith;
> @ExtendWith(FailingTestTemplateInvocationContextProvider.class)
> class DemonstrationTest {
> @TestTemplate
> void testOne() {
> System.out.println("testOne");
> }
> }
> {code}
> Display in surefire:
> {noformat}
> ...
> [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ amps-utils ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running surefirebug.DemonstrationTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> s - in surefirebug.DemonstrationTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Display in the console runner:
> {noformat}
> ╷
> ├─ JUnit Jupiter ✔
> │ └─ DemonstrationTest ✔
> │ └─ testOne() ✘ No supporting TestTemplateInvocationContextProvider
> provided an invocation context
> └─ JUnit Vintage ✔
> Failures (1):
> JUnit Jupiter:DemonstrationTest:testOne()
> MethodSource [className = 'surefirebug.DemonstrationTest', methodName =
> 'testOne', methodParameterTypes = '']
> => org.junit.platform.commons.PreconditionViolationException: No
> supporting TestTemplateInvocationContextProvider provided an invocation
> context
>
> org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.validateWasAtLeastInvokedOnce(TestTemplateTestDescriptor.java:142)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:108)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
>
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
[jira] [Commented] (SUREFIRE-1727) Failures during test template creation are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983453#comment-16983453
]
Thomas Weißschuh commented on SUREFIRE-1727:
Also Junit 5 wraps everything in an engine container of which may exist
multiple. This is also currently discarded.
> Failures during test template creation are ignored
> --
>
> Key: SUREFIRE-1727
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M4
>Reporter: Thomas Weißschuh
>Priority: Major
>
> Junit5 allows dynamic creation of tests via {{ @TestTemplate }} and
> {{TestTemplateInvocationContextProvider}}.
> If the {{TestTemplateInvocationContextProvider}} fails with an exception
> itself or Junit itself rejects it then surefire still marks the test as
> successful.
> Both Intellij IDEA and the junit 5 console launcher mark the test method as
> failed.
> Examples:
> {code:java}
> package surefirebug;
> import java.util.stream.Stream;
> import org.junit.jupiter.api.extension.ExtensionContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContextProvider;
> public class FailingTestTemplateInvocationContextProvider
> implements TestTemplateInvocationContextProvider {
> @Override
> public boolean supportsTestTemplate(ExtensionContext context) {
> return true;
> }
> @Override
> public Stream
> provideTestTemplateInvocationContexts(
> ExtensionContext context) {
> //throw new IllegalStateException(""); // throw a custom exception
> return Stream.of(); // this will be rejected by Junit itself with a
> PreconditionViolationException
> }
> }
> {code}
> {code:java}
> package surefirebug;
> import org.junit.jupiter.api.TestTemplate;
> import org.junit.jupiter.api.extension.ExtendWith;
> @ExtendWith(FailingTestTemplateInvocationContextProvider.class)
> class DemonstrationTest {
> @TestTemplate
> void testOne() {
> System.out.println("testOne");
> }
> }
> {code}
> Display in surefire:
> {noformat}
> ...
> [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ amps-utils ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running surefirebug.DemonstrationTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> s - in surefirebug.DemonstrationTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Display in the console runner:
> {noformat}
> ╷
> ├─ JUnit Jupiter ✔
> │ └─ DemonstrationTest ✔
> │ └─ testOne() ✘ No supporting TestTemplateInvocationContextProvider
> provided an invocation context
> └─ JUnit Vintage ✔
> Failures (1):
> JUnit Jupiter:DemonstrationTest:testOne()
> MethodSource [className = 'surefirebug.DemonstrationTest', methodName =
> 'testOne', methodParameterTypes = '']
> => org.junit.platform.commons.PreconditionViolationException: No
> supporting TestTemplateInvocationContextProvider provided an invocation
> context
>
> org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.validateWasAtLeastInvokedOnce(TestTemplateTestDescriptor.java:142)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:108)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
>
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>[...]
> Test run finished after 40 ms
> [ 4 containers found ]
> [ 0 containers skipped]
> [ 4 containers started]
> [ 0 containers
[jira] [Commented] (SUREFIRE-1727) Failures during test template creation are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983441#comment-16983441
]
Thomas Weißschuh commented on SUREFIRE-1727:
Here is a demonstrator: https://github.com/t-8ch/SUREFIRE-1727-demonstrator
> Failures during test template creation are ignored
> --
>
> Key: SUREFIRE-1727
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M4
>Reporter: Thomas Weißschuh
>Priority: Major
>
> Junit5 allows dynamic creation of tests via {{ @TestTemplate }} and
> {{TestTemplateInvocationContextProvider}}.
> If the {{TestTemplateInvocationContextProvider}} fails with an exception
> itself or Junit itself rejects it then surefire still marks the test as
> successful.
> Both Intellij IDEA and the junit 5 console launcher mark the test method as
> failed.
> Examples:
> {code:java}
> package surefirebug;
> import java.util.stream.Stream;
> import org.junit.jupiter.api.extension.ExtensionContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContextProvider;
> public class FailingTestTemplateInvocationContextProvider
> implements TestTemplateInvocationContextProvider {
> @Override
> public boolean supportsTestTemplate(ExtensionContext context) {
> return true;
> }
> @Override
> public Stream
> provideTestTemplateInvocationContexts(
> ExtensionContext context) {
> //throw new IllegalStateException(""); // throw a custom exception
> return Stream.of(); // this will be rejected by Junit itself with a
> PreconditionViolationException
> }
> }
> {code}
> {code:java}
> package surefirebug;
> import org.junit.jupiter.api.TestTemplate;
> import org.junit.jupiter.api.extension.ExtendWith;
> @ExtendWith(FailingTestTemplateInvocationContextProvider.class)
> class DemonstrationTest {
> @TestTemplate
> void testOne() {
> System.out.println("testOne");
> }
> }
> {code}
> Display in surefire:
> {noformat}
> ...
> [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ amps-utils ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running surefirebug.DemonstrationTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> s - in surefirebug.DemonstrationTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Display in the console runner:
> {noformat}
> ╷
> ├─ JUnit Jupiter ✔
> │ └─ DemonstrationTest ✔
> │ └─ testOne() ✘ No supporting TestTemplateInvocationContextProvider
> provided an invocation context
> └─ JUnit Vintage ✔
> Failures (1):
> JUnit Jupiter:DemonstrationTest:testOne()
> MethodSource [className = 'surefirebug.DemonstrationTest', methodName =
> 'testOne', methodParameterTypes = '']
> => org.junit.platform.commons.PreconditionViolationException: No
> supporting TestTemplateInvocationContextProvider provided an invocation
> context
>
> org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.validateWasAtLeastInvokedOnce(TestTemplateTestDescriptor.java:142)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:108)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
>
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>[...]
> Test run finished after 40 ms
> [ 4 containers found ]
> [ 0 containers skipped]
> [ 4 containers started]
> [ 0 containers aborted]
> [ 3 containers
[jira] [Commented] (SUREFIRE-1727) Failures during test template creation are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983429#comment-16983429
]
Thomas Weißschuh commented on SUREFIRE-1727:
The first comment was about whether the following sequence of events for a
given RunListener is legal:
* testSetStarting(containerA)
* testSetStarting(containerBinA)
* testSetStarting(containerCinBinA)
* testSucceed()/testError()/testSkipped() ...
* testSetComplete(containerCinBinA)
* testSetComplete(containerBinA)
* testSetComplete(containerA)
Will the rest of surefire handle this fine and will the generated report still
be valid?
> Failures during test template creation are ignored
> --
>
> Key: SUREFIRE-1727
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M4
>Reporter: Thomas Weißschuh
>Priority: Major
>
> Junit5 allows dynamic creation of tests via {{ @TestTemplate }} and
> {{TestTemplateInvocationContextProvider}}.
> If the {{TestTemplateInvocationContextProvider}} fails with an exception
> itself or Junit itself rejects it then surefire still marks the test as
> successful.
> Both Intellij IDEA and the junit 5 console launcher mark the test method as
> failed.
> Examples:
> {code:java}
> package surefirebug;
> import java.util.stream.Stream;
> import org.junit.jupiter.api.extension.ExtensionContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContextProvider;
> public class FailingTestTemplateInvocationContextProvider
> implements TestTemplateInvocationContextProvider {
> @Override
> public boolean supportsTestTemplate(ExtensionContext context) {
> return true;
> }
> @Override
> public Stream
> provideTestTemplateInvocationContexts(
> ExtensionContext context) {
> //throw new IllegalStateException(""); // throw a custom exception
> return Stream.of(); // this will be rejected by Junit itself with a
> PreconditionViolationException
> }
> }
> {code}
> {code:java}
> package surefirebug;
> import org.junit.jupiter.api.TestTemplate;
> import org.junit.jupiter.api.extension.ExtendWith;
> @ExtendWith(FailingTestTemplateInvocationContextProvider.class)
> class DemonstrationTest {
> @TestTemplate
> void testOne() {
> System.out.println("testOne");
> }
> }
> {code}
> Display in surefire:
> {noformat}
> ...
> [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ amps-utils ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running surefirebug.DemonstrationTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> s - in surefirebug.DemonstrationTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Display in the console runner:
> {noformat}
> ╷
> ├─ JUnit Jupiter ✔
> │ └─ DemonstrationTest ✔
> │ └─ testOne() ✘ No supporting TestTemplateInvocationContextProvider
> provided an invocation context
> └─ JUnit Vintage ✔
> Failures (1):
> JUnit Jupiter:DemonstrationTest:testOne()
> MethodSource [className = 'surefirebug.DemonstrationTest', methodName =
> 'testOne', methodParameterTypes = '']
> => org.junit.platform.commons.PreconditionViolationException: No
> supporting TestTemplateInvocationContextProvider provided an invocation
> context
>
> org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.validateWasAtLeastInvokedOnce(TestTemplateTestDescriptor.java:142)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:108)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
>
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
>
>
[jira] [Commented] (SUREFIRE-1727) Failures during test template creation are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983398#comment-16983398
]
Tibor Digana commented on SUREFIRE-1727:
[~t-8ch]
I understand your second comment but I do not understand your first comment
with nested TestSetReportEntry. How did you mean that?
Do you mean that {{runListener.testSetCompleted()}} is called when it is a
class? That's probably the issue.
Pls bundle all files (POM, sources) so that I would be able to execute your
project and i will better debug the adapter class. Thx
> Failures during test template creation are ignored
> --
>
> Key: SUREFIRE-1727
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M4
>Reporter: Thomas Weißschuh
>Priority: Major
>
> Junit5 allows dynamic creation of tests via {{ @TestTemplate }} and
> {{TestTemplateInvocationContextProvider}}.
> If the {{TestTemplateInvocationContextProvider}} fails with an exception
> itself or Junit itself rejects it then surefire still marks the test as
> successful.
> Both Intellij IDEA and the junit 5 console launcher mark the test method as
> failed.
> Examples:
> {code:java}
> package surefirebug;
> import java.util.stream.Stream;
> import org.junit.jupiter.api.extension.ExtensionContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContextProvider;
> public class FailingTestTemplateInvocationContextProvider
> implements TestTemplateInvocationContextProvider {
> @Override
> public boolean supportsTestTemplate(ExtensionContext context) {
> return true;
> }
> @Override
> public Stream
> provideTestTemplateInvocationContexts(
> ExtensionContext context) {
> //throw new IllegalStateException(""); // throw a custom exception
> return Stream.of(); // this will be rejected by Junit itself with a
> PreconditionViolationException
> }
> }
> {code}
> {code:java}
> package surefirebug;
> import org.junit.jupiter.api.TestTemplate;
> import org.junit.jupiter.api.extension.ExtendWith;
> @ExtendWith(FailingTestTemplateInvocationContextProvider.class)
> class DemonstrationTest {
> @TestTemplate
> void testOne() {
> System.out.println("testOne");
> }
> }
> {code}
> Display in surefire:
> {noformat}
> ...
> [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ amps-utils ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running surefirebug.DemonstrationTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> s - in surefirebug.DemonstrationTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Display in the console runner:
> {noformat}
> ╷
> ├─ JUnit Jupiter ✔
> │ └─ DemonstrationTest ✔
> │ └─ testOne() ✘ No supporting TestTemplateInvocationContextProvider
> provided an invocation context
> └─ JUnit Vintage ✔
> Failures (1):
> JUnit Jupiter:DemonstrationTest:testOne()
> MethodSource [className = 'surefirebug.DemonstrationTest', methodName =
> 'testOne', methodParameterTypes = '']
> => org.junit.platform.commons.PreconditionViolationException: No
> supporting TestTemplateInvocationContextProvider provided an invocation
> context
>
> org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.validateWasAtLeastInvokedOnce(TestTemplateTestDescriptor.java:142)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:108)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
>
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
>
>
[jira] [Commented] (SUREFIRE-1727) Failures during test template creation are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983346#comment-16983346
]
Thomas Weißschuh commented on SUREFIRE-1727:
Note (to myself): it should also handle nodes that are "Type.CONTAINER_AND_TEST"
> Failures during test template creation are ignored
> --
>
> Key: SUREFIRE-1727
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M4
>Reporter: Thomas Weißschuh
>Priority: Major
>
> Junit5 allows dynamic creation of tests via {{ @TestTemplate }} and
> {{TestTemplateInvocationContextProvider}}.
> If the {{TestTemplateInvocationContextProvider}} fails with an exception
> itself or Junit itself rejects it then surefire still marks the test as
> successful.
> Both Intellij IDEA and the junit 5 console launcher mark the test method as
> failed.
> Examples:
> {code:java}
> package surefirebug;
> import java.util.stream.Stream;
> import org.junit.jupiter.api.extension.ExtensionContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContextProvider;
> public class FailingTestTemplateInvocationContextProvider
> implements TestTemplateInvocationContextProvider {
> @Override
> public boolean supportsTestTemplate(ExtensionContext context) {
> return true;
> }
> @Override
> public Stream
> provideTestTemplateInvocationContexts(
> ExtensionContext context) {
> //throw new IllegalStateException(""); // throw a custom exception
> return Stream.of(); // this will be rejected by Junit itself with a
> PreconditionViolationException
> }
> }
> {code}
> {code:java}
> package surefirebug;
> import org.junit.jupiter.api.TestTemplate;
> import org.junit.jupiter.api.extension.ExtendWith;
> @ExtendWith(FailingTestTemplateInvocationContextProvider.class)
> class DemonstrationTest {
> @TestTemplate
> void testOne() {
> System.out.println("testOne");
> }
> }
> {code}
> Display in surefire:
> {noformat}
> ...
> [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ amps-utils ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running surefirebug.DemonstrationTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> s - in surefirebug.DemonstrationTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Display in the console runner:
> {noformat}
> ╷
> ├─ JUnit Jupiter ✔
> │ └─ DemonstrationTest ✔
> │ └─ testOne() ✘ No supporting TestTemplateInvocationContextProvider
> provided an invocation context
> └─ JUnit Vintage ✔
> Failures (1):
> JUnit Jupiter:DemonstrationTest:testOne()
> MethodSource [className = 'surefirebug.DemonstrationTest', methodName =
> 'testOne', methodParameterTypes = '']
> => org.junit.platform.commons.PreconditionViolationException: No
> supporting TestTemplateInvocationContextProvider provided an invocation
> context
>
> org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.validateWasAtLeastInvokedOnce(TestTemplateTestDescriptor.java:142)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:108)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
>
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>[...]
> Test run finished after 40 ms
> [ 4 containers found ]
> [ 0 containers skipped]
> [ 4 containers started]
> [ 0 containers aborted]
> [ 3 containers
[jira] [Commented] (SUREFIRE-1727) Failures during test template creation are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983343#comment-16983343
]
Thomas Weißschuh commented on SUREFIRE-1727:
Can {{TestSetReportEntry}}s be nested?
Then it would make most sense to map Junit 5 containers 1:1 to
{{TestSetReportEntry}} and Junit 5 tests to normal {{TestReportEntry}}.
If it will get fairly ugly, because Junit5 can really have arbitrarily nested
containers that do not have to have any relation to Classes at all.
> Failures during test template creation are ignored
> --
>
> Key: SUREFIRE-1727
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M4
>Reporter: Thomas Weißschuh
>Priority: Major
>
> Junit5 allows dynamic creation of tests via {{ @TestTemplate }} and
> {{TestTemplateInvocationContextProvider}}.
> If the {{TestTemplateInvocationContextProvider}} fails with an exception
> itself or Junit itself rejects it then surefire still marks the test as
> successful.
> Both Intellij IDEA and the junit 5 console launcher mark the test method as
> failed.
> Examples:
> {code:java}
> package surefirebug;
> import java.util.stream.Stream;
> import org.junit.jupiter.api.extension.ExtensionContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContextProvider;
> public class FailingTestTemplateInvocationContextProvider
> implements TestTemplateInvocationContextProvider {
> @Override
> public boolean supportsTestTemplate(ExtensionContext context) {
> return true;
> }
> @Override
> public Stream
> provideTestTemplateInvocationContexts(
> ExtensionContext context) {
> //throw new IllegalStateException(""); // throw a custom exception
> return Stream.of(); // this will be rejected by Junit itself with a
> PreconditionViolationException
> }
> }
> {code}
> {code:java}
> package surefirebug;
> import org.junit.jupiter.api.TestTemplate;
> import org.junit.jupiter.api.extension.ExtendWith;
> @ExtendWith(FailingTestTemplateInvocationContextProvider.class)
> class DemonstrationTest {
> @TestTemplate
> void testOne() {
> System.out.println("testOne");
> }
> }
> {code}
> Display in surefire:
> {noformat}
> ...
> [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ amps-utils ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running surefirebug.DemonstrationTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> s - in surefirebug.DemonstrationTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Display in the console runner:
> {noformat}
> ╷
> ├─ JUnit Jupiter ✔
> │ └─ DemonstrationTest ✔
> │ └─ testOne() ✘ No supporting TestTemplateInvocationContextProvider
> provided an invocation context
> └─ JUnit Vintage ✔
> Failures (1):
> JUnit Jupiter:DemonstrationTest:testOne()
> MethodSource [className = 'surefirebug.DemonstrationTest', methodName =
> 'testOne', methodParameterTypes = '']
> => org.junit.platform.commons.PreconditionViolationException: No
> supporting TestTemplateInvocationContextProvider provided an invocation
> context
>
> org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.validateWasAtLeastInvokedOnce(TestTemplateTestDescriptor.java:142)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:108)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
>
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
>
>
[GitHub] [maven-wagon] michael-o commented on issue #61: Fix cast exception, when the server returns an xml containing a newli…
michael-o commented on issue #61: Fix cast exception, when the server returns an xml containing a newli… URL: https://github.com/apache/maven-wagon/pull/61#issuecomment-55932 I do not even understand the problem here. Can you at least elaborate? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983293#comment-16983293 ] Hudson commented on MNG-6399: - Build succeeded in Jenkins: Maven TLP » maven » master #312 See https://builds.apache.org/job/maven-box/job/maven/job/master/312/ > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.7.0 > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1726) @AfterAll JUnit5 methods from extensions are not called when a test is rerun
[ https://issues.apache.org/jira/browse/SUREFIRE-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol closed SUREFIRE-1726. Resolution: Invalid Closing since this issue was wrongly created. I thought AfterAll wasn't called but I was wrong. It is called correctly. The issue is elsewhere in our own code. Sorry for the trouble. Thanks > @AfterAll JUnit5 methods from extensions are not called when a test is rerun > > > Key: SUREFIRE-1726 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1726 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Affects Versions: 3.0.0-M4 >Reporter: Vincent Massol >Priority: Major > > I'm testing the rerun feature with the failsafe plugin (with > -Dfailsafe.rerunFailingTestsCount=2) and I've noticed that my failing tests > that are executed again don't have the @AfterAll method of the extension they > use executed again. However the extension's @BeforeAll methods are correctly > called during the reruns. -- This message was sent by Atlassian Jira (v8.3.4#803005)
