[jira] [Closed] (MCOMPILER-413) Parameters does not work when only release is specified
[
https://issues.apache.org/jira/browse/MCOMPILER-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-413.
Fix Version/s: 3.9.0
Assignee: Robert Scholte
Resolution: Fixed
> Parameters does not work when only release is specified
> ---
>
> Key: MCOMPILER-413
> URL: https://issues.apache.org/jira/browse/MCOMPILER-413
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Arch Linux, OpenJDK 11.0.6.u10, Maven 3.6.3
>Reporter: Jiri Kraml
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.9.0
>
>
> Compiling a project with the following maven-compiler-plugin configuration
> does not produce parameter name metadata in the class files:
> {{<{color:#0033b3}configuration{color}>}}
> {{ <{color:#0033b3}release{color}>9}}
> {{
> <{color:#0033b3}parameters{color}>true}}
> {{}}
> I believe this is a mistake, because
> {{javac --release 9 -parameters Test.java}}
> will produce the metadata.
> This behavior is due to dependency
> {{org.codehaus.plexus:plexus-compiler-javac:2.8.4}}, where in
> {{org.codehaus.plexus.compiler.javac.JavacCompiler}}, line 312, the function
> {{isPreJava18}} is called. This function does not evaluate the release
> property, only source and compilerVersion.
> Available workarounds in {{pom.xml}} are additionally specifying {{source}}
> or explicitly specifying the {{-parameters}} parameter in the plugin
> configuration.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481623#comment-17481623
]
Robert Scholte commented on MCOMPILER-481:
--
{quote}Shouldn't we automatically add test dependencies coming from the pom in
module-path for test?{quote}
No, that would mean that for instance junit ends up on the modulepath, that
doesn't make sense.
Only jars that are used by both compile and test should be added to the
modulepath.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class
[GitHub] [maven-archetypes] slawekjaranowski commented on pull request #6: Bump web archetype deployment descriptor to v4, portlet to v3
slawekjaranowski commented on pull request #6: URL: https://github.com/apache/maven-archetypes/pull/6#issuecomment-1020893574 Please create jira issue for 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7397) Expose getPluginDescriptor
[
https://issues.apache.org/jira/browse/MNG-7397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MNG-7397:
-
Labels: mng-missing-apis (was: )
> Expose getPluginDescriptor
> --
>
> Key: MNG-7397
> URL: https://issues.apache.org/jira/browse/MNG-7397
> Project: Maven
> Issue Type: Task
> Components: Core
>Reporter: Tamás Cservenák
>Priority: Major
> Labels: mng-missing-apis
>
> Invoking
> {{maven-core:org.apache.maven.plugin.MavenPluginManager#getPluginDescriptor}}
> method is not possible without using Maven Resolver classes
> (RemoteRepository, RepositorySystemSession). It should be encapsulated into
> some method like: {{PluginDescriptor getPluginDescriptor( Plugin plugin,
> MavenSession session )}} .
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481495#comment-17481495
]
Olivier Lamy edited comment on MCOMPILER-481 at 1/25/22, 7:35 AM:
--
I find it strange we almost do not read anything from pom regarding (test?)
dependencies.
Shouldn't we automatically add test dependencies coming from the pom in
module-path for test?
not sure including static should be limited to test compilation only. If you
look at the provided test project. not included static will fail compilation as
there is
requires static org.eclipse.jetty.util.ajax
and the dependency is marked as optional
but it's required for compilation.
was (Author: olamy):
I find it strange we almost do not read anything from pom regarding (test?)
dependencies.
Shouldn't we automatically add test dependencies coming from the pom in
module-path for test?
not sure including static should be limited to test compilation only. If you
look at the provided test project. not included static will fail compilation as
there is
requires static org.eclipse.jetty.util.ajax
and the dependency is marked as optional
but it's required for compilation.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
[GitHub] [maven-reporting-exec] slawekjaranowski commented on pull request #9: Fix Maven site build
slawekjaranowski commented on pull request #9: URL: https://github.com/apache/maven-reporting-exec/pull/9#issuecomment-1020889625 I didn't investigate so mach it - probably there is problem with some old dependencies or plugins used in IT tests. As I wrote I will wait for your PR ... maybe it resolve it. I want to merge it and wait for your changes. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7397) Expose getPluginDescriptor
Tamás Cservenák created MNG-7397:
Summary: Expose getPluginDescriptor
Key: MNG-7397
URL: https://issues.apache.org/jira/browse/MNG-7397
Project: Maven
Issue Type: Task
Components: Core
Reporter: Tamás Cservenák
Invoking
{{maven-core:org.apache.maven.plugin.MavenPluginManager#getPluginDescriptor}}
method is not possible without using Maven Resolver classes (RemoteRepository,
RepositorySystemSession). It should be encapsulated into some method like:
{{PluginDescriptor getPluginDescriptor( Plugin plugin, MavenSession session )}}
.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-reporting-exec] cstamas commented on pull request #9: Fix Maven site build
cstamas commented on pull request #9: URL: https://github.com/apache/maven-reporting-exec/pull/9#issuecomment-1020880649 There are still some issues in 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1029) Update plugin (requires Maven 3.2.5+)
[ https://issues.apache.org/jira/browse/MSHARED-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481599#comment-17481599 ] ASF GitHub Bot commented on MSHARED-1029: - cstamas commented on a change in pull request #8: URL: https://github.com/apache/maven-reporting-exec/pull/8#discussion_r791414031 ## File path: src/main/java/org/apache/maven/reporting/exec/DefaultMavenPluginManagerHelper.java ## @@ -34,6 +32,10 @@ import org.codehaus.plexus.component.annotations.Component; import org.codehaus.plexus.component.annotations.Requirement; import org.codehaus.plexus.logging.Logger; +import org.eclipse.aether.RepositorySystemSession; +import org.eclipse.aether.graph.DependencyFilter; +import org.eclipse.aether.repository.RemoteRepository; +import org.eclipse.aether.util.filter.ExclusionsDependencyFilter; Review comment: Yes, let's collect "missing APIs", agreed. OTOH, this PR is to "up component maven dep to maven 3.2.x", that does not provide those. IMHO, we could start collecting and providing them in Maven 4.x line (or even maybe Maven 3.9.x line), and when we start doing plugins 4.x line (like we did with plugins 3.x that were aligned with Maven 3.x), then we could move all plugins to newly published APIs... Created page https://cwiki.apache.org/confluence/display/MAVEN/Maven+Missing+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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update plugin (requires Maven 3.2.5+) > - > > Key: MSHARED-1029 > URL: https://issues.apache.org/jira/browse/MSHARED-1029 > Project: Maven Shared Components > Issue Type: Task > Components: maven-reporting-exec >Reporter: Tamás Cservenák >Priority: Major > > Drop Maven 3.1 and 3.0 support (to get rid of Sonatype Aether), align with > other components. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-reporting-exec] cstamas commented on a change in pull request #8: [MSHARED-1029] Drop support for maven below 3.2.x
cstamas commented on a change in pull request #8: URL: https://github.com/apache/maven-reporting-exec/pull/8#discussion_r791414031 ## File path: src/main/java/org/apache/maven/reporting/exec/DefaultMavenPluginManagerHelper.java ## @@ -34,6 +32,10 @@ import org.codehaus.plexus.component.annotations.Component; import org.codehaus.plexus.component.annotations.Requirement; import org.codehaus.plexus.logging.Logger; +import org.eclipse.aether.RepositorySystemSession; +import org.eclipse.aether.graph.DependencyFilter; +import org.eclipse.aether.repository.RemoteRepository; +import org.eclipse.aether.util.filter.ExclusionsDependencyFilter; Review comment: Yes, let's collect "missing APIs", agreed. OTOH, this PR is to "up component maven dep to maven 3.2.x", that does not provide those. IMHO, we could start collecting and providing them in Maven 4.x line (or even maybe Maven 3.9.x line), and when we start doing plugins 4.x line (like we did with plugins 3.x that were aligned with Maven 3.x), then we could move all plugins to newly published APIs... Created page https://cwiki.apache.org/confluence/display/MAVEN/Maven+Missing+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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1029) Update plugin (requires Maven 3.2.5+)
[ https://issues.apache.org/jira/browse/MSHARED-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481591#comment-17481591 ] ASF GitHub Bot commented on MSHARED-1029: - cstamas commented on a change in pull request #8: URL: https://github.com/apache/maven-reporting-exec/pull/8#discussion_r791409204 ## File path: src/main/java/org/apache/maven/reporting/exec/DefaultMavenPluginManagerHelper.java ## @@ -48,134 +50,20 @@ @Requirement protected MavenPluginManager mavenPluginManager; Review comment: I wanted to keep changes focused (drop sonatype aether). I would rather do a second PR that does plexus -> ATInject move... -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update plugin (requires Maven 3.2.5+) > - > > Key: MSHARED-1029 > URL: https://issues.apache.org/jira/browse/MSHARED-1029 > Project: Maven Shared Components > Issue Type: Task > Components: maven-reporting-exec >Reporter: Tamás Cservenák >Priority: Major > > Drop Maven 3.1 and 3.0 support (to get rid of Sonatype Aether), align with > other components. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-reporting-exec] cstamas commented on a change in pull request #8: [MSHARED-1029] Drop support for maven below 3.2.x
cstamas commented on a change in pull request #8: URL: https://github.com/apache/maven-reporting-exec/pull/8#discussion_r791409204 ## File path: src/main/java/org/apache/maven/reporting/exec/DefaultMavenPluginManagerHelper.java ## @@ -48,134 +50,20 @@ @Requirement protected MavenPluginManager mavenPluginManager; Review comment: I wanted to keep changes focused (drop sonatype aether). I would rather do a second PR that does plexus -> ATInject move... -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1029) Update plugin (requires Maven 3.2.5+)
[ https://issues.apache.org/jira/browse/MSHARED-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481589#comment-17481589 ] ASF GitHub Bot commented on MSHARED-1029: - cstamas commented on a change in pull request #8: URL: https://github.com/apache/maven-reporting-exec/pull/8#discussion_r791408768 ## File path: pom.xml ## @@ -170,7 +145,13 @@ junit junit - 4.13.1 + 4.13.2 + test + + + org.slf4j + slf4j-simple + 1.7.32 Review comment: These are all "test" scoped deps, so they matter "locally" only, so IMHO does not matter. We can align them (by same logic as resolver, so "use version maven X used"), but putting them into parent is overkill IMO. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update plugin (requires Maven 3.2.5+) > - > > Key: MSHARED-1029 > URL: https://issues.apache.org/jira/browse/MSHARED-1029 > Project: Maven Shared Components > Issue Type: Task > Components: maven-reporting-exec >Reporter: Tamás Cservenák >Priority: Major > > Drop Maven 3.1 and 3.0 support (to get rid of Sonatype Aether), align with > other components. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-reporting-exec] cstamas commented on a change in pull request #8: [MSHARED-1029] Drop support for maven below 3.2.x
cstamas commented on a change in pull request #8: URL: https://github.com/apache/maven-reporting-exec/pull/8#discussion_r791408768 ## File path: pom.xml ## @@ -170,7 +145,13 @@ junit junit - 4.13.1 + 4.13.2 + test + + + org.slf4j + slf4j-simple + 1.7.32 Review comment: These are all "test" scoped deps, so they matter "locally" only, so IMHO does not matter. We can align them (by same logic as resolver, so "use version maven X used"), but putting them into parent is overkill IMO. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1029) Update plugin (requires Maven 3.2.5+)
[ https://issues.apache.org/jira/browse/MSHARED-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481588#comment-17481588 ] ASF GitHub Bot commented on MSHARED-1029: - cstamas commented on a change in pull request #8: URL: https://github.com/apache/maven-reporting-exec/pull/8#discussion_r791408235 ## File path: pom.xml ## @@ -56,9 +56,9 @@ -3.0 +3.2.5 +1.0.0.v20140518 Review comment: Whenever "maven version" in play, I tend to align resolver based on this table: https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup#MavenEcosystemCleanup-ResolverandMaven -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update plugin (requires Maven 3.2.5+) > - > > Key: MSHARED-1029 > URL: https://issues.apache.org/jira/browse/MSHARED-1029 > Project: Maven Shared Components > Issue Type: Task > Components: maven-reporting-exec >Reporter: Tamás Cservenák >Priority: Major > > Drop Maven 3.1 and 3.0 support (to get rid of Sonatype Aether), align with > other components. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-reporting-exec] cstamas commented on a change in pull request #8: [MSHARED-1029] Drop support for maven below 3.2.x
cstamas commented on a change in pull request #8: URL: https://github.com/apache/maven-reporting-exec/pull/8#discussion_r791408235 ## File path: pom.xml ## @@ -56,9 +56,9 @@ -3.0 +3.2.5 +1.0.0.v20140518 Review comment: Whenever "maven version" in play, I tend to align resolver based on this table: https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup#MavenEcosystemCleanup-ResolverandMaven -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1029) Update plugin (requires Maven 3.2.5+)
Tamás Cservenák created MSHARED-1029: Summary: Update plugin (requires Maven 3.2.5+) Key: MSHARED-1029 URL: https://issues.apache.org/jira/browse/MSHARED-1029 Project: Maven Shared Components Issue Type: Task Components: maven-reporting-exec Reporter: Tamás Cservenák Drop Maven 3.1 and 3.0 support (to get rid of Sonatype Aether), align with other components. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481574#comment-17481574
]
Martin Tzvetanov Grigorov commented on MCOMPILER-481:
-
https://issues.apache.org/jira/browse/MCOMPILER-482 is a similar issue like
this one. You can take an inspiration from it for more test cases.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class {{JSON}} is in {{{}jetty-util-10.0.7.jar{}}}.
> In 3.9.0 this jar is missing from the module-path, causing the error.
> Attached you
[jira] [Commented] (MCOMPILER-482) JPMS regression: optional transitive module is not found
[
https://issues.apache.org/jira/browse/MCOMPILER-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481573#comment-17481573
]
Martin Tzvetanov Grigorov commented on MCOMPILER-482:
-
[~sor] confirmed that this issue is the same as MCOMPILER-481:
https://the-asf.slack.com/archives/C7Q9JB404/p1643019726096400
> JPMS regression: optional transitive module is not found
>
>
> Key: MCOMPILER-482
> URL: https://issues.apache.org/jira/browse/MCOMPILER-482
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Martin Tzvetanov Grigorov
>Priority: Minor
>
> Apache Wicket's build fails with maven-compiler-plugin:3.9.0:
>
> {code:java}
> [INFO] --- maven-compiler-plugin:3.9.0:compile (default-compile) @
> wicket-core ---
> [WARNING]
>
> [WARNING] * Required filename-based automodules detected:
> [commons-fileupload2-2.0-SNAPSHOT.jar]. Please don't publish this project to
> a public artifact repository! *
> [WARNING]
>
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 836 source files to
> /home/martin/git/apache/wicket/wicket-core/target/classes
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR] module not found: org.apiguardian.api
> [INFO] 1 error
> [INFO] -
> {code}
>
> Wicket-core module depends on JUnit Jupiter API:
> [https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/module-info.java#L31]
> and apiguardian comes as a transitive dependency of it.
>
> To reproduce:
> 1) git clone [https://github.com/apache/wicket.git]
> 2) edit pom.xml (line 195) to change the version of maven-compiler-plugin
> from 3.8.1 to 3.9.0
> 3) export JAVA_HOME=/path/to/jdk-17 (also you need to have an entry for JDK
> 17 in ~/.m2/toolchains.xml)
> 4) mvn verify
>
> https://issues.apache.org/jira/browse/MCOMPILER-481 looks similar but I am
> not sure it is the same!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[
https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rishabh Arora updated SUREFIRE-1984:
Description:
I need this feature because some testcases need isolated environment to run. I
have seen that certain testcases fail on an existing fork but seem to run fine
on a new fork. I want to be able to keep the number of active forks same at all
times. Just that kill the fork that executes a failed testcase and retry on a
newly generated fork.
The idea in a nutshell:
{code:java}
import org.junit.Assert;
import org.junit.Test;
public class surefireTest {
private static boolean flag = true;
@Test
public void test1() {
Assert.assertTrue(flag);
flag = false;
}
@Test
public void test2() {
test1();
}
@Test
public void test3() {
test1();
}
}
{code}
Running the above code using surefire using 1 &
3 should ideally be able to
pass all the testcases, but in our case it is able to pass just testcase 1. Is
it possible to have a completely isolated environment (free from pollution from
other testcases) for all 3 testcases, that is as soon as a testcase fails, we
kill the current fork and start a new fork and retry for the failed testcase
and so on.
Please find the observed result attached below.
Thanks!
was:
I need this feature because some testcases need isolated environment to run. I
have seen that certain testcases fail on an existing fork but seem to run fine
on a new fork. I want to be able to keep the number of active forks same at all
times. Just that kill the fork that executes a failed testcase and retry on a
newly generated fork.
The idea in a nutshell:
{code:java}
import org.junit.Assert;
import org.junit.Test;
public class surefireTest {
private static boolean flag = true;
@Test
public void test1() {
Assert.assertTrue(flag);
flag = false;
}
@Test
public void test2() {
test1();
}
@Test
public void test3() {
test1();
}
}
{code}
Running the above code using surefire should ideally be able to pass all the
testcases, but in our case it is able to pass just testcase 1. Is it possible
to have a completely isolated environment (free from pollution from other
testcases) for all 3 testcases?
Please find the observed result attached below.
Thanks!
> To be able to kill a fork as soon as a test case fails and start a new fork
> from the failed testcase, following which subsequent testcases are run.
>
>
> Key: SUREFIRE-1984
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1984
> Project: Maven Surefire
> Issue Type: Wish
> Components: process forking
>Reporter: Rishabh Arora
>Priority: Major
> Fix For: Backlog
>
> Attachments: Screenshot 2022-01-25 at 10.36.34 AM.png
>
>
> I need this feature because some testcases need isolated environment to run.
> I have seen that certain testcases fail on an existing fork but seem to run
> fine on a new fork. I want to be able to keep the number of active forks same
> at all times. Just that kill the fork that executes a failed testcase and
> retry on a newly generated fork.
> The idea in a nutshell:
>
> {code:java}
> import org.junit.Assert;
> import org.junit.Test;
> public class surefireTest {
> private static boolean flag = true;
> @Test
> public void test1() {
> Assert.assertTrue(flag);
> flag = false;
> }
> @Test
> public void test2() {
> test1();
> }
> @Test
> public void test3() {
> test1();
> }
> }
> {code}
>
> Running the above code using surefire using 1 &
> 3 should ideally be able to
> pass all the testcases, but in our case it is able to pass just testcase 1.
> Is it possible to have a completely isolated environment (free from pollution
> from other testcases) for all 3 testcases, that is as soon as a testcase
> fails, we kill the current fork and start a new fork and retry for the failed
> testcase and so on.
> Please find the observed result attached below.
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1985) While running test cases if a test case fails, need to kill the fork and run subsequent testcases(including the failed one) with a new fork
[ https://issues.apache.org/jira/browse/SUREFIRE-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanidhya Vijaivargia updated SUREFIRE-1985: --- Description: after running a particular module/project if the test fails even after rerunning it N specified times the subsequent modules fail automatically without running them. was:While running 'n' tests using forks the if a particular testcase fails all the subsequent test are skipped and can't be executed. > While running test cases if a test case fails, need to kill the fork and run > subsequent testcases(including the failed one) with a new fork > - > > Key: SUREFIRE-1985 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1985 > Project: Maven Surefire > Issue Type: Wish > Components: process forking >Reporter: Sanidhya Vijaivargia >Priority: Major > > after running a particular module/project if the test fails even after > rerunning it N specified times the subsequent modules fail automatically > without running them. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-1985) While running test cases if a test case fails, need to kill the fork and run subsequent testcases(including the failed one) with a new fork
[ https://issues.apache.org/jira/browse/SUREFIRE-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481553#comment-17481553 ] Sanidhya Vijaivargia edited comment on SUREFIRE-1985 at 1/25/22, 5:34 AM: -- I meant that after running a particular module/project if the test fails even after rerunning it N specified times the subsequent modules fail automatically without running them. was (Author: JIRAUSER284086): I meant that after running a particular module/project if the test fails even after rerunning it N specified times the subsequent modules fail automatically. > While running test cases if a test case fails, need to kill the fork and run > subsequent testcases(including the failed one) with a new fork > - > > Key: SUREFIRE-1985 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1985 > Project: Maven Surefire > Issue Type: Wish > Components: process forking >Reporter: Sanidhya Vijaivargia >Priority: Major > > While running 'n' tests using forks the if a particular testcase fails all > the subsequent test are skipped and can't be executed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1985) While running test cases if a test case fails, need to kill the fork and run subsequent testcases(including the failed one) with a new fork
[ https://issues.apache.org/jira/browse/SUREFIRE-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481553#comment-17481553 ] Sanidhya Vijaivargia commented on SUREFIRE-1985: I meant that after running a particular module/project if the test fails even after rerunning it N specified times the subsequent modules fail automatically. > While running test cases if a test case fails, need to kill the fork and run > subsequent testcases(including the failed one) with a new fork > - > > Key: SUREFIRE-1985 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1985 > Project: Maven Surefire > Issue Type: Wish > Components: process forking >Reporter: Sanidhya Vijaivargia >Priority: Major > > While running 'n' tests using forks the if a particular testcase fails all > the subsequent test are skipped and can't be executed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[
https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rishabh Arora updated SUREFIRE-1984:
Description:
I need this feature because some testcases need isolated environment to run. I
have seen that certain testcases fail on an existing fork but seem to run fine
on a new fork. I want to be able to keep the number of active forks same at all
times. Just that kill the fork that executes a failed testcase and retry on a
newly generated fork.
The idea in a nutshell:
{code:java}
import org.junit.Assert;
import org.junit.Test;
public class surefireTest {
private static boolean flag = true;
@Test
public void test1() {
Assert.assertTrue(flag);
flag = false;
}
@Test
public void test2() {
test1();
}
@Test
public void test3() {
test1();
}
}
{code}
Running the above code using surefire should ideally be able to pass all the
testcases, but in our case it is able to pass just testcase 1. Is it possible
to have a completely isolated environment (free from pollution from other
testcases) for all 3 testcases?
Please find the observed result attached below.
Thanks!
was:
I need this feature because some testcases need isolated environment to run. I
have seen that certain testcases fail on an existing fork but seem to run fine
on a new fork. I want to be able to keep the number of active forks same at all
times. Just that kill the fork that executes a failed testcase and retry on a
newly generated fork.
The idea in a nutshell:
{code:java}
import org.junit.Assert;
import org.junit.Test;
public class surefireTest {
private static boolean flag = true;
@Test
public void test1() throws InterruptedException {
Assert.assertTrue(flag);
flag = false;
}
@Test
public void test2() throws InterruptedException {
test1();
}
@Test
public void test3() throws InterruptedException {
test1();
}
}
{code}
Running the above code using surefire should ideally be able to pass all the
testcases, but in our case it is able to pass just testcase 1. Is it possible
to have a completely isolated environment (free from pollution from other
testcases) for all 3 testcases?
Please find the observed result attached below.
Thanks!
> To be able to kill a fork as soon as a test case fails and start a new fork
> from the failed testcase, following which subsequent testcases are run.
>
>
> Key: SUREFIRE-1984
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1984
> Project: Maven Surefire
> Issue Type: Wish
> Components: process forking
>Reporter: Rishabh Arora
>Priority: Major
> Fix For: Backlog
>
> Attachments: Screenshot 2022-01-25 at 10.36.34 AM.png
>
>
> I need this feature because some testcases need isolated environment to run.
> I have seen that certain testcases fail on an existing fork but seem to run
> fine on a new fork. I want to be able to keep the number of active forks same
> at all times. Just that kill the fork that executes a failed testcase and
> retry on a newly generated fork.
> The idea in a nutshell:
>
> {code:java}
> import org.junit.Assert;
> import org.junit.Test;
> public class surefireTest {
> private static boolean flag = true;
> @Test
> public void test1() {
> Assert.assertTrue(flag);
> flag = false;
> }
> @Test
> public void test2() {
> test1();
> }
> @Test
> public void test3() {
> test1();
> }
> }
> {code}
>
> Running the above code using surefire should ideally be able to pass all the
> testcases, but in our case it is able to pass just testcase 1. Is it possible
> to have a completely isolated environment (free from pollution from other
> testcases) for all 3 testcases?
> Please find the observed result attached below.
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[
https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rishabh Arora updated SUREFIRE-1984:
Description:
I need this feature because some testcases need isolated environment to run. I
have seen that certain testcases fail on an existing fork but seem to run fine
on a new fork. I want to be able to keep the number of active forks same at all
times. Just that kill the fork that executes a failed testcase and retry on a
newly generated fork.
The idea in a nutshell:
{code:java}
import org.junit.Assert;
import org.junit.Test;
public class surefireTest {
private static boolean flag = true;
@Test
public void test1() throws InterruptedException {
Assert.assertTrue(flag);
flag = false;
}
@Test
public void test2() throws InterruptedException {
test1();
}
@Test
public void test3() throws InterruptedException {
test1();
}
}
{code}
Running the above code using surefire should ideally be able to pass all the
testcases, but in our case it is able to pass just testcase 1. Is it possible
to have a completely isolated environment (free from pollution from other
testcases) for all 3 testcases?
Please find the observed result attached below.
Thanks!
was:
I need this feature because some testcases need isolated environment to run. I
have seen that certain testcases fail on an existing fork but seem to run fine
on a new fork. I want to be able to keep the number of active forks same at all
times. Just that kill the fork that executes a failed testcase and retry on a
newly generated fork.
The idea in a nutshell:
--
import org.junit.Assert;
import org.junit.Test;
public class surefireTest {
private static boolean flag = true;
@Test
public void test1() throws InterruptedException {
Assert.assertTrue(flag);
flag = false;
}
@Test
public void test2() throws InterruptedException {
test1();
}
@Test
public void test3() throws InterruptedException {
test1();
}
}
-
Running the above code using surefire should ideally be able to pass all the
testcases, but in our case it is able to pass just testcase 1. Is it possible
to have a completely isolated environment (free from pollution from other
testcases) for all 3 testcases?
Please find the observed result attached below.
Thanks!
> To be able to kill a fork as soon as a test case fails and start a new fork
> from the failed testcase, following which subsequent testcases are run.
>
>
> Key: SUREFIRE-1984
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1984
> Project: Maven Surefire
> Issue Type: Wish
> Components: process forking
>Reporter: Rishabh Arora
>Priority: Major
> Fix For: Backlog
>
> Attachments: Screenshot 2022-01-25 at 10.36.34 AM.png
>
>
> I need this feature because some testcases need isolated environment to run.
> I have seen that certain testcases fail on an existing fork but seem to run
> fine on a new fork. I want to be able to keep the number of active forks same
> at all times. Just that kill the fork that executes a failed testcase and
> retry on a newly generated fork.
> The idea in a nutshell:
>
> {code:java}
> import org.junit.Assert;
> import org.junit.Test;
> public class surefireTest {
> private static boolean flag = true;
> @Test
> public void test1() throws InterruptedException {
> Assert.assertTrue(flag);
> flag = false;
> }
> @Test
> public void test2() throws InterruptedException {
> test1();
> }
> @Test
> public void test3() throws InterruptedException {
> test1();
> }
> }
> {code}
>
> Running the above code using surefire should ideally be able to pass all the
> testcases, but in our case it is able to pass just testcase 1. Is it possible
> to have a completely isolated environment (free from pollution from other
> testcases) for all 3 testcases?
> Please find the observed result attached below.
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[
https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481543#comment-17481543
]
Rishabh Arora edited comment on SUREFIRE-1984 at 1/25/22, 5:11 AM:
---
[~tibordigana] I have updated the description a bit. A little bit of guidance
on how to kill a fork when a testcase fails and how to start a new fork for the
remaining test cases (including the failed one, provided it's retry count is
not 0) will be extremely useful.
was (Author: JIRAUSER284083):
[~tibordigana] I have updated the description a bit.
> To be able to kill a fork as soon as a test case fails and start a new fork
> from the failed testcase, following which subsequent testcases are run.
>
>
> Key: SUREFIRE-1984
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1984
> Project: Maven Surefire
> Issue Type: Wish
> Components: process forking
>Reporter: Rishabh Arora
>Priority: Major
> Fix For: Backlog
>
> Attachments: Screenshot 2022-01-25 at 10.36.34 AM.png
>
>
> I need this feature because some testcases need isolated environment to run.
> I have seen that certain testcases fail on an existing fork but seem to run
> fine on a new fork. I want to be able to keep the number of active forks same
> at all times. Just that kill the fork that executes a failed testcase and
> retry on a newly generated fork.
> The idea in a nutshell:
> --
> import org.junit.Assert;
> import org.junit.Test;
> public class surefireTest {
> private static boolean flag = true;
> @Test
> public void test1() throws InterruptedException {
> Assert.assertTrue(flag);
> flag = false;
> }
> @Test
> public void test2() throws InterruptedException {
> test1();
> }
> @Test
> public void test3() throws InterruptedException {
> test1();
> }
> }
> -
> Running the above code using surefire should ideally be able to pass all the
> testcases, but in our case it is able to pass just testcase 1. Is it possible
> to have a completely isolated environment (free from pollution from other
> testcases) for all 3 testcases?
> Please find the observed result attached below.
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[
https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481543#comment-17481543
]
Rishabh Arora commented on SUREFIRE-1984:
-
[~tibordigana] I have updated the description a bit.
> To be able to kill a fork as soon as a test case fails and start a new fork
> from the failed testcase, following which subsequent testcases are run.
>
>
> Key: SUREFIRE-1984
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1984
> Project: Maven Surefire
> Issue Type: Wish
> Components: process forking
>Reporter: Rishabh Arora
>Priority: Major
> Fix For: Backlog
>
> Attachments: Screenshot 2022-01-25 at 10.36.34 AM.png
>
>
> I need this feature because some testcases need isolated environment to run.
> I have seen that certain testcases fail on an existing fork but seem to run
> fine on a new fork. I want to be able to keep the number of active forks same
> at all times. Just that kill the fork that executes a failed testcase and
> retry on a newly generated fork.
> The idea in a nutshell:
> --
> import org.junit.Assert;
> import org.junit.Test;
> public class surefireTest {
> private static boolean flag = true;
> @Test
> public void test1() throws InterruptedException {
> Assert.assertTrue(flag);
> flag = false;
> }
> @Test
> public void test2() throws InterruptedException {
> test1();
> }
> @Test
> public void test3() throws InterruptedException {
> test1();
> }
> }
> -
> Running the above code using surefire should ideally be able to pass all the
> testcases, but in our case it is able to pass just testcase 1. Is it possible
> to have a completely isolated environment (free from pollution from other
> testcases) for all 3 testcases?
> Please find the observed result attached below.
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[
https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rishabh Arora updated SUREFIRE-1984:
Description:
I need this feature because some testcases need isolated environment to run. I
have seen that certain testcases fail on an existing fork but seem to run fine
on a new fork. I want to be able to keep the number of active forks same at all
times. Just that kill the fork that executes a failed testcase and retry on a
newly generated fork.
The idea in a nutshell:
--
import org.junit.Assert;
import org.junit.Test;
public class surefireTest {
private static boolean flag = true;
@Test
public void test1() throws InterruptedException {
Assert.assertTrue(flag);
flag = false;
}
@Test
public void test2() throws InterruptedException {
test1();
}
@Test
public void test3() throws InterruptedException {
test1();
}
}
-
Running the above code using surefire should ideally be able to pass all the
testcases, but in our case it is able to pass just testcase 1. Is it possible
to have a completely isolated environment (free from pollution from other
testcases) for all 3 testcases?
Please find the observed result attached below.
Thanks!
was:
I need this feature because some testcases need isolated environment to run. I
have seen that certain testcases fail on an existing fork but seem to run fine
on a new fork. I want to be able to keep the number of active forks same at all
times. Just that kill the fork that executes a failed testcase and retry on a
newly generated fork.
The idea in a nutshell:
import org.junit.Assert;
import org.junit.Test;
public class surefireTest {
private static boolean flag = true;
@Test
public void test1() throws InterruptedException {
Assert.assertTrue(flag);
flag = false;
Thread.sleep(4);
}
@Test
public void test2() throws InterruptedException {
test1();
}
@Test
public void test3() throws InterruptedException {
test1();
}
}
Running the above code using surefire should ideally be able to pass all the
testcases, but in our case it is able to pass just testcase 1. Is it possible
to have a completely isolated environment (free from pollution from other
testcases) for all 3 testcases?
Observed Output:
> To be able to kill a fork as soon as a test case fails and start a new fork
> from the failed testcase, following which subsequent testcases are run.
>
>
> Key: SUREFIRE-1984
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1984
> Project: Maven Surefire
> Issue Type: Wish
> Components: process forking
>Reporter: Rishabh Arora
>Priority: Major
> Fix For: Backlog
>
> Attachments: Screenshot 2022-01-25 at 10.36.34 AM.png
>
>
> I need this feature because some testcases need isolated environment to run.
> I have seen that certain testcases fail on an existing fork but seem to run
> fine on a new fork. I want to be able to keep the number of active forks same
> at all times. Just that kill the fork that executes a failed testcase and
> retry on a newly generated fork.
> The idea in a nutshell:
> --
> import org.junit.Assert;
> import org.junit.Test;
> public class surefireTest {
> private static boolean flag = true;
> @Test
> public void test1() throws InterruptedException {
> Assert.assertTrue(flag);
> flag = false;
> }
> @Test
> public void test2() throws InterruptedException {
> test1();
> }
> @Test
> public void test3() throws InterruptedException {
> test1();
> }
> }
> -
> Running the above code using surefire should ideally be able to pass all the
> testcases, but in our case it is able to pass just testcase 1. Is it possible
> to have a completely isolated environment (free from pollution from other
> testcases) for all 3 testcases?
> Please find the observed result attached below.
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[
https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rishabh Arora updated SUREFIRE-1984:
Description:
I need this feature because some testcases need isolated environment to run. I
have seen that certain testcases fail on an existing fork but seem to run fine
on a new fork. I want to be able to keep the number of active forks same at all
times. Just that kill the fork that executes a failed testcase and retry on a
newly generated fork.
The idea in a nutshell:
import org.junit.Assert;
import org.junit.Test;
public class surefireTest {
private static boolean flag = true;
@Test
public void test1() throws InterruptedException {
Assert.assertTrue(flag);
flag = false;
Thread.sleep(4);
}
@Test
public void test2() throws InterruptedException {
test1();
}
@Test
public void test3() throws InterruptedException {
test1();
}
}
Running the above code using surefire should ideally be able to pass all the
testcases, but in our case it is able to pass just testcase 1. Is it possible
to have a completely isolated environment (free from pollution from other
testcases) for all 3 testcases?
Observed Output:
was:
I need this feature because some testcases need isolated environment to run. I
have seen that certain testcases fail on an existing fork but seem to run fine
on a new fork. I want to be able to keep the number of active forks same at all
times. Just that kill the fork that executes a failed testcase and retry on a
newly generated fork.
The idea in a nutshell:
{{import org.junit.Assert;
import org.junit.Test;
public class surefireTest {
private static boolean flag = true;
@Test
public void test1() throws InterruptedException {
Assert.assertTrue(flag);
flag = false;
Thread.sleep(4);
}
@Test
public void test2() throws InterruptedException {
test1();
}
@Test
public void test3() throws InterruptedException {
test1();
}
}}}
> To be able to kill a fork as soon as a test case fails and start a new fork
> from the failed testcase, following which subsequent testcases are run.
>
>
> Key: SUREFIRE-1984
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1984
> Project: Maven Surefire
> Issue Type: Wish
> Components: process forking
>Reporter: Rishabh Arora
>Priority: Major
> Fix For: Backlog
>
> Attachments: Screenshot 2022-01-25 at 10.36.34 AM.png
>
>
> I need this feature because some testcases need isolated environment to run.
> I have seen that certain testcases fail on an existing fork but seem to run
> fine on a new fork. I want to be able to keep the number of active forks same
> at all times. Just that kill the fork that executes a failed testcase and
> retry on a newly generated fork.
> The idea in a nutshell:
> import org.junit.Assert;
> import org.junit.Test;
> public class surefireTest {
> private static boolean flag = true;
> @Test
> public void test1() throws InterruptedException {
> Assert.assertTrue(flag);
> flag = false;
> Thread.sleep(4);
> }
> @Test
> public void test2() throws InterruptedException {
> test1();
> }
> @Test
> public void test3() throws InterruptedException {
> test1();
> }
> }
> Running the above code using surefire should ideally be able to pass all the
> testcases, but in our case it is able to pass just testcase 1. Is it possible
> to have a completely isolated environment (free from pollution from other
> testcases) for all 3 testcases?
> Observed Output:
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[
https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rishabh Arora updated SUREFIRE-1984:
Attachment: Screenshot 2022-01-25 at 10.36.34 AM.png
> To be able to kill a fork as soon as a test case fails and start a new fork
> from the failed testcase, following which subsequent testcases are run.
>
>
> Key: SUREFIRE-1984
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1984
> Project: Maven Surefire
> Issue Type: Wish
> Components: process forking
>Reporter: Rishabh Arora
>Priority: Major
> Fix For: Backlog
>
> Attachments: Screenshot 2022-01-25 at 10.36.34 AM.png
>
>
> I need this feature because some testcases need isolated environment to run.
> I have seen that certain testcases fail on an existing fork but seem to run
> fine on a new fork. I want to be able to keep the number of active forks same
> at all times. Just that kill the fork that executes a failed testcase and
> retry on a newly generated fork.
> The idea in a nutshell:
> import org.junit.Assert;
> import org.junit.Test;
> public class surefireTest {
> private static boolean flag = true;
> @Test
> public void test1() throws InterruptedException {
> Assert.assertTrue(flag);
> flag = false;
> Thread.sleep(4);
> }
> @Test
> public void test2() throws InterruptedException {
> test1();
> }
> @Test
> public void test3() throws InterruptedException {
> test1();
> }
> }
> Running the above code using surefire should ideally be able to pass all the
> testcases, but in our case it is able to pass just testcase 1. Is it possible
> to have a completely isolated environment (free from pollution from other
> testcases) for all 3 testcases?
> Observed Output:
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[
https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rishabh Arora updated SUREFIRE-1984:
Description:
I need this feature because some testcases need isolated environment to run. I
have seen that certain testcases fail on an existing fork but seem to run fine
on a new fork. I want to be able to keep the number of active forks same at all
times. Just that kill the fork that executes a failed testcase and retry on a
newly generated fork.
The idea in a nutshell:
{{import org.junit.Assert;
import org.junit.Test;
public class surefireTest {
private static boolean flag = true;
@Test
public void test1() throws InterruptedException {
Assert.assertTrue(flag);
flag = false;
Thread.sleep(4);
}
@Test
public void test2() throws InterruptedException {
test1();
}
@Test
public void test3() throws InterruptedException {
test1();
}
}}}
was:I need this feature because some testcases need isolated environment to
run. I have seen that certain testcases fail on an existing fork but seem to
run fine on a new fork. I want to be able to keep the number of active forks
same at all times. Just that kill the fork that executes a failed testcase and
retry on a newly generated fork.
> To be able to kill a fork as soon as a test case fails and start a new fork
> from the failed testcase, following which subsequent testcases are run.
>
>
> Key: SUREFIRE-1984
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1984
> Project: Maven Surefire
> Issue Type: Wish
> Components: process forking
>Reporter: Rishabh Arora
>Priority: Major
> Fix For: Backlog
>
>
> I need this feature because some testcases need isolated environment to run.
> I have seen that certain testcases fail on an existing fork but seem to run
> fine on a new fork. I want to be able to keep the number of active forks same
> at all times. Just that kill the fork that executes a failed testcase and
> retry on a newly generated fork.
> The idea in a nutshell:
> {{import org.junit.Assert;
> import org.junit.Test;
> public class surefireTest {
> private static boolean flag = true;
> @Test
> public void test1() throws InterruptedException {
> Assert.assertTrue(flag);
> flag = false;
> Thread.sleep(4);
> }
> @Test
> public void test2() throws InterruptedException {
> test1();
> }
> @Test
> public void test3() throws InterruptedException {
> test1();
> }
> }}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] laeubi commented on pull request #665: MNG-7395 - Support system-properties in extension.xml
laeubi commented on pull request #665: URL: https://github.com/apache/maven/pull/665#issuecomment-1020812021 @michael-o I now added the interrogator similar to that method you mentioned @rmannibucau It now also support env-variables. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] dependabot[bot] opened a new pull request #446: Bump jansi from 2.2.0 to 2.4.0
dependabot[bot] opened a new pull request #446: URL: https://github.com/apache/maven-surefire/pull/446 Bumps [jansi](https://github.com/fusesource/jansi) from 2.2.0 to 2.4.0. Changelog Sourced from https://github.com/fusesource/jansi/blob/master/changelog.md;>jansi's changelog. https://repo.maven.apache.org/maven2/org/fusesource/jansi/jansi/2.4.0;>Jansi 2.4.0, released 2021-10-14 https://github.com/fusesource/jansi/commit/2cf446182c823a4c110411b765a1f0367eb8a913;>2cf4461 Fix support for GraalVM native-image, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/199;>#199 https://github.com/fusesource/jansi/commit/d83ab13378ca17bc359ba1c780b2a2f0474877b1;>d83ab13 Code cleanup https://github.com/fusesource/jansi/commit/3d976451adce20e8ab48528fbe4051595a1d21c5;>3d97645 Improve error reporting when the tmp dir has the noexec flag, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/193;>#193 https://github.com/fusesource/jansi/commit/454d8582c689af7646a21b036e887d6737b20e66;>454d858 Support Mac-arm64 target, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/218;>#218 (https://github-redirect.dependabot.com/fusesource/jansi/issues/222;>#222) https://github.com/fusesource/jansi/commit/4e5ab5b1628df50f06d13fbe2d1bfeeead37d01e;>4e5ab5b Support linux armv6 platform, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/201;>#201 (https://github-redirect.dependabot.com/fusesource/jansi/issues/221;>#221) https://github.com/fusesource/jansi/commit/98c430a4d42368f9a5524470e74ca87aeee03bcb;>98c430a Change the behavior to fail gracefuly in case the system is not supported, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/204;>#204 https://github.com/fusesource/jansi/commit/cb843bff3fab9cfa2008093483cf6c161899a749;>cb843bf Switch to test on LTS versions https://github.com/fusesource/jansi/commit/ae20846652a85926676ad61b90dba43f49b6b636;>ae20846 Remove native methods not used by jansi, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/208;>#208 https://github.com/fusesource/jansi/commit/1ab54ca6d40c92600411e7d84bbe02d22e22fb06;>1ab54ca Add aarch64 support, fix https://github-redirect.dependabot.com/fusesource/jansi/issues/219;>#219 https://github.com/fusesource/jansi/commit/b3fe92b4ba2dfe7af23a7175e00329724ff0644a;>b3fe92b Remove old Win XP need to download something https://github.com/fusesource/jansi/commit/321a8ff71c731e10f4ea05c607860180276b2215;>321a8ff [maven-release-plugin] prepare for next development iteration https://github.com/fusesource/jansi/commit/4e2e6a9f6813bedb4d788b2cd1f70c5617214a9a;>4e2e6a9 [maven-release-plugin] prepare release jansi-2.3.4 https://github.com/fusesource/jansi/commit/ba575ba6ef2e963405c462db271d31ef05442dbb;>ba575ba Update changelog for release https://github.com/fusesource/jansi/commit/09722b78a99f14ac1656db3072dbeef34478;>09722b7 Disable colors when running inside emacs without comint, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/205;>#205 https://github.com/fusesource/jansi/commit/e019a75ee267a53a48d02ac983266cdf2b4e16a9;>e019a75 Add missing colors to AnsiRender, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/213;>#213 https://github.com/fusesource/jansi/commit/01d68f03c6b69c323a05738efec1fd4404c0f0f8;>01d68f0 Fix Ansi outputting escape sequences when disabled, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/215;>#215 https://github.com/fusesource/jansi/commit/3ba11e9d324f81b359229715ceacadcb9137ff46;>3ba11e9 Avoid possible NPE, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/214;>#214 https://repo.maven.apache.org/maven2/org/fusesource/jansi/jansi/2.3.4;>Jansi 2.3.4, released 2021-07-23 https://github.com/fusesource/jansi/commit/09722b78a99f14ac1656db3072dbeef34478;>09722b7 Disable colors when running inside emacs without comint, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/205;>#205 https://github.com/fusesource/jansi/commit/e019a75ee267a53a48d02ac983266cdf2b4e16a9;>e019a75 Add missing colors to AnsiRender, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/213;>#213 https://github.com/fusesource/jansi/commit/01d68f03c6b69c323a05738efec1fd4404c0f0f8;>01d68f0 Fix Ansi outputting escape sequences when disabled, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/215;>#215 https://github.com/fusesource/jansi/commit/3ba11e9d324f81b359229715ceacadcb9137ff46;>3ba11e9 Avoid possible NPE, fixes https://github-redirect.dependabot.com/fusesource/jansi/issues/214;>#214 https://repo.maven.apache.org/maven2/org/fusesource/jansi/jansi/2.3.3;>Jansi 2.3.3, released 2021-06-11 https://github.com/fusesource/jansi/commit/e4d58d94eab5ecbc2f466978a5006835cf728da7;>e4d58d9 Jansi fails to start on Mac arm,
[GitHub] [maven] laeubi commented on pull request #665: MNG-7395 - Support system-properties in extension.xml
laeubi commented on pull request #665:
URL: https://github.com/apache/maven/pull/665#issuecomment-1020793244
> I don't see the need for that since in the pom you can set in properties
`1.2.3` and override it with `-Dmyextension.version` in
maven's spirit.
Please take a look at the code and/or [referenced JIRA
](https://issues.apache.org/jira/browse/MNG-7395), at the time the extensions
are fetched/created there is no properties, no session, even no "maven".
If you still think it is possible a small example would be useful
(disclaimer: I have already tried this out and got only an warning from maven
where it complains that `${myextension.version}` could not be found as a
version in any repository) you can use the one I have [attached
here](https://issues.apache.org/jira/secure/attachment/13039302/testit.zip) as
a starting point.
> Anything else just creates something inconsistent without new real
features so better to ensure the "on the fly plugin" is processed as any model
instead of making it specific (and lacking env support for ex), no?
Why do you think it is inconsistent? It is what most maven developers would
expect and the first thing you have to learn when using core-extensions with
`.mvn/extensions.xml` that they are simply dump and missing all features beside
plain text parsing. So I'd like to have *at laest* support for java properties,
if one feels env-variables are useful or whatever else that is avaiable at this
very early stage, why not, but at the end of the day I'd better have support
for "only" system properties instead of no support at all because there are so
many other thing one *might* could need and essentially the feature never
happens.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481495#comment-17481495
]
Olivier Lamy edited comment on MCOMPILER-481 at 1/25/22, 2:25 AM:
--
I find it strange we almost do not read anything from pom regarding (test?)
dependencies.
Shouldn't we automatically add test dependencies coming from the pom in
module-path for test?
not sure including static should be limited to test compilation only. If you
look at the provided test project. not included static will fail compilation as
there is
requires static org.eclipse.jetty.util.ajax
and the dependency is marked as optional
but it's required for compilation.
was (Author: olamy):
I find it strange we almost do not read anything from pom regarding (test?)
dependencies.
Shouldn't we automatically add test dependencies coming from the pom in
module-path for test?
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481495#comment-17481495
]
Olivier Lamy commented on MCOMPILER-481:
I find it strange we almost do not read anything from pom regarding (test?)
dependencies.
Shouldn't we automatically add test dependencies coming from the pom in
module-path for test?
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class {{JSON}} is in {{{}jetty-util-10.0.7.jar{}}}.
> In 3.9.0 this jar is missing from the module-path, causing the
[jira] [Comment Edited] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[ https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481485#comment-17481485 ] Tibor Digana edited comment on SUREFIRE-1984 at 1/25/22, 1:47 AM: -- This is a very good idea, we spoke about it with Professor Jonathan Bell and Wing Lam but unfortunately it is too complicated to focus the energy on it today. You can talk to these people about it and they may tell you more about it from the perspective of studies they have done so far and feasibility. Maybe they would find a team who may help... was (Author: tibor17): This is a very good idea, we spoke about it with Professor Jonathan Bell and Wing Lam but unfortunately it is too complicated to focus the energy on it today. You can talk to these people about it and may tell you more about it from the perspective of studies they have done so far and feasibility. Maybe they would find a team who may help... > To be able to kill a fork as soon as a test case fails and start a new fork > from the failed testcase, following which subsequent testcases are run. > > > Key: SUREFIRE-1984 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1984 > Project: Maven Surefire > Issue Type: Wish > Components: process forking >Reporter: Rishabh Arora >Priority: Major > Fix For: Backlog > > > I need this feature because some testcases need isolated environment to run. > I have seen that certain testcases fail on an existing fork but seem to run > fine on a new fork. I want to be able to keep the number of active forks same > at all times. Just that kill the fork that executes a failed testcase and > retry on a newly generated fork. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[ https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481485#comment-17481485 ] Tibor Digana edited comment on SUREFIRE-1984 at 1/25/22, 1:42 AM: -- This is a very good idea, we spoke about it with Professor Jonathan Bell and Wing Lam but unfortunately it is too complicated to focus the energy on it today. You can talk to these people about it and may tell you more about it from the perspective of studies they have done so far and feasibility. Maybe they would find a team who may help... was (Author: tibor17): This is very good idea, we spoke about it with Professor Jonathan Bell and Wing Lam but unfortunately it is too complicated to focus the energy on it today. You can talk to these people about it and may tell you more about it from the perspective of studies they have done so far and feasibility. > To be able to kill a fork as soon as a test case fails and start a new fork > from the failed testcase, following which subsequent testcases are run. > > > Key: SUREFIRE-1984 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1984 > Project: Maven Surefire > Issue Type: Wish > Components: process forking >Reporter: Rishabh Arora >Priority: Major > Fix For: Backlog > > > I need this feature because some testcases need isolated environment to run. > I have seen that certain testcases fail on an existing fork but seem to run > fine on a new fork. I want to be able to keep the number of active forks same > at all times. Just that kill the fork that executes a failed testcase and > retry on a newly generated fork. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[ https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481485#comment-17481485 ] Tibor Digana edited comment on SUREFIRE-1984 at 1/25/22, 1:42 AM: -- This is a very good idea, we spoke about it with Professor Jonathan Bell and Wing Lam but unfortunately it is too complicated to focus the energy on it today. You can talk to these people about it and may tell you more about it from the perspective of studies they have done so far and feasibility. Maybe they would find a team who may help... was (Author: tibor17): This is a very good idea, we spoke about it with Professor Jonathan Bell and Wing Lam but unfortunately it is too complicated to focus the energy on it today. You can talk to these people about it and may tell you more about it from the perspective of studies they have done so far and feasibility. Maybe they would find a team who may help... > To be able to kill a fork as soon as a test case fails and start a new fork > from the failed testcase, following which subsequent testcases are run. > > > Key: SUREFIRE-1984 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1984 > Project: Maven Surefire > Issue Type: Wish > Components: process forking >Reporter: Rishabh Arora >Priority: Major > Fix For: Backlog > > > I need this feature because some testcases need isolated environment to run. > I have seen that certain testcases fail on an existing fork but seem to run > fine on a new fork. I want to be able to keep the number of active forks same > at all times. Just that kill the fork that executes a failed testcase and > retry on a newly generated fork. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[ https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481485#comment-17481485 ] Tibor Digana commented on SUREFIRE-1984: This is very good idea, we spoke about it with Professor Jonathan Bell and Wing Lam but unfortunately it is too complicated to focus the energy on it today. You can talk to these people about it and may tell you more about it from the perspective of studies they have done so far and feasibility. > To be able to kill a fork as soon as a test case fails and start a new fork > from the failed testcase, following which subsequent testcases are run. > > > Key: SUREFIRE-1984 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1984 > Project: Maven Surefire > Issue Type: Wish > Components: process forking >Reporter: Rishabh Arora >Priority: Major > Fix For: Backlog > > > I need this feature because some testcases need isolated environment to run. > I have seen that certain testcases fail on an existing fork but seem to run > fine on a new fork. I want to be able to keep the number of active forks same > at all times. Just that kill the fork that executes a failed testcase and > retry on a newly generated fork. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1984) To be able to kill a fork as soon as a test case fails and start a new fork from the failed testcase, following which subsequent testcases are run.
[ https://issues.apache.org/jira/browse/SUREFIRE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1984: --- Fix Version/s: Backlog > To be able to kill a fork as soon as a test case fails and start a new fork > from the failed testcase, following which subsequent testcases are run. > > > Key: SUREFIRE-1984 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1984 > Project: Maven Surefire > Issue Type: Wish > Components: process forking >Reporter: Rishabh Arora >Priority: Major > Fix For: Backlog > > > I need this feature because some testcases need isolated environment to run. > I have seen that certain testcases fail on an existing fork but seem to run > fine on a new fork. I want to be able to keep the number of active forks same > at all times. Just that kill the fork that executes a failed testcase and > retry on a newly generated fork. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1985) While running test cases if a test case fails, need to kill the fork and run subsequent testcases(including the failed one) with a new fork
[ https://issues.apache.org/jira/browse/SUREFIRE-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481482#comment-17481482 ] Tibor Digana commented on SUREFIRE-1985: The title and description are talking about opposite. See this documentation https://maven.apache.org/surefire/maven-surefire-plugin/examples/skip-after-failure.html and config parameter there. Do you think it is what you need to have? > While running test cases if a test case fails, need to kill the fork and run > subsequent testcases(including the failed one) with a new fork > - > > Key: SUREFIRE-1985 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1985 > Project: Maven Surefire > Issue Type: Wish > Components: process forking >Reporter: Sanidhya Vijaivargia >Priority: Major > > While running 'n' tests using forks the if a particular testcase fails all > the subsequent test are skipped and can't be executed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-dependency-tree] gnodet commented on pull request #10: Drop maven 3.0 compatibility
gnodet commented on pull request #10: URL: https://github.com/apache/maven-dependency-tree/pull/10#issuecomment-1020680862 > > Yes #6 > > Does this mean this artifact should be deprecated and somehow merged into maven-core ? Same as maven-artifact-transfer / maven-common-artifact-filters ? Something like https://github.com/gnodet/maven/tree/mat ? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1986) New element "rerunSkipped" in XSD of XML Test Report
[ https://issues.apache.org/jira/browse/SUREFIRE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481466#comment-17481466 ] Tibor Digana commented on SUREFIRE-1986: Remove the xml comment and add a new entry. > New element "rerunSkipped" in XSD of XML Test Report > > > Key: SUREFIRE-1986 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1986 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin, Maven Surefire Plugin, xml > generation >Reporter: Tibor Digana >Priority: Major > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SUREFIRE-1986) New element "rerunSkipped" in XSD of XML Test Report
Tibor Digana created SUREFIRE-1986: -- Summary: New element "rerunSkipped" in XSD of XML Test Report Key: SUREFIRE-1986 URL: https://issues.apache.org/jira/browse/SUREFIRE-1986 Project: Maven Surefire Issue Type: New Feature Components: Maven Failsafe Plugin, Maven Surefire Plugin, xml generation Reporter: Tibor Digana Fix For: 3.1.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-dependency-tree] gnodet commented on pull request #10: Drop maven 3.0 compatibility
gnodet commented on pull request #10: URL: https://github.com/apache/maven-dependency-tree/pull/10#issuecomment-1020665163 > Yes #6 Does this mean this artifact should be deprecated and somehow merged into maven-core ? Same as maven-artifact-transfer / maven-common-artifact-filters ? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-tree] slachiewicz commented on pull request #10: Drop maven 3.0 compatibility
slachiewicz commented on pull request #10: URL: https://github.com/apache/maven-dependency-tree/pull/10#issuecomment-1020661630 Yes #6 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-tree] gnodet commented on pull request #10: Drop maven 3.0 compatibility
gnodet commented on pull request #10: URL: https://github.com/apache/maven-dependency-tree/pull/10#issuecomment-1020645308 > That was rejected some time ago What was rejected exactly ? The drop of legacy maven 3.0.x support ? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-774) analyze-only failed: PermittedSubclasses requires ASM9
[
https://issues.apache.org/jira/browse/MDEP-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481447#comment-17481447
]
Pino Silvaggio commented on MDEP-774:
-
Do we have an ETA? Maybe release a milestone ({{-MX}}) version if necessary
(like surefire).
> analyze-only failed: PermittedSubclasses requires ASM9
> --
>
> Key: MDEP-774
> URL: https://issues.apache.org/jira/browse/MDEP-774
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
> Environment: Maven 3.8.2, Adoptium 17, MacOS 11.6
>Reporter: Dan Ziemba
>Assignee: Sylwester Lachiewicz
>Priority: Critical
> Fix For: 3.3.0
>
>
> The analyze-only goal does not work with Java 17 bytecode:
> {noformat}
> Execution dep-analyze of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.2.0:analyze-only failed:
> PermittedSubclasses requires ASM9{noformat}
> Running the same build under the same version of Java 17, but with
> "maven.compiler.release" set to 16 works fine.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MWRAPPER-47) Use name wrapperUrl consistently in Maven Wrapper files/scripts
[ https://issues.apache.org/jira/browse/MWRAPPER-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MWRAPPER-47. - Assignee: Herve Boutemy Resolution: Fixed PR merged in https://github.com/apache/maven-wrapper/commit/7e8d914e18fec85445d5e2cf79eefed73b916ac6 thank you > Use name wrapperUrl consistently in Maven Wrapper files/scripts > --- > > Key: MWRAPPER-47 > URL: https://issues.apache.org/jira/browse/MWRAPPER-47 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Jimisola Laursen >Assignee: Herve Boutemy >Priority: Low > Labels: up-for-grabs > Fix For: 3.1.1 > > > maven-wrapper.properties has two properties: *wrapperUrl* and distributionUrl > However, in the mvnw script the wrapperUrl is stored as jarUrl (no need for > confusion) and after download it is referred to as wrapperJarPath. > Rename jarUrl to wrapperUrl in mvn[.cmd] for consistency. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MWRAPPER-47) Use name wrapperUrl consistently in Maven Wrapper files/scripts
[ https://issues.apache.org/jira/browse/MWRAPPER-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481442#comment-17481442 ] ASF GitHub Bot commented on MWRAPPER-47: hboutemy commented on pull request #14: URL: https://github.com/apache/maven-wrapper/pull/14#issuecomment-1020618355 thank you -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Use name wrapperUrl consistently in Maven Wrapper files/scripts > --- > > Key: MWRAPPER-47 > URL: https://issues.apache.org/jira/browse/MWRAPPER-47 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Jimisola Laursen >Priority: Low > Labels: up-for-grabs > Fix For: 3.1.1 > > > maven-wrapper.properties has two properties: *wrapperUrl* and distributionUrl > However, in the mvnw script the wrapperUrl is stored as jarUrl (no need for > confusion) and after download it is referred to as wrapperJarPath. > Rename jarUrl to wrapperUrl in mvn[.cmd] for consistency. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] hboutemy commented on pull request #14: [MWRAPPER-47] - Use name wrapperUrl consistently in Maven Wrapper files/scripts
hboutemy commented on pull request #14: URL: https://github.com/apache/maven-wrapper/pull/14#issuecomment-1020618355 thank you -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-47) Use name wrapperUrl consistently in Maven Wrapper files/scripts
[ https://issues.apache.org/jira/browse/MWRAPPER-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481441#comment-17481441 ] ASF GitHub Bot commented on MWRAPPER-47: hboutemy merged pull request #14: URL: https://github.com/apache/maven-wrapper/pull/14 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Use name wrapperUrl consistently in Maven Wrapper files/scripts > --- > > Key: MWRAPPER-47 > URL: https://issues.apache.org/jira/browse/MWRAPPER-47 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Jimisola Laursen >Priority: Low > Labels: up-for-grabs > Fix For: 3.1.1 > > > maven-wrapper.properties has two properties: *wrapperUrl* and distributionUrl > However, in the mvnw script the wrapperUrl is stored as jarUrl (no need for > confusion) and after download it is referred to as wrapperJarPath. > Rename jarUrl to wrapperUrl in mvn[.cmd] for consistency. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] hboutemy merged pull request #14: [MWRAPPER-47] - Use name wrapperUrl consistently in Maven Wrapper files/scripts
hboutemy merged pull request #14: URL: https://github.com/apache/maven-wrapper/pull/14 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481437#comment-17481437 ] Tibor Digana edited comment on SUREFIRE-1147 at 1/24/22, 10:26 PM: --- [~NB4L1] What test framework you use? JUnit xxx or TestNG? You have many logs, right? How big they are? You have parallel tests? was (Author: tibor17): [~NB4L1] What test framework you use? JUnit xxx or TestNG? You have many logs, right? How big they are? > Unbounded memory usage when running MANY tests > -- > > Key: SUREFIRE-1147 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1147 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 > Environment: win7, jdk 8u25, mvn 3.2.5 >Reporter: Laurent Claisse >Assignee: Tibor Digana >Priority: Major > Fix For: Backlog > > Attachments: surefire-allocation-traces.png, surefire-leak.png, > surefire-leak2.png, surefire-leak3.png > > > I'm writing concurrency tests, checking that this thing is reproducible, that > other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to > reproduce the leak, the test project is here: > https://github.com/vandekeiser/parallel-stream-fork-join-pool) > I see in VisualVM that the culprit is WrappedReportEntry, which indirectly > holds references to lots of byte[] and char[] (allocation traces and heap > dump pics are included in attachment) > I forked and patched maven-surefire-common, and that makes the leak go. I had > to replace WrappedReportEntry.original by a singleton fake ReportEntry. > Bebefore that i had replaced > Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a > NullOutputStream and the leak was lesser but still here. > My fork of maven-surefire-common is there: > https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. > It IS a patch so i checked the patch checkbox in the issue reporter, but it > is NOT intended to be distributed of course since it is very brutal and basic. > Also in my test project i explicitly deactivated reporting, but that doesn't > make the reporting leak go away at all: > true > false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MWRAPPER-47) Use name wrapperUrl consistently in Maven Wrapper files/scripts
[ https://issues.apache.org/jira/browse/MWRAPPER-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481439#comment-17481439 ] ASF GitHub Bot commented on MWRAPPER-47: hboutemy commented on pull request #14: URL: https://github.com/apache/maven-wrapper/pull/14#issuecomment-1020612858 > Not sure what choices you are referring to (command line option?), but that will be clearer with another Jira issue :) I have no concrete case in mind, just the idea that there may be other cases of such differences between mvnw.cmd and mvnw that could be avoided to have a better consistency -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Use name wrapperUrl consistently in Maven Wrapper files/scripts > --- > > Key: MWRAPPER-47 > URL: https://issues.apache.org/jira/browse/MWRAPPER-47 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Jimisola Laursen >Priority: Low > Labels: up-for-grabs > Fix For: 3.1.1 > > > maven-wrapper.properties has two properties: *wrapperUrl* and distributionUrl > However, in the mvnw script the wrapperUrl is stored as jarUrl (no need for > confusion) and after download it is referred to as wrapperJarPath. > Rename jarUrl to wrapperUrl in mvn[.cmd] for consistency. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] hboutemy commented on pull request #14: [MWRAPPER-47] - Use name wrapperUrl consistently in Maven Wrapper files/scripts
hboutemy commented on pull request #14: URL: https://github.com/apache/maven-wrapper/pull/14#issuecomment-1020612858 > Not sure what choices you are referring to (command line option?), but that will be clearer with another Jira issue :) I have no concrete case in mind, just the idea that there may be other cases of such differences between mvnw.cmd and mvnw that could be avoided to have a better consistency -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481437#comment-17481437 ] Tibor Digana commented on SUREFIRE-1147: [~NB4L1] What test framework you use? JUnit xxx or TestNG? You have many logs, right? How big they are? > Unbounded memory usage when running MANY tests > -- > > Key: SUREFIRE-1147 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1147 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 > Environment: win7, jdk 8u25, mvn 3.2.5 >Reporter: Laurent Claisse >Assignee: Tibor Digana >Priority: Major > Fix For: Backlog > > Attachments: surefire-allocation-traces.png, surefire-leak.png, > surefire-leak2.png, surefire-leak3.png > > > I'm writing concurrency tests, checking that this thing is reproducible, that > other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to > reproduce the leak, the test project is here: > https://github.com/vandekeiser/parallel-stream-fork-join-pool) > I see in VisualVM that the culprit is WrappedReportEntry, which indirectly > holds references to lots of byte[] and char[] (allocation traces and heap > dump pics are included in attachment) > I forked and patched maven-surefire-common, and that makes the leak go. I had > to replace WrappedReportEntry.original by a singleton fake ReportEntry. > Bebefore that i had replaced > Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a > NullOutputStream and the leak was lesser but still here. > My fork of maven-surefire-common is there: > https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. > It IS a patch so i checked the patch checkbox in the issue reporter, but it > is NOT intended to be distributed of course since it is very brutal and basic. > Also in my test project i explicitly deactivated reporting, but that doesn't > make the reporting leak go away at all: > true > false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481435#comment-17481435
]
Balázs Németh commented on SUREFIRE-1147:
-
[~tibordigana] The accumulation of extra memory is slower. It is still there,
but not a problem anymore {_}for us at least{_}. (If I'm not being clear
enough, I'm testing with our business project, not anything artifical.)
> Unbounded memory usage when running MANY tests
> --
>
> Key: SUREFIRE-1147
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1147
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.18.1
> Environment: win7, jdk 8u25, mvn 3.2.5
>Reporter: Laurent Claisse
>Assignee: Tibor Digana
>Priority: Major
> Fix For: Backlog
>
> Attachments: surefire-allocation-traces.png, surefire-leak.png,
> surefire-leak2.png, surefire-leak3.png
>
>
> I'm writing concurrency tests, checking that this thing is reproducible, that
> other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to
> reproduce the leak, the test project is here:
> https://github.com/vandekeiser/parallel-stream-fork-join-pool)
> I see in VisualVM that the culprit is WrappedReportEntry, which indirectly
> holds references to lots of byte[] and char[] (allocation traces and heap
> dump pics are included in attachment)
> I forked and patched maven-surefire-common, and that makes the leak go. I had
> to replace WrappedReportEntry.original by a singleton fake ReportEntry.
> Bebefore that i had replaced
> Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a
> NullOutputStream and the leak was lesser but still here.
> My fork of maven-surefire-common is there:
> https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common.
> It IS a patch so i checked the patch checkbox in the issue reporter, but it
> is NOT intended to be distributed of course since it is very brutal and basic.
> Also in my test project i explicitly deactivated reporting, but that doesn't
> make the reporting leak go away at all:
> true
> false
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481429#comment-17481429 ] Tibor Digana commented on SUREFIRE-1147: The JVM memory usage continuously goes down from 4.4GB to 2.2GB... and TestNG continues on writing the reports down to the disk. > Unbounded memory usage when running MANY tests > -- > > Key: SUREFIRE-1147 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1147 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 > Environment: win7, jdk 8u25, mvn 3.2.5 >Reporter: Laurent Claisse >Assignee: Tibor Digana >Priority: Major > Fix For: Backlog > > Attachments: surefire-allocation-traces.png, surefire-leak.png, > surefire-leak2.png, surefire-leak3.png > > > I'm writing concurrency tests, checking that this thing is reproducible, that > other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to > reproduce the leak, the test project is here: > https://github.com/vandekeiser/parallel-stream-fork-join-pool) > I see in VisualVM that the culprit is WrappedReportEntry, which indirectly > holds references to lots of byte[] and char[] (allocation traces and heap > dump pics are included in attachment) > I forked and patched maven-surefire-common, and that makes the leak go. I had > to replace WrappedReportEntry.original by a singleton fake ReportEntry. > Bebefore that i had replaced > Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a > NullOutputStream and the leak was lesser but still here. > My fork of maven-surefire-common is there: > https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. > It IS a patch so i checked the patch checkbox in the issue reporter, but it > is NOT intended to be distributed of course since it is very brutal and basic. > Also in my test project i explicitly deactivated reporting, but that doesn't > make the reporting leak go away at all: > true > false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481421#comment-17481421 ] Tibor Digana commented on SUREFIRE-1147: [~NB4L1] Slower? What is slower? Now I have changed the version of TestNG from previous version 6.8.x to 7.5, and the JVM has not crashed yet, it is running because the TestNG still creates XML and HTMl reports. > Unbounded memory usage when running MANY tests > -- > > Key: SUREFIRE-1147 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1147 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 > Environment: win7, jdk 8u25, mvn 3.2.5 >Reporter: Laurent Claisse >Assignee: Tibor Digana >Priority: Major > Fix For: Backlog > > Attachments: surefire-allocation-traces.png, surefire-leak.png, > surefire-leak2.png, surefire-leak3.png > > > I'm writing concurrency tests, checking that this thing is reproducible, that > other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to > reproduce the leak, the test project is here: > https://github.com/vandekeiser/parallel-stream-fork-join-pool) > I see in VisualVM that the culprit is WrappedReportEntry, which indirectly > holds references to lots of byte[] and char[] (allocation traces and heap > dump pics are included in attachment) > I forked and patched maven-surefire-common, and that makes the leak go. I had > to replace WrappedReportEntry.original by a singleton fake ReportEntry. > Bebefore that i had replaced > Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a > NullOutputStream and the leak was lesser but still here. > My fork of maven-surefire-common is there: > https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. > It IS a patch so i checked the patch checkbox in the issue reporter, but it > is NOT intended to be distributed of course since it is very brutal and basic. > Also in my test project i explicitly deactivated reporting, but that doesn't > make the reporting leak go away at all: > true > false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481411#comment-17481411 ] Balázs Németh commented on SUREFIRE-1147: - The issue I noticed was the constantly increasing memory usage of the "Launcher" JVM process in JUnit, and had nothing to do with "ForkedBooter" where the tests were actually executed. Anyway it's still happening with the fix, but it's much slower so it seems acceptable. > Unbounded memory usage when running MANY tests > -- > > Key: SUREFIRE-1147 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1147 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 > Environment: win7, jdk 8u25, mvn 3.2.5 >Reporter: Laurent Claisse >Assignee: Tibor Digana >Priority: Major > Fix For: Backlog > > Attachments: surefire-allocation-traces.png, surefire-leak.png, > surefire-leak2.png, surefire-leak3.png > > > I'm writing concurrency tests, checking that this thing is reproducible, that > other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to > reproduce the leak, the test project is here: > https://github.com/vandekeiser/parallel-stream-fork-join-pool) > I see in VisualVM that the culprit is WrappedReportEntry, which indirectly > holds references to lots of byte[] and char[] (allocation traces and heap > dump pics are included in attachment) > I forked and patched maven-surefire-common, and that makes the leak go. I had > to replace WrappedReportEntry.original by a singleton fake ReportEntry. > Bebefore that i had replaced > Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a > NullOutputStream and the leak was lesser but still here. > My fork of maven-surefire-common is there: > https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. > It IS a patch so i checked the patch checkbox in the issue reporter, but it > is NOT intended to be distributed of course since it is very brutal and basic. > Also in my test project i explicitly deactivated reporting, but that doesn't > make the reporting leak go away at all: > true > false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481407#comment-17481407
]
Tibor Digana commented on SUREFIRE-1147:
[~NB4L1]
See my comment, 26 min ago, and the problem is that the OOM does not happen in
the plugin JVM. Notice that `Utf8RecodingDeferredFileOutputStream` appears only
in the plugin JVM. The OOM does not happen in plugin JVM. The OOM happens in
the forked JVM and I can prove it by the stack trace. What it means? It means
that substituting `Utf8RecodingDeferredFileOutputStream` won't help of course
because the problem is in another JVM. It is in the JVM where the tests reside
and it means that the problem is with the design of the tests itself.
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on
project parallel-stream: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test failed: There was an
error in the forked process
[ERROR] java.lang.OutOfMemoryError: Java heap space
[ERROR] at java.util.Arrays.copyOf(Arrays.java:3332)
[ERROR] at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
[ERROR] at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
[ERROR] at java.lang.StringBuffer.append(StringBuffer.java:270)
[ERROR] at
org.testng.reporters.TestHTMLReporter.generateTable(TestHTMLReporter.java:85)
[ERROR] at
org.testng.reporters.TestHTMLReporter.generateLog(TestHTMLReporter.java:312)
[ERROR] at
org.testng.reporters.TestHTMLReporter.onFinish(TestHTMLReporter.java:40)
[ERROR] at org.testng.TestRunner.fireEvent(TestRunner.java:1244)
[ERROR] at org.testng.TestRunner.afterRun(TestRunner.java:1035)
[ERROR] at org.testng.TestRunner.run(TestRunner.java:621)
[ERROR] at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
[ERROR] at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343)
[ERROR] at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
[ERROR] at org.testng.SuiteRunner.run(SuiteRunner.java:254)
[ERROR] at
org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
[ERROR] at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
[ERROR] at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
[ERROR] at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
[ERROR] at org.testng.TestNG.run(TestNG.java:1057)
[ERROR] at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:115)
[ERROR] at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:129)
[ERROR] at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:113)
[ERROR] at
org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:111)
[ERROR] at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
[ERROR] at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
[ERROR] at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{noformat}
> Unbounded memory usage when running MANY tests
> --
>
> Key: SUREFIRE-1147
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1147
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.18.1
> Environment: win7, jdk 8u25, mvn 3.2.5
>Reporter: Laurent Claisse
>Assignee: Tibor Digana
>Priority: Major
> Fix For: Backlog
>
> Attachments: surefire-allocation-traces.png, surefire-leak.png,
> surefire-leak2.png, surefire-leak3.png
>
>
> I'm writing concurrency tests, checking that this thing is reproducible, that
> other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to
> reproduce the leak, the test project is here:
> https://github.com/vandekeiser/parallel-stream-fork-join-pool)
> I see in VisualVM that the culprit is WrappedReportEntry, which indirectly
> holds references to lots of byte[] and char[] (allocation traces and heap
> dump pics are included in attachment)
> I forked and patched maven-surefire-common, and that makes the leak go. I had
> to replace WrappedReportEntry.original by a singleton fake ReportEntry.
> Bebefore that i had replaced
> Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a
> NullOutputStream and the leak was lesser but still here.
> My fork of maven-surefire-common is there:
> https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common.
[GitHub] [maven-archetypes] michael-o commented on pull request #9: [MARCHETYPES-73] Add image referenced by skin
michael-o commented on pull request #9: URL: https://github.com/apache/maven-archetypes/pull/9#issuecomment-1020558482 Intersting...likely it was assumed that it comes with default skin already... -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481391#comment-17481391 ] Balázs Németh commented on SUREFIRE-1147: - Well, I would rather say mitigated. It is still happening, but with a smaller effect. Even as described in the issue itself "Bebefore that i had replaced Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a NullOutputStream and the leak was lesser but still here.". > Unbounded memory usage when running MANY tests > -- > > Key: SUREFIRE-1147 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1147 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 > Environment: win7, jdk 8u25, mvn 3.2.5 >Reporter: Laurent Claisse >Assignee: Tibor Digana >Priority: Major > Fix For: Backlog > > Attachments: surefire-allocation-traces.png, surefire-leak.png, > surefire-leak2.png, surefire-leak3.png > > > I'm writing concurrency tests, checking that this thing is reproducible, that > other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to > reproduce the leak, the test project is here: > https://github.com/vandekeiser/parallel-stream-fork-join-pool) > I see in VisualVM that the culprit is WrappedReportEntry, which indirectly > holds references to lots of byte[] and char[] (allocation traces and heap > dump pics are included in attachment) > I forked and patched maven-surefire-common, and that makes the leak go. I had > to replace WrappedReportEntry.original by a singleton fake ReportEntry. > Bebefore that i had replaced > Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a > NullOutputStream and the leak was lesser but still here. > My fork of maven-surefire-common is there: > https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. > It IS a patch so i checked the patch checkbox in the issue reporter, but it > is NOT intended to be distributed of course since it is very brutal and basic. > Also in my test project i explicitly deactivated reporting, but that doesn't > make the reporting leak go away at all: > true > false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481390#comment-17481390
]
Tibor Digana commented on SUREFIRE-1147:
[~chtimi59]
I used the project
https://github.com/vandekeiser/parallel-stream-fork-join-pool of the author of
this ticket.
After analysis of the code and after setting {{TEST_TIMES = 100_000}} in the
test, I have to say that the OOM is expected in the surefire forked JVM because
the parallel tests trigger parallel and reuse-able threads which handle the
objects created in all executions of parallel test method and they won't be
reclaimed.
> Unbounded memory usage when running MANY tests
> --
>
> Key: SUREFIRE-1147
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1147
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.18.1
> Environment: win7, jdk 8u25, mvn 3.2.5
>Reporter: Laurent Claisse
>Assignee: Tibor Digana
>Priority: Major
> Fix For: Backlog
>
> Attachments: surefire-allocation-traces.png, surefire-leak.png,
> surefire-leak2.png, surefire-leak3.png
>
>
> I'm writing concurrency tests, checking that this thing is reproducible, that
> other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to
> reproduce the leak, the test project is here:
> https://github.com/vandekeiser/parallel-stream-fork-join-pool)
> I see in VisualVM that the culprit is WrappedReportEntry, which indirectly
> holds references to lots of byte[] and char[] (allocation traces and heap
> dump pics are included in attachment)
> I forked and patched maven-surefire-common, and that makes the leak go. I had
> to replace WrappedReportEntry.original by a singleton fake ReportEntry.
> Bebefore that i had replaced
> Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a
> NullOutputStream and the leak was lesser but still here.
> My fork of maven-surefire-common is there:
> https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common.
> It IS a patch so i checked the patch checkbox in the issue reporter, but it
> is NOT intended to be distributed of course since it is very brutal and basic.
> Also in my test project i explicitly deactivated reporting, but that doesn't
> make the reporting leak go away at all:
> true
> false
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-doxia-sitetools] pzygielo commented on pull request #26: (doc) Switch to raw HTML to fix rendering of published page
pzygielo commented on pull request #26: URL: https://github.com/apache/maven-doxia-sitetools/pull/26#issuecomment-1020537390 > Was it supposed to generate Javadoc and our extractor does not read that? I only know that - #17 helped with build. But not with site. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-doxia-sitetools] pzygielo opened a new pull request #26: (doc) Switch to raw HTML to fix rendering of published page
pzygielo opened a new pull request #26: URL: https://github.com/apache/maven-doxia-sitetools/pull/26 Change  to  -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481357#comment-17481357 ] Tibor Digana edited comment on SUREFIRE-1147 at 1/24/22, 7:58 PM: -- [~NB4L1] I am convinced that I fixed this bug in SUREFIRE-1845. Please see the [changes|https://github.com/apache/maven-surefire/commit/32bd56b4ea908147592ef92c71c4e7936e070993] and run a test with the version *3.0.0-M6-SNAPSHOT*. The plugin can be found in the ASF repository https://repository.apache.org/content/repositories/snapshots/org/apache/maven/surefire/surefire/3.0.0-M6-SNAPSHOT/ was (Author: tibor17): [~NB4L1] I am convinced that I fixed this bug in SUREFIRE-1845. Please see the [changes|https://github.com/apache/maven-surefire/commit/32bd56b4ea908147592ef92c71c4e7936e070993] and run a test with the version *3.0.0-M6-SNAPSHOT*. The plugin can be found in the ASF repository repository.apache.org/content/repositories/snapshots/org/apache/maven/surefire/surefire/3.0.0-M6-SNAPSHOT/ > Unbounded memory usage when running MANY tests > -- > > Key: SUREFIRE-1147 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1147 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 > Environment: win7, jdk 8u25, mvn 3.2.5 >Reporter: Laurent Claisse >Assignee: Tibor Digana >Priority: Major > Fix For: Backlog > > Attachments: surefire-allocation-traces.png, surefire-leak.png, > surefire-leak2.png, surefire-leak3.png > > > I'm writing concurrency tests, checking that this thing is reproducible, that > other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to > reproduce the leak, the test project is here: > https://github.com/vandekeiser/parallel-stream-fork-join-pool) > I see in VisualVM that the culprit is WrappedReportEntry, which indirectly > holds references to lots of byte[] and char[] (allocation traces and heap > dump pics are included in attachment) > I forked and patched maven-surefire-common, and that makes the leak go. I had > to replace WrappedReportEntry.original by a singleton fake ReportEntry. > Bebefore that i had replaced > Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a > NullOutputStream and the leak was lesser but still here. > My fork of maven-surefire-common is there: > https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. > It IS a patch so i checked the patch checkbox in the issue reporter, but it > is NOT intended to be distributed of course since it is very brutal and basic. > Also in my test project i explicitly deactivated reporting, but that doesn't > make the reporting leak go away at all: > true > false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481357#comment-17481357 ] Tibor Digana commented on SUREFIRE-1147: [~NB4L1] I am convinced that I fixed this bug in SUREFIRE-1845. Please see the [changes|https://github.com/apache/maven-surefire/commit/32bd56b4ea908147592ef92c71c4e7936e070993] and run a test with the version *3.0.0-M6-SNAPSHOT*. The plugin can be found in the ASF repository repository.apache.org/content/repositories/snapshots/org/apache/maven/surefire/surefire/3.0.0-M6-SNAPSHOT/ > Unbounded memory usage when running MANY tests > -- > > Key: SUREFIRE-1147 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1147 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 > Environment: win7, jdk 8u25, mvn 3.2.5 >Reporter: Laurent Claisse >Assignee: Tibor Digana >Priority: Major > Fix For: Backlog > > Attachments: surefire-allocation-traces.png, surefire-leak.png, > surefire-leak2.png, surefire-leak3.png > > > I'm writing concurrency tests, checking that this thing is reproducible, that > other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to > reproduce the leak, the test project is here: > https://github.com/vandekeiser/parallel-stream-fork-join-pool) > I see in VisualVM that the culprit is WrappedReportEntry, which indirectly > holds references to lots of byte[] and char[] (allocation traces and heap > dump pics are included in attachment) > I forked and patched maven-surefire-common, and that makes the leak go. I had > to replace WrappedReportEntry.original by a singleton fake ReportEntry. > Bebefore that i had replaced > Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a > NullOutputStream and the leak was lesser but still here. > My fork of maven-surefire-common is there: > https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. > It IS a patch so i checked the patch checkbox in the issue reporter, but it > is NOT intended to be distributed of course since it is very brutal and basic. > Also in my test project i explicitly deactivated reporting, but that doesn't > make the reporting leak go away at all: > true > false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resolver] gnodet commented on pull request #147: Auto formatting
gnodet commented on pull request #147: URL: https://github.com/apache/maven-resolver/pull/147#issuecomment-1020478388 > > @gnodet what IDE and what style you use? > > nvm, I see this is a plugin... The point is that the code is reformatted and the imports automatically organized. It saves a bit of time ... The two plugins are quite fast, especially as they do not process the files if they haven't been changed. The checkstyle / code formatter have been somewhat aligned to maven codestyle. Ideally, the configuration files would be shared between all maven repos. I already reused those from https://github.com/apache/maven-build-cache-extension. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481343#comment-17481343 ] Balázs Németh edited comment on SUREFIRE-1147 at 1/24/22, 7:35 PM: --- [https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1845] most likely mitigated the issue considerably. ( [https://github.com/apache/maven-surefire/commit/32bd56b4ea908147592ef92c71c4e7936e070993] ) was (Author: JIRAUSER284124): [https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1845] most likely mitigated the issue considerably. > Unbounded memory usage when running MANY tests > -- > > Key: SUREFIRE-1147 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1147 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 > Environment: win7, jdk 8u25, mvn 3.2.5 >Reporter: Laurent Claisse >Assignee: Tibor Digana >Priority: Major > Fix For: Backlog > > Attachments: surefire-allocation-traces.png, surefire-leak.png, > surefire-leak2.png, surefire-leak3.png > > > I'm writing concurrency tests, checking that this thing is reproducible, that > other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to > reproduce the leak, the test project is here: > https://github.com/vandekeiser/parallel-stream-fork-join-pool) > I see in VisualVM that the culprit is WrappedReportEntry, which indirectly > holds references to lots of byte[] and char[] (allocation traces and heap > dump pics are included in attachment) > I forked and patched maven-surefire-common, and that makes the leak go. I had > to replace WrappedReportEntry.original by a singleton fake ReportEntry. > Bebefore that i had replaced > Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a > NullOutputStream and the leak was lesser but still here. > My fork of maven-surefire-common is there: > https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. > It IS a patch so i checked the patch checkbox in the issue reporter, but it > is NOT intended to be distributed of course since it is very brutal and basic. > Also in my test project i explicitly deactivated reporting, but that doesn't > make the reporting leak go away at all: > true > false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481343#comment-17481343 ] Balázs Németh commented on SUREFIRE-1147: - [https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1845] most likely mitigated the issue considerably. > Unbounded memory usage when running MANY tests > -- > > Key: SUREFIRE-1147 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1147 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 > Environment: win7, jdk 8u25, mvn 3.2.5 >Reporter: Laurent Claisse >Assignee: Tibor Digana >Priority: Major > Fix For: Backlog > > Attachments: surefire-allocation-traces.png, surefire-leak.png, > surefire-leak2.png, surefire-leak3.png > > > I'm writing concurrency tests, checking that this thing is reproducible, that > other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to > reproduce the leak, the test project is here: > https://github.com/vandekeiser/parallel-stream-fork-join-pool) > I see in VisualVM that the culprit is WrappedReportEntry, which indirectly > holds references to lots of byte[] and char[] (allocation traces and heap > dump pics are included in attachment) > I forked and patched maven-surefire-common, and that makes the leak go. I had > to replace WrappedReportEntry.original by a singleton fake ReportEntry. > Bebefore that i had replaced > Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a > NullOutputStream and the leak was lesser but still here. > My fork of maven-surefire-common is there: > https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. > It IS a patch so i checked the patch checkbox in the issue reporter, but it > is NOT intended to be distributed of course since it is very brutal and basic. > Also in my test project i explicitly deactivated reporting, but that doesn't > make the reporting leak go away at all: > true > false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resolver] cstamas commented on pull request #147: Auto formatting
cstamas commented on pull request #147: URL: https://github.com/apache/maven-resolver/pull/147#issuecomment-1020456767 > @gnodet what IDE and what style you use? nvm, I see this is a plugin... -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on pull request #147: Auto formatting
cstamas commented on pull request #147: URL: https://github.com/apache/maven-resolver/pull/147#issuecomment-1020455757 @gnodet what IDE and what style you use? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
Tibor17 commented on pull request #398: URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-102024 @slawekjaranowski I did not mean TesNG provider info. I only compared two classes. I meant `DynamicProviderInfo`. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski closed pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
slawekjaranowski closed pull request #398: URL: https://github.com/apache/maven-surefire/pull/398 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
slawekjaranowski commented on pull request #398: URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-1020391061 Sorry but I was deleted branch from my fork ... I need to recreate PR: #445 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski opened a new pull request #445: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
slawekjaranowski opened a new pull request #445: URL: https://github.com/apache/maven-surefire/pull/445 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
slawekjaranowski commented on pull request #398:
URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-1020382408
`TestNgProviderInfo( ).isApplicable()` has implementation:
```java
public boolean isApplicable()
{
return testNgArtifact != null;
}
```
so return `true` for any TestNg artifact
I didn't change production code ... I just wrote tests to show current
situation
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
slawekjaranowski commented on pull request #398:
URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-1020376819
`ProviderDetector` was inner class in `AbstractSurefireMojo` I didn't change
method:
```java
@Nonnull private List autoDetectOneWellKnownProvider()
{
List providersToRun = new ArrayList<>();
for ( ProviderInfo wellKnownProvider : wellKnownProviders )
{
if ( wellKnownProvider.isApplicable() )
{
providersToRun.add( wellKnownProvider );
return providersToRun;
}
}
return providersToRun;
}
```
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on pull request #147: Auto formatting
michael-o commented on pull request #147: URL: https://github.com/apache/maven-resolver/pull/147#issuecomment-1020376478 What has applied the automagic? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7396) Allow specification of additional plugin-repositories in extensions.xml
[ https://issues.apache.org/jira/browse/MNG-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481254#comment-17481254 ] Michael Osipov commented on MNG-7396: - Yes, pity the message is wrong. This is something we need to fix for Maven 4. > Allow specification of additional plugin-repositories in extensions.xml > --- > > Key: MNG-7396 > URL: https://issues.apache.org/jira/browse/MNG-7396 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > Attachments: testit.zip > > > Currently the only way is a settings.xml and default activated profiles are > even ignored see https://issues.apache.org/jira/browse/MNG-5984 > I'd like to propose to allow specifying (additional) plugin repositories > directly in the extensions.xml this would make it much clearer and flexible > (e.g. in case one likes to use snapshots but don't want to force everyone to > add / specify a settings.xml). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] rmannibucau commented on pull request #665: MNG-7395 - Support system-properties in extension.xml
rmannibucau commented on pull request #665: URL: https://github.com/apache/maven/pull/665#issuecomment-1020286812 I don't see the need for that since in the pom you can set in properties `1.2.3` and override it with `-Dmyextension.version` in maven's spirit. Anything else just creates something inconsistent without new real features so better to ensure the "on the fly plugin" is processed as any model instead of making it specific (and lacking env support for ex), no? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7396) Allow specification of additional plugin-repositories in extensions.xml
[ https://issues.apache.org/jira/browse/MNG-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481229#comment-17481229 ] Christoph Läubrich commented on MNG-7396: - I have added an example. Running 'mvn verify' works as the extension is downloaded from maven central. Now I change this to a snapshot version and get: Failed to read extensions descriptor *Plugin* org.eclipse.tycho.extras:tycho-pomless:2.7.0-SNAPSHOT or one of its dependencies could not be resolved: Could not find artifact org.eclipse.tycho.extras:tycho-pomless:jar:2.7.0-SNAPSHOT (but build still proceeds). So what users first try is to specify the repository in pom.xml (what obviously do not work at all), allowing to specify it in extension.xml file would be the next logical choice (if it would be supported) :-) > Allow specification of additional plugin-repositories in extensions.xml > --- > > Key: MNG-7396 > URL: https://issues.apache.org/jira/browse/MNG-7396 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > Attachments: testit.zip > > > Currently the only way is a settings.xml and default activated profiles are > even ignored see https://issues.apache.org/jira/browse/MNG-5984 > I'd like to propose to allow specifying (additional) plugin repositories > directly in the extensions.xml this would make it much clearer and flexible > (e.g. in case one likes to use snapshots but don't want to force everyone to > add / specify a settings.xml). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
Tibor17 edited a comment on pull request #398: URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-1020276839 `new TestNgProviderInfo( null ).isApplicable()` returns `false` but `new DynamicProviderInfo( ... ).isApplicable()` always returns `true`. We have to decide whether the parameter of the constructor will be `@Nunnull` or the method `isApplicable()` would respect the parameter in its return value. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
Tibor17 commented on pull request #398: URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-1020276839 `new TestNgProviderInfo( null ).isApplicable()` returns `false` but `new DynamicProviderInfo( ... ).isApplicable()` always returns `true`. We have to decide whether the parameter of the constructor will be `@Nunnull` or the method `isApplicable()` would respect that parameter in its return value. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7396) Allow specification of additional plugin-repositories in extensions.xml
[ https://issues.apache.org/jira/browse/MNG-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Läubrich updated MNG-7396: Attachment: testit.zip > Allow specification of additional plugin-repositories in extensions.xml > --- > > Key: MNG-7396 > URL: https://issues.apache.org/jira/browse/MNG-7396 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > Attachments: testit.zip > > > Currently the only way is a settings.xml and default activated profiles are > even ignored see https://issues.apache.org/jira/browse/MNG-5984 > I'd like to propose to allow specifying (additional) plugin repositories > directly in the extensions.xml this would make it much clearer and flexible > (e.g. in case one likes to use snapshots but don't want to force everyone to > add / specify a settings.xml). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7396) Allow specification of additional plugin-repositories in extensions.xml
[ https://issues.apache.org/jira/browse/MNG-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481226#comment-17481226 ] Michael Osipov commented on MNG-7396: - Alright, you should generalize your request. > Allow specification of additional plugin-repositories in extensions.xml > --- > > Key: MNG-7396 > URL: https://issues.apache.org/jira/browse/MNG-7396 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > Currently the only way is a settings.xml and default activated profiles are > even ignored see https://issues.apache.org/jira/browse/MNG-5984 > I'd like to propose to allow specifying (additional) plugin repositories > directly in the extensions.xml this would make it much clearer and flexible > (e.g. in case one likes to use snapshots but don't want to force everyone to > add / specify a settings.xml). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] michael-o edited a comment on pull request #665: MNG-7395 - Support system-properties in extension.xml
michael-o edited a comment on pull request #665:
URL: https://github.com/apache/maven/pull/665#issuecomment-1020273161
> > * If we are going to allow default values, the approach would be a
subset of this
>
> So you suggest something like:
>
> `${tycho-version:=2.6.0}`
>
> to have default values?
Rather `parameter:-word`, but depends on the conditions describes in the
table.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #665: MNG-7395 - Support system-properties in extension.xml
michael-o commented on pull request #665:
URL: https://github.com/apache/maven/pull/665#issuecomment-1020273161
> > * If we are going to allow default values, the approach would be a
subset of this
>
> So you suggest something like:
>
> `${tycho-version:=2.6.0}`
>
> to have default values?
Rather `parameter:-word`
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7396) Allow specification of additional plugin-repositories in extensions.xml
[ https://issues.apache.org/jira/browse/MNG-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481220#comment-17481220 ] Christoph Läubrich commented on MNG-7396: - I don't mind as far as it works :-) >From my experience (maven 3.8.x) and looking at the code it specifically loads >extensions as "plugins" and thus uses the "pluginRepositories" but I'm >only using maven as a build tool so I might using the naming incorrectly here. > Allow specification of additional plugin-repositories in extensions.xml > --- > > Key: MNG-7396 > URL: https://issues.apache.org/jira/browse/MNG-7396 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > Currently the only way is a settings.xml and default activated profiles are > even ignored see https://issues.apache.org/jira/browse/MNG-5984 > I'd like to propose to allow specifying (additional) plugin repositories > directly in the extensions.xml this would make it much clearer and flexible > (e.g. in case one likes to use snapshots but don't want to force everyone to > add / specify a settings.xml). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] laeubi commented on pull request #665: MNG-7395 - Support system-properties in extension.xml
laeubi commented on pull request #665:
URL: https://github.com/apache/maven/pull/665#issuecomment-1020264550
> * If we are going to allow default values, the approach would be a subset
of this
So you suggest something like:
`${tycho-version:=2.6.0}`
to have default values?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7396) Allow specification of additional plugin-repositories in extensions.xml
[ https://issues.apache.org/jira/browse/MNG-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481218#comment-17481218 ] Michael Osipov commented on MNG-7396: - But I still don't understand why this needs to be a plugin repo after all. Why is regular repo support not sufficient here? > Allow specification of additional plugin-repositories in extensions.xml > --- > > Key: MNG-7396 > URL: https://issues.apache.org/jira/browse/MNG-7396 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > Currently the only way is a settings.xml and default activated profiles are > even ignored see https://issues.apache.org/jira/browse/MNG-5984 > I'd like to propose to allow specifying (additional) plugin repositories > directly in the extensions.xml this would make it much clearer and flexible > (e.g. in case one likes to use snapshots but don't want to force everyone to > add / specify a settings.xml). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MNG-7396) Allow specification of additional plugin-repositories in extensions.xml
[ https://issues.apache.org/jira/browse/MNG-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481204#comment-17481204 ] Michael Osipov edited comment on MNG-7396 at 1/24/22, 4:06 PM: --- 1. True 2. Well, they are currently somewhat handled like plugins, we have recently discussed that with [~gnodet] 3. Yes, that true. My bad. Those repos are only availabe when the Maven session is up and running. So as far as I understand you have a plugin which is an extension also that is why you need this feature? was (Author: michael-o): 1. True 2. Well, they are currently somewhat handled like plugins, we have recently discussed that with [~gnodet] 3. Yes, that true. My bad. Those repos are only availabe when the Maven session is up and running. So af far as I understand you have a plugin which is an extension also that is why you need this feature? > Allow specification of additional plugin-repositories in extensions.xml > --- > > Key: MNG-7396 > URL: https://issues.apache.org/jira/browse/MNG-7396 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > Currently the only way is a settings.xml and default activated profiles are > even ignored see https://issues.apache.org/jira/browse/MNG-5984 > I'd like to propose to allow specifying (additional) plugin repositories > directly in the extensions.xml this would make it much clearer and flexible > (e.g. in case one likes to use snapshots but don't want to force everyone to > add / specify a settings.xml). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
Tibor17 commented on pull request #398: URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-1020257072 Perhaps you meant the name of test `dynamicProviderAreAlwaysAvailable()` be `dynamicProviderAreAlwaysApplicable()`. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] dependabot[bot] opened a new pull request #137: Bump mockito.version from 4.2.0 to 4.3.0
dependabot[bot] opened a new pull request #137: URL: https://github.com/apache/maven-enforcer/pull/137 Bumps `mockito.version` from 4.2.0 to 4.3.0. Updates `mockito-core` from 4.2.0 to 4.3.0 Release notes Sourced from https://github.com/mockito/mockito/releases;>mockito-core's releases. v4.3.0 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 4.3.0 2022-01-24 - https://github.com/mockito/mockito/compare/v4.2.0...v4.3.0;>20 commit(s) by Andrew Kozel, John Pyeatt, Liam Miller-Cushon, Thomas Keller, Tim van der Lippe, dependabot[bot], temp-droid Fixes https://github-redirect.dependabot.com/mockito/mockito/issues/2489;>#2489 : Fixed issue related to exceptions thrown from the nested spies [(https://github-redirect.dependabot.com/mockito/mockito/issues/2546;>#2546)](https://github-redirect.dependabot.com/mockito/mockito/pull/2546;>mockito/mockito#2546) Issue 2544 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2545;>#2545)](https://github-redirect.dependabot.com/mockito/mockito/pull/2545;>mockito/mockito#2545) Bump versions.bytebuddy from 1.12.6 to 1.12.7 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2543;>#2543)](https://github-redirect.dependabot.com/mockito/mockito/pull/2543;>mockito/mockito#2543) Bump com.diffplug.spotless from 6.1.2 to 6.2.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2542;>#2542)](https://github-redirect.dependabot.com/mockito/mockito/pull/2542;>mockito/mockito#2542) Bump material from 1.4.0 to 1.5.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2541;>#2541)](https://github-redirect.dependabot.com/mockito/mockito/pull/2541;>mockito/mockito#2541) Bump appcompat from 1.4.0 to 1.4.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2539;>#2539)](https://github-redirect.dependabot.com/mockito/mockito/pull/2539;>mockito/mockito#2539) Bump com.diffplug.spotless from 6.1.1 to 6.1.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2536;>#2536)](https://github-redirect.dependabot.com/mockito/mockito/pull/2536;>mockito/mockito#2536) Remove an @link [(https://github-redirect.dependabot.com/mockito/mockito/issues/2535;>#2535)](https://github-redirect.dependabot.com/mockito/mockito/pull/2535;>mockito/mockito#2535) Bump com.diffplug.spotless from 6.1.0 to 6.1.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2534;>#2534)](https://github-redirect.dependabot.com/mockito/mockito/pull/2534;>mockito/mockito#2534) Bump com.github.ben-manes.versions from 0.40.0 to 0.41.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2533;>#2533)](https://github-redirect.dependabot.com/mockito/mockito/pull/2533;>mockito/mockito#2533) Bump assertj-core from 3.21.0 to 3.22.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2531;>#2531)](https://github-redirect.dependabot.com/mockito/mockito/pull/2531;>mockito/mockito#2531) Bump com.github.ben-manes.versions from 0.39.0 to 0.40.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2529;>#2529)](https://github-redirect.dependabot.com/mockito/mockito/pull/2529;>mockito/mockito#2529) Bump com.diffplug.spotless from 6.0.5 to 6.1.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2527;>#2527)](https://github-redirect.dependabot.com/mockito/mockito/pull/2527;>mockito/mockito#2527) Bump kotlinx-coroutines-core from 1.5.2-native-mt to 1.6.0-native-mt [(https://github-redirect.dependabot.com/mockito/mockito/issues/2526;>#2526)](https://github-redirect.dependabot.com/mockito/mockito/pull/2526;>mockito/mockito#2526) Bump versions.bytebuddy from 1.12.5 to 1.12.6 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2524;>#2524)](https://github-redirect.dependabot.com/mockito/mockito/pull/2524;>mockito/mockito#2524) Bump com.diffplug.spotless from 6.0.4 to 6.0.5 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2520;>#2520)](https://github-redirect.dependabot.com/mockito/mockito/pull/2520;>mockito/mockito#2520) Bump versions.bytebuddy from 1.12.4 to 1.12.5 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2519;>#2519)](https://github-redirect.dependabot.com/mockito/mockito/pull/2519;>mockito/mockito#2519) Fixes https://github-redirect.dependabot.com/mockito/mockito/issues/2510;>#2510: Remove ExpectedException from internal test suite [(https://github-redirect.dependabot.com/mockito/mockito/issues/2518;>#2518)](https://github-redirect.dependabot.com/mockito/mockito/pull/2518;>mockito/mockito#2518) Fix JavaDoc warnings and enforce zero errors in Gradle [(https://github-redirect.dependabot.com/mockito/mockito/issues/2513;>#2513)](https://github-redirect.dependabot.com/mockito/mockito/pull/2513;>mockito/mockito#2513) Remove ExpectedException from internal test suite
[jira] [Commented] (MNG-7396) Allow specification of additional plugin-repositories in extensions.xml
[
https://issues.apache.org/jira/browse/MNG-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481210#comment-17481210
]
Christoph Läubrich commented on MNG-7396:
-
I won't mind a "extensions" repository if that's more descriptive :-)
Lets say I have:
{code:xml}
org.eclipse.tycho
tycho-build
2.7.0-SNAPSHOT
{code}
This works, if I install the snapshot in the local repository, or if I have
configured a snapshot-(plugin)-repository with a profile and activate that
profile (default will not work as described in the linked bug).
We generally ask people to test our SNAPSHOTs early and often (see
https://github.com/eclipse/tycho/wiki#getting-tycho-snapshots ) but need to add
a special note about the maven-core extension as it is not obvious (at least to
the usual maven user at it seems) how to do this.
If I now could have something like (as mention before I dont mind naming it
extensionsRepositories):
{code:xml}
org.eclipse.tycho
tycho-build
2.7.0-SNAPSHOT
tycho-snapshots
https://repo.eclipse.org/content/repositories/tycho-snapshots/
{code}
this would easily allow people to test snapshots even if the are not in control
of the maven build settings.
Also this would be good if I don't use snapshots but a non-default repository,
this is somewhat similar to define one in the pom.xml.
> Allow specification of additional plugin-repositories in extensions.xml
> ---
>
> Key: MNG-7396
> URL: https://issues.apache.org/jira/browse/MNG-7396
> Project: Maven
> Issue Type: Improvement
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Currently the only way is a settings.xml and default activated profiles are
> even ignored see https://issues.apache.org/jira/browse/MNG-5984
> I'd like to propose to allow specifying (additional) plugin repositories
> directly in the extensions.xml this would make it much clearer and flexible
> (e.g. in case one likes to use snapshots but don't want to force everyone to
> add / specify a settings.xml).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
Tibor17 edited a comment on pull request #398: URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-1020245043 @slawekjaranowski I have one question. Why the method `ProviderDetector.autoDetectOneWellKnownProvider(): List` returns only one object in List? It was like this before your refactoring as well? Acctually it should return just one, and the caller should make the singleton List. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #398: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
Tibor17 edited a comment on pull request #398: URL: https://github.com/apache/maven-surefire/pull/398#issuecomment-1020245043 @slawekjaranowski I have one question. Why the method `ProviderDetector.autoDetectOneWellKnownProvider(): List` returns only one object in List? It was like this before your refactoring 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
