[GitHub] [maven] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
laeubi commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065819288 I'm not sure if I can give more input on this, but only quote this > it really depends on the use case `WorkspaceReader` and `AbstractMavenLifecycleParticipant` are special because they are a mean of bootstrap and/or add additional look-ups on a global level, but at the same time they are very limited and require special care, e.g. as noted above depending on how an `AbstractMavenLifecycleParticipant` is provided not all methods are called and `WorkspaceReader` for example has no access to any project or session context. Anyways I don't think one could assume that one *always* wan't to lookup everything from all project extensions, similar to when I define a mirror in a pom.xml I for sure don't want it to be used in other (unrelated) modules just because they are part of the same reactor, if I want this then I define it on the settings.xml ... So for your case, if you really thing your extension should be defined on the project level, then for me it makes totally sense that this is only available in the projects where it is defined (either explicit or implicit e.g. though parent reference) and then your extension would not be looked up globally. If you want ti to act globally independent of defined in a project and you want to have much more control I think it should be a core-extension even if others not so involved in the details think "it might be useful" to define it on the project level. @michael-o maybe you want to take over here or suggest others more familiar with how maven is supposed to work 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
[GitHub] [maven-jenkins-lib] olamy opened a new pull request #3: add ci-reporting, errorprone profile and record static code analysis
olamy opened a new pull request #3: URL: https://github.com/apache/maven-jenkins-lib/pull/3 do not maven.test.failure.ignore per default as we do not even recommend using it (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#testFailureIgnore) -- 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-jenkins-lib] olamy closed pull request #3: add ci-reporting, errorprone profile and record static code analysis
olamy closed pull request #3: URL: https://github.com/apache/maven-jenkins-lib/pull/3 -- 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-jenkins-lib] olamy opened a new pull request #5: notify only for master or main per default (no need to notify for eve…
olamy opened a new pull request #5: URL: https://github.com/apache/maven-jenkins-lib/pull/5 …ry branches) -- 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] (MPOM-310) Replace Google Analytics with ASF Matomo in documentation
[ https://issues.apache.org/jira/browse/MPOM-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPOM-310: --- Fix Version/s: ASF-26 (was: MAVEN-36) > Replace Google Analytics with ASF Matomo in documentation > - > > Key: MPOM-310 > URL: https://issues.apache.org/jira/browse/MPOM-310 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-25 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: ASF-26 > > > ASF Parent POM documentation is published to Maven site: it need to follow > Maven's tracking practice that is changing with MPOM-300 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MPOM-310) Replace Google Analytics with ASF Matomo in documentation
[ https://issues.apache.org/jira/browse/MPOM-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPOM-310. -- Assignee: Herve Boutemy Resolution: Fixed done in https://github.com/apache/maven-apache-parent/commit/8c52ca6e7b407a959acd741d25c0f0efd4f18d45 > Replace Google Analytics with ASF Matomo in documentation > - > > Key: MPOM-310 > URL: https://issues.apache.org/jira/browse/MPOM-310 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-25 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: MAVEN-36 > > > ASF Parent POM documentation is published to Maven site: it need to follow > Maven's tracking practice that is changing with MPOM-300 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MPOM-310) Replace Google Analytics with ASF Matomo in documentation
[ https://issues.apache.org/jira/browse/MPOM-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPOM-310: --- Description: ASF Parent POM documentation is published to Maven site: it need to follow Maven's tracking practice that is changing with MPOM-300 > Replace Google Analytics with ASF Matomo in documentation > - > > Key: MPOM-310 > URL: https://issues.apache.org/jira/browse/MPOM-310 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-25 >Reporter: Herve Boutemy >Priority: Major > Fix For: MAVEN-36 > > > ASF Parent POM documentation is published to Maven site: it need to follow > Maven's tracking practice that is changing with MPOM-300 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPOM-310) Replace Google Analytics with ASF Matomo in documentation
[ https://issues.apache.org/jira/browse/MPOM-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505170#comment-17505170 ] Hudson commented on MPOM-310: - Build succeeded in Jenkins: Maven » Maven TLP » maven-apache-parent » master #12 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-apache-parent/job/master/12/ > Replace Google Analytics with ASF Matomo in documentation > - > > Key: MPOM-310 > URL: https://issues.apache.org/jira/browse/MPOM-310 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-25 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: MAVEN-36 > > > ASF Parent POM documentation is published to Maven site: it need to follow > Maven's tracking practice that is changing with MPOM-300 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MPOM-310) Replace Google Analytics with ASF Matomo in documentation
Herve Boutemy created MPOM-310: -- Summary: Replace Google Analytics with ASF Matomo in documentation Key: MPOM-310 URL: https://issues.apache.org/jira/browse/MPOM-310 Project: Maven POMs Issue Type: Improvement Components: asf Affects Versions: ASF-25 Reporter: Herve Boutemy Fix For: MAVEN-36 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MPOM-300) Replace Google Analytics with ASF Matomo
[ https://issues.apache.org/jira/browse/MPOM-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPOM-300: --- Affects Version/s: MAVEN-35 > Replace Google Analytics with ASF Matomo > > > Key: MPOM-300 > URL: https://issues.apache.org/jira/browse/MPOM-300 > Project: Maven POMs > Issue Type: Improvement >Affects Versions: MAVEN-35 >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Fix For: MAVEN-36 > > > While GA is still allowed according to the [ASF Privacy > Policy|https://www.apache.org/foundation/policies/privacy.html], there's now > [an ASF Matomo instance|https://matomo.privacy.apache.org/]. > * Matomo doesn't track full IPs, doesn't track sessions after closing the > browser, etc. > * Additionally, GA is already illegal in some countries,, like France. > Let's replace the GA code with Matomo. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MPOM-302) Rename property surefire.version to surefireVersion
[
https://issues.apache.org/jira/browse/MPOM-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPOM-302:
---
Description: {{surefire.version}} property was introduced in MPOM-108
released first in ASF parent 18
https://github.com/apache/maven-apache-parent/commit/b56133c80f8a308430a01ddb49c02794b7579bff
(was: {{surefire.version}} property was introduced in ASF parent 18
https://github.com/apache/maven-apache-parent/commit/b56133c80f8a308430a01ddb49c02794b7579bff)
> Rename property surefire.version to surefireVersion
> ---
>
> Key: MPOM-302
> URL: https://issues.apache.org/jira/browse/MPOM-302
> Project: Maven POMs
> Issue Type: Task
> Components: asf
>Affects Versions: ASF-18
>Reporter: Slawomir Jaranowski
>Priority: Major
> Labels: warning
> Fix For: ASF-26
>
>
> {{surefire.version}} property was introduced in MPOM-108 released first in
> ASF parent 18
> https://github.com/apache/maven-apache-parent/commit/b56133c80f8a308430a01ddb49c02794b7579bff
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MPOM-302) Rename property surefire.version to surefireVersion
[
https://issues.apache.org/jira/browse/MPOM-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPOM-302:
---
Labels: warning (was: )
> Rename property surefire.version to surefireVersion
> ---
>
> Key: MPOM-302
> URL: https://issues.apache.org/jira/browse/MPOM-302
> Project: Maven POMs
> Issue Type: Task
> Components: asf
>Affects Versions: ASF-18
>Reporter: Slawomir Jaranowski
>Priority: Major
> Labels: warning
> Fix For: ASF-26
>
>
> {{surefire.version}} property was introduced in ASF parent 18
> https://github.com/apache/maven-apache-parent/commit/b56133c80f8a308430a01ddb49c02794b7579bff
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MPOM-303) Rename property maven.plugin.tools.version to mavenPluginToolsVersion
[
https://issues.apache.org/jira/browse/MPOM-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPOM-303:
---
Description: {{maven.plugin.tools.version}} was introduced in ASF parent 25
https://github.com/apache/maven-apache-parent/commit/5a878dcdc00439cf03d383096c62e9003b503bfe
> Rename property maven.plugin.tools.version to mavenPluginToolsVersion
> -
>
> Key: MPOM-303
> URL: https://issues.apache.org/jira/browse/MPOM-303
> Project: Maven POMs
> Issue Type: Task
> Components: asf
>Affects Versions: ASF-25
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: ASF-26
>
>
> {{maven.plugin.tools.version}} was introduced in ASF parent 25
> https://github.com/apache/maven-apache-parent/commit/5a878dcdc00439cf03d383096c62e9003b503bfe
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MPOM-303) Rename property maven.plugin.tools.version to mavenPluginToolsVersion
[ https://issues.apache.org/jira/browse/MPOM-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPOM-303: --- Affects Version/s: ASF-25 > Rename property maven.plugin.tools.version to mavenPluginToolsVersion > - > > Key: MPOM-303 > URL: https://issues.apache.org/jira/browse/MPOM-303 > Project: Maven POMs > Issue Type: Task > Components: asf >Affects Versions: ASF-25 >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: ASF-26 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPOM-302) Rename property surefire.version to surefireVersion
[
https://issues.apache.org/jira/browse/MPOM-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505166#comment-17505166
]
Herve Boutemy commented on MPOM-302:
what is the rationale behind this change, please?
> Rename property surefire.version to surefireVersion
> ---
>
> Key: MPOM-302
> URL: https://issues.apache.org/jira/browse/MPOM-302
> Project: Maven POMs
> Issue Type: Task
> Components: asf
>Affects Versions: ASF-18
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: ASF-26
>
>
> {{surefire.version}} property was introduced in ASF parent 18
> https://github.com/apache/maven-apache-parent/commit/b56133c80f8a308430a01ddb49c02794b7579bff
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MPOM-302) Rename property surefire.version to surefireVersion
[
https://issues.apache.org/jira/browse/MPOM-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPOM-302:
---
Description: {{surefire.version}} property was introduced in ASF parent 18
https://github.com/apache/maven-apache-parent/commit/b56133c80f8a308430a01ddb49c02794b7579bff
> Rename property surefire.version to surefireVersion
> ---
>
> Key: MPOM-302
> URL: https://issues.apache.org/jira/browse/MPOM-302
> Project: Maven POMs
> Issue Type: Task
> Components: asf
>Affects Versions: ASF-18
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: ASF-26
>
>
> {{surefire.version}} property was introduced in ASF parent 18
> https://github.com/apache/maven-apache-parent/commit/b56133c80f8a308430a01ddb49c02794b7579bff
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MPOM-302) Rename property surefire.version to surefireVersion
[ https://issues.apache.org/jira/browse/MPOM-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPOM-302: --- Affects Version/s: ASF-18 > Rename property surefire.version to surefireVersion > --- > > Key: MPOM-302 > URL: https://issues.apache.org/jira/browse/MPOM-302 > Project: Maven POMs > Issue Type: Task > Components: asf >Affects Versions: ASF-18 >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: ASF-26 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARCHETYPE-628) error thrown when trying to create maven project from command line
CLAUDIA MARTINEZ created ARCHETYPE-628: -- Summary: error thrown when trying to create maven project from command line Key: ARCHETYPE-628 URL: https://issues.apache.org/jira/browse/ARCHETYPE-628 Project: Maven Archetype Issue Type: Bug Components: Plugin Environment: I just configured version 3.8.4, I have windows 10, I have already configured the environment variables (M2_HOME, MAVEN_HOME) Reporter: CLAUDIA MARTINEZ Attachments: maven_error.txt I just configured version 3.8.4, I have windows 10, I have already configured the environment variables (M2_HOME, MAVEN_HOME), and I am trying to create a maven project from the console with the following line: mvn archetype:generate or I have also tried with the sentence that they suggest in the maven site: mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false But it always throws me the same error (see attached txt file), that the plugin for the "Archetype" prefix was not found. I already googled the error, and it seems that everything works very well for everyone, but it has not allowed me to create the project from the command line. I hope you can help me. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-411) When Shade finds overlapping classes, clarify which class is added to final artifact
[ https://issues.apache.org/jira/browse/MSHADE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505102#comment-17505102 ] Michael Osipov commented on MSHADE-411: --- You see warning and overlap, but you don't see the ultimate source of which ends up in the shaded artifact. Therefore, you don't have predictability. > When Shade finds overlapping classes, clarify which class is added to final > artifact > > > Key: MSHADE-411 > URL: https://issues.apache.org/jira/browse/MSHADE-411 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: John Hendrikx >Priority: Minor > > For example: > [WARNING] mediasystem-jfx-2.0.0-SNAPSHOT.jar, javafx-controls-16-win.jar > define 5 overlapping classes: > [WARNING] - javafx.scene.control.skin.SpinnerSkin$2 > [WARNING] - javafx.scene.control.skin.SpinnerSkin > [WARNING] - javafx.scene.control.skin.SpinnerSkin$1 > [WARNING] - javafx.scene.control.skin.SpinnerSkin$4 > [WARNING] - javafx.scene.control.skin.SpinnerSkin$3 > Here I purposely override the SpinnerSkin class to fix a bug. But it is > unclear which version eventually will make it in the uber.jar (I'm hoping it > takes it from the first jar listed). > I could not find anything on the website, faq, stackoverflow that clarifies > *which* version of the class gets included. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-verifier] kwin commented on a change in pull request #11: [MSHARED-871] add basic documentation
kwin commented on a change in pull request #11: URL: https://github.com/apache/maven-verifier/pull/11#discussion_r825044180 ## File path: src/site/markdown/getting-started.md ## @@ -0,0 +1,94 @@ + + +# Getting Started + +## Overview + +Using the `Verifier` consists out of three different phases + +1. Configure +2. Run +3. Verify + +## Configure + +The `Verifier` instance is constructed in the simplest case with just one argument taking the path name of the base directory containing the `pom.xml` of the project you want to build. + +``` +String baseDir = ... +Verifier verifier = new Verifier(baseDir); +``` + +The configuration can be further tweaked with additional setter methods and/or constructors taking more parameters. + +### System Properties + +The following systen properties/environment variables are evaluated + +| System Property | Description | +| --- | --- | +| `verifier.forkMode` | The following values are supported: `auto` uses the forked launcher when environment variables are set`embedder` always uses the embedded launcherany other value leads to always using the forked launcher +| `maven.home` | The directory containing the Maven executable in `bin/mvn` | +| `user.home` | Set by JRE, used for determining Maven default local repository path or the fallback Maven executable | +| `maven.bootclasspath` | Only relevant if Maven home could be determined and the embedded launcher is being used. Determines the classpath of the launcher. May contain multiple path separated by the system dependent path separator. +| `classworlds.conf` | Only relevant if Maven home could be determined and the embedded launcher is being used. The configuration file used by [Plexus Classworlds Loader][plexus-classwords]. If not set defaults to `/bin/m2.conf`. | +| `maven.repo.local` | Contains the path of the local Maven repository | +| `maven.repo.local.layout` | Layout of the local Maven repository. Either `legacy` or `default` with the latter being the default. | + + +### Finding Maven Executable + +The following mechanism determines the binary which is used for executing Maven. This is + +- either the embedded launcher which uses +- the `org.apache.maven.cli.MavenCli` class loaded from the context class loader (in case Maven Home could not be determined) or +- the [Plexus Classworlds Loader][plexus-classwords] (in case Maven Home could be determined) +- or the forked launcher + +Whether the embedded or the forked launcher are used depends on the field `forkJvm` set through the constructor or `setForkJvm` or as fallback on the value of system property `verifier.forkMode`. + + Determining Maven Home directory + +The following directories are considered as potential Maven home directory (relevant for both forked launcher and embedded launcher with [Plexus Classworlds Loader][plexus-classwords]). The first existing directory terminates the mechanism. + +1. Maven Home path given in the constructor +2. System property `maven.home` +3. Environment variable `M2_HOME` Review comment: Please create a dedicated JIRA issue for that. This PR is just about documenting the status quo. -- 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-verifier] kwin commented on a change in pull request #11: [MSHARED-871] add basic documentation
kwin commented on a change in pull request #11: URL: https://github.com/apache/maven-verifier/pull/11#discussion_r825043513 ## File path: src/site/markdown/getting-started.md ## @@ -0,0 +1,94 @@ + + +# Getting Started + +## Overview + +Using the `Verifier` consists out of three different phases + +1. Configure +2. Run +3. Verify Review comment: Well, that is no toc but rather some explanation of the phases in paragraph "Overview". -- 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] (MSHADE-411) When Shade finds overlapping classes, clarify which class is added to final artifact
[ https://issues.apache.org/jira/browse/MSHADE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505098#comment-17505098 ] John Hendrikx commented on MSHADE-411: -- I'm not sure what you are saying, could you explain this it a bit more? > When Shade finds overlapping classes, clarify which class is added to final > artifact > > > Key: MSHADE-411 > URL: https://issues.apache.org/jira/browse/MSHADE-411 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: John Hendrikx >Priority: Minor > > For example: > [WARNING] mediasystem-jfx-2.0.0-SNAPSHOT.jar, javafx-controls-16-win.jar > define 5 overlapping classes: > [WARNING] - javafx.scene.control.skin.SpinnerSkin$2 > [WARNING] - javafx.scene.control.skin.SpinnerSkin > [WARNING] - javafx.scene.control.skin.SpinnerSkin$1 > [WARNING] - javafx.scene.control.skin.SpinnerSkin$4 > [WARNING] - javafx.scene.control.skin.SpinnerSkin$3 > Here I purposely override the SpinnerSkin class to fix a bug. But it is > unclear which version eventually will make it in the uber.jar (I'm hoping it > takes it from the first jar listed). > I could not find anything on the website, faq, stackoverflow that clarifies > *which* version of the class gets included. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MSHADE-411) When Shade finds overlapping classes, clarify which class is added to final artifact
[ https://issues.apache.org/jira/browse/MSHADE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505098#comment-17505098 ] John Hendrikx edited comment on MSHADE-411 at 3/11/22, 7:42 PM: I'm not sure what you are saying, could you explain this a bit more? was (Author: john16384): I'm not sure what you are saying, could you explain this it a bit more? > When Shade finds overlapping classes, clarify which class is added to final > artifact > > > Key: MSHADE-411 > URL: https://issues.apache.org/jira/browse/MSHADE-411 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: John Hendrikx >Priority: Minor > > For example: > [WARNING] mediasystem-jfx-2.0.0-SNAPSHOT.jar, javafx-controls-16-win.jar > define 5 overlapping classes: > [WARNING] - javafx.scene.control.skin.SpinnerSkin$2 > [WARNING] - javafx.scene.control.skin.SpinnerSkin > [WARNING] - javafx.scene.control.skin.SpinnerSkin$1 > [WARNING] - javafx.scene.control.skin.SpinnerSkin$4 > [WARNING] - javafx.scene.control.skin.SpinnerSkin$3 > Here I purposely override the SpinnerSkin class to fix a bug. But it is > unclear which version eventually will make it in the uber.jar (I'm hoping it > takes it from the first jar listed). > I could not find anything on the website, faq, stackoverflow that clarifies > *which* version of the class gets included. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resolver] michael-o commented on a change in pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…
michael-o commented on a change in pull request #158: URL: https://github.com/apache/maven-resolver/pull/158#discussion_r825006511 ## File path: maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java ## @@ -253,7 +253,9 @@ public CollectResult collectDependencies( RepositorySystemSession session, Colle DefaultVersionFilterContext versionContext = new DefaultVersionFilterContext( session ); -Args args = new Args( session, trace, pool, context, versionContext, request ); +Args args = +new Args( session, trace, pool, context, versionContext, request, +new DependencyResolutionSkipper() ); Review comment: Correc, that's be awesome. Interface and two impls. External names: `never` and maybe `default`? ## File path: maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java ## @@ -253,7 +253,9 @@ public CollectResult collectDependencies( RepositorySystemSession session, Colle DefaultVersionFilterContext versionContext = new DefaultVersionFilterContext( session ); -Args args = new Args( session, trace, pool, context, versionContext, request ); +Args args = +new Args( session, trace, pool, context, versionContext, request, +new DependencyResolutionSkipper() ); Review comment: Correct, that's be awesome. Interface and two impls. External names: `never` and maybe `default`? -- 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 edited a comment on pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…
cstamas edited a comment on pull request #158:
URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1065181795
```
maven-integration-testing dcd63dc29413e5154df524002eea967521dd09fc
mvn master:
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]
MavenITmng4913UserPropertyVsDependencyPomPropertyTest>AbstractMavenIntegrationTestCase.runTest:265->testit:59
» Verification
[INFO]
[ERROR] Tests run: 890, Failures: 0, Errors: 1, Skipped: 0
[INFO] Total time: 23:30 min
mvn bfs (see footnote 1):
[INFO] Results:
[INFO]
[ERROR] Failures:
DT [ERROR]
MavenITmng3652UserAgentHeaderTest>AbstractMavenIntegrationTestCase.runTest:265->testmng3652_AdditionnalHttpHeaderConfiguredInSettings:334
expected:<[Maven Fu]> but was:<[Apache-Maven/4.0.0-alpha-1-SNAPSHOT (Java
11.0.14; Linux 5.13.0-35-generic)]>
DT [ERROR]
MavenITmng3652UserAgentHeaderTest>AbstractMavenIntegrationTestCase.runTest:265->testmng3652_UserAgentConfiguredInSettings:298
expected:<[Maven Fu]> but was:<[Apache-Maven/4.0.0-alpha-1-SNAPSHOT (Java
11.0.14; Linux 5.13.0-35-generic)]>
?? [ERROR]
MavenITmng5669ReadPomsOnce>AbstractMavenIntegrationTestCase.runTest:265->testWithBuildConsumer:131
[{org.apache.maven.model.io.inputSource=null null,
org.apache.maven.model.io.isStrict=true,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/pom.xml},
{org.apache.maven.model.io.inputSource=null null,
org.apache.maven.model.io.isStrict=true,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module1/pom.xml},
{org.apache.maven.model.io.inputSource=null null,
org.apache.maven.model.io.isStrict=true,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module2/pom.xml},
{org.apache.maven.model.io.inputSource=null null,
org.apache.maven.model.io.isStrict=true, org.apa
che.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module3/pom.xml},
{transformerContext=org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1@29f0c4f2},
{org.apache.maven.model.io.inputSource=org.apache.maven:maven-model-builder:4.0.0-alpha-1-SNAPSHOT:super-pom
jar:file:/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/apache-maven/lib/maven-model-builder-4.0.0-alpha-1-SNAPSHOT.jar!/org/apache/maven/model/pom-4.0.0.xml,
xml:4.0.0=xml:4.0.0},
{transformerContext=org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1@7c3ebc6b},
{transformerContext=org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1@de18f63},
{transformerContext=org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1@54aca26f},
{org.apache.maven.model.io.isStrict=fa
lse,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/plugins/maven-plugins/23/maven-plugins-23.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/maven-parent/22/maven-parent-22.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/apache/11/apache-11.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-pl
ugin-3.1.pom}, {org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/plugins/maven-plugins/24/maven-plugins-24.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/maven-parent/23/maven-parent-23.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/apache/13/apache-13.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/plugins/maven-surefire-plugin/2.12.4/maven-surefire-plugin-2.
[GitHub] [maven-integration-testing] cstamas edited a comment on pull request #140: [MRESOLVER-247] IT update for resolver behaviour change
cstamas edited a comment on pull request #140:
URL:
https://github.com/apache/maven-integration-testing/pull/140#issuecomment-1065402086
> I don't understand this change. Why 140+? And how did `+ 4` make it to `-
4`? Moving the expected value to a constant make sense, but the rest is unclear.
Changes one by one:
* The assert for 140+ is really just to exclude false positives (ie. Maven
does not parse even one POM). We KNOW there are hundred-something POMs to
parse, but we DO NOT WANT to fix that number (as will change between
DFS/BFS/skipper)
* instead to assert lines in log (created by agent), we "remember" the
count, then we make that list unique, and compare size again
* the +4 was factored out, the sum was asserted (168+4), so assertion
happened with 172, hence, to get 168 out of 172 we do -4.
* In other words (applies to testWithBuildConsumer) method only: we KNOW
that reactor POMs are read twice (and reactor has 2 POMs, hence we "correct"
the count with -4)
* finally, I have a list of strings, making them unique by file path (using
`model.building.source`) and asserting result is list.size - 1 = uniqList.size
(as super pom is OMITTED from uniq list, it has NO `model.building.sourcre`).
Example of log entries for POM that went thru model builder vs Super POM
(reformatted for easier read, they are all one liners):
```
{
org.apache.maven.model.io.inputSource=null null,
org.apache.maven.model.io.isStrict=true,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-
suite/target/test-classes/mng-5669-read-poms-once/module3/pom.xml
},
{
org.apache.maven.model.io.inputSource=org.apache.maven:maven-model-builder:4.0.0-alpha-1-SNAPSHOT:super-pom
jar:file:/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/apache-maven/lib/maven-model-builder-4.0.0-alpha-1-SNAPSHOT.jar!/org/apache/maven/model/pom-4.0.0.xml,
xml:4.0.0=xml:4.0.0
}
```
--
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 a change in pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…
cstamas commented on a change in pull request #158: URL: https://github.com/apache/maven-resolver/pull/158#discussion_r824996140 ## File path: maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java ## @@ -253,7 +253,9 @@ public CollectResult collectDependencies( RepositorySystemSession session, Colle DefaultVersionFilterContext versionContext = new DefaultVersionFilterContext( session ); -Args args = new Args( session, trace, pool, context, versionContext, request ); +Args args = +new Args( session, trace, pool, context, versionContext, request, +new DependencyResolutionSkipper() ); Review comment: Session is here, so based on configUtil results using session, one could create instance of DependencyResolutionSkipper or NeverSkipper 😄 -- 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-integration-testing] cstamas commented on pull request #129: [MNG-7371] Parent POM for dependency packaging is not pom
cstamas commented on pull request #129: URL: https://github.com/apache/maven-integration-testing/pull/129#issuecomment-1065403606 This was a fluke, closing, dropping this -- 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-integration-testing] cstamas closed pull request #129: [MNG-7371] Parent POM for dependency packaging is not pom
cstamas closed pull request #129: URL: https://github.com/apache/maven-integration-testing/pull/129 -- 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] gnodet commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
gnodet commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065402650 > > Isn't that exactly the opposite of what is done for lifecycle participants and workspace readers at boot time ? Those are loaded from all registered extensions for all projects and are active for the whole build. > > But each of those are loaded from their own classloader (there is no shared one) if they are defined at the project level. If they are defined as core-extension they are all loaded from the "maven-core-realm", that's why I said if you want to be on the "global-scope" (thus all projects are sharing the same instance) you should use a maven-core extension. But I'm not talking about changing the class loaders, just the visibility for beans with plexus lookup. I don't see why `WorkspaceReader` and `AbstractMavenLifecycleParticipant` should be treated differently than any other lookup. > The whole caching-story for me sounds as if it is more suitable as a core-extension, for example tycho is defined on a per project level, but we check as the very first step that **all** projects in the reactor are using the same tycho version and fail the build if not. Neverless my goal is to make tycho a pure core-extension because project-scoped is much more limited and requires special care. Core extensions are not loaded if you're aggregating multiple projects as you hinted earlier, so I guess it really depends on the use case. I don't really any good reason to not try to support both. I've added a commit which explains my thoughts : a single ClassRealm is created with all extensions (and not only the ones from top level or the last project). This realm is not used to load classes from, it's only used for lookups. It's created as early as possible after the projects are created and used as the context classloader. It removes the need for explicit lookup in those realms for workspace readers and lifecycle participants. -- 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-integration-testing] cstamas commented on pull request #140: [MRESOLVER-247] IT update for resolver behaviour change
cstamas commented on pull request #140:
URL:
https://github.com/apache/maven-integration-testing/pull/140#issuecomment-1065402086
> I don't understand this change. Why 140+? And how did `+ 4` make it to `-
4`? Moving the expected value to a constant make sense, but the rest is unclear.
Changes one by one:
* The assert for 140+ is really just to exclude false positives (ie. Maven
does not parse even one POM). We KNOW there are hundred-something POMs to
parse, but we DO NOT WANT to fix that number (as will change between
DFS/BFS/skipper)
* instead to assert lines in log (created by agent), we "remember" the
count, then we make that list unique, and compare size again
* the +4 was factored out, the sum was asserted (168+4), so assertion
happened with 172, hence, to get 168 out of 172 we do -4.
* In other words (applies to testWithBuildConsumer) method only: we KNOW
that reactor POMs are read twice (and reactor has 2 POMs, hence we "correct"
the count with -4)
* finally, I have a list of strings, making them unique by file path (using
`model.building.source`) and asserting result is list.size - 1 = uniqList.size
(as super pom is OMITTED from this list, it has NO `model.building.sourcre`).
Example of log entries for POM that went thru model builder vs Super POM
(reformatted for easier read, they are all one liners):
```
{
org.apache.maven.model.io.inputSource=null null,
org.apache.maven.model.io.isStrict=true,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-
suite/target/test-classes/mng-5669-read-poms-once/module3/pom.xml
},
{
org.apache.maven.model.io.inputSource=org.apache.maven:maven-model-builder:4.0.0-alpha-1-SNAPSHOT:super-pom
jar:file:/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/apache-maven/lib/maven-model-builder-4.0.0-alpha-1-SNAPSHOT.jar!/org/apache/maven/model/pom-4.0.0.xml,
xml:4.0.0=xml:4.0.0
}
```
--
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 #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…
michael-o commented on pull request #158: URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1065380564 > One remark: maybe a config param to DISABLE skipper? As sometimes inspecting the "whole overloaded" graph is useful, no? And skipper is added always currently. So maybe an another skipper implementation that is "no-skip"? This makes sense. @caiwei-ebay Do you see a way to make this configurable? -- 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 #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…
michael-o commented on pull request #158: URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1065379812 > ``` > mvn 3.8.4: > Total time:40.749 s > Total files: 4675 > Total bytes: 169M > > mvn master: > Total time:38.446 s > Total files: 4673 > Total bytes: 169M > > mvn bfs: > Total time:33.510 s > Total files: 4556 > Total bytes: 168M > ``` > > (all 3 building current mvn master 97c1e4b4aa73f5851801fdf5e17f013dd46a6b3e w/ empty local repo, primed proxy, no tests executed) (files/bytes are count of files and total size in bytes of local repo AFTER build done) This is actually fantastic since we save time when we skip. @jebeaudet Can you test this at work to speed up your build 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
[jira] [Commented] (MPLUGIN-394) Report-Mojo doesn't respect input encoding
[
https://issues.apache.org/jira/browse/MPLUGIN-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505064#comment-17505064
]
ASF GitHub Bot commented on MPLUGIN-394:
michael-o commented on a change in pull request #73:
URL: https://github.com/apache/maven-plugin-tools/pull/73#discussion_r824972534
##
File path:
maven-plugin-plugin/src/it/mplugin-394_report-encoding/invoker.properties
##
@@ -0,0 +1,18 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+invoker.goals = -Dfile.encoding=CP1252 plugin:report
Review comment:
@SebastianKuehn Please add a followup PR which documents the limitations
of this PR
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Report-Mojo doesn't respect input encoding
> --
>
> Key: MPLUGIN-394
> URL: https://issues.apache.org/jira/browse/MPLUGIN-394
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.6.4
>Reporter: Sebastian Kühn
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0
>
>
> {{plugin:report}} reads the Plugin-XML-File with with the platform encoding
> instead of the specified input encoding. This results in an broken generated
> XDoc and finally Site.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-plugin-tools] michael-o commented on a change in pull request #73: [MPLUGIN-394] Respect input encoding
michael-o commented on a change in pull request #73: URL: https://github.com/apache/maven-plugin-tools/pull/73#discussion_r824972534 ## File path: maven-plugin-plugin/src/it/mplugin-394_report-encoding/invoker.properties ## @@ -0,0 +1,18 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +invoker.goals = -Dfile.encoding=CP1252 plugin:report Review comment: @SebastianKuehn Please add a followup PR which documents the limitations of this PR -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] jglick commented on issue #579: `java.lang.NoSuchMethodError: org.apache.maven.project.MavenProject.setArtifacts(Ljava/util/Set;)V`
jglick commented on issue #579: URL: https://github.com/apache/maven-mvnd/issues/579#issuecomment-1065368840 Any plans to release 0.7.2? -- 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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487: URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824922994 ## File path: surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java ## @@ -70,13 +39,47 @@ import org.junit.platform.launcher.TestIdentifier; import org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder; +import java.io.IOException; +import java.io.StringReader; +import java.io.UncheckedIOException; +import java.util.ArrayList; +import java.util.Collection; +import java.util.HashMap; +import java.util.LinkedHashSet; +import java.util.List; +import java.util.Map; +import java.util.Optional; +import java.util.Properties; +import java.util.ServiceLoader; +import java.util.logging.Logger; +import java.util.stream.Collectors; +import java.util.stream.StreamSupport; + +import static java.util.Arrays.stream; +import static java.util.Collections.emptyMap; +import static java.util.Optional.empty; +import static java.util.Optional.of; +import static java.util.logging.Level.WARNING; +import static java.util.stream.Collectors.toList; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.EXCLUDE_JUNIT5_ENGINES_PROP; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.INCLUDE_JUNIT5_ENGINES_PROP; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.TESTNG_EXCLUDEDGROUPS_PROP; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.TESTNG_GROUPS_PROP; +import static org.apache.maven.surefire.api.report.ConsoleOutputCapture.startCapture; +import static org.apache.maven.surefire.api.report.RunMode.NORMAL_RUN; +import static org.apache.maven.surefire.api.report.RunMode.RERUN_TEST_AFTER_FAILURE; +import static org.apache.maven.surefire.api.util.TestsToRun.fromClass; +import static org.apache.maven.surefire.shared.utils.StringUtils.isBlank; +import static org.junit.platform.engine.discovery.DiscoverySelectors.selectClass; +import static org.junit.platform.engine.discovery.DiscoverySelectors.selectUniqueId; +import static org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder.request; + /** * JUnit 5 Platform Provider. * * @since 2.22.0 */ -public class JUnitPlatformProvider -extends AbstractProvider +public class JUnitPlatformProvider extends AbstractProvider Review comment: I've reformatted this class according to `maven_checks` after getting checkstyle violations. Let me try to revert unrelated changes EDIT Done, see updated code -- 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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824921536
##
File path: surefire-providers/surefire-junit-platform/pom.xml
##
@@ -136,6 +136,47 @@
+
+ org.apache.maven.plugins
+ maven-jar-plugin
+
+
+ api-jar
+ package
+
+jar
+
+
+api
Review comment:
> Can you explain how the customer would implement the interface
TestSelectorFactory you have introduced? What types of sources can be filtered
and how they can be configured?
Absolutely.
Here is my implementation for ArchUnit's
[`FieldSource`](https://github.com/TNG/ArchUnit/blob/2f3ff7dccbe3e3d8900604801fd545dd0c2e70d8/archunit-junit/junit5/engine-api/src/main/java/com/tngtech/archunit/junit/FieldSource.java):
```
package com.tngtech.archunit.junit.surefire;
import com.tngtech.archunit.junit.FieldSource;
import org.apache.maven.surefire.junitplatform.TestSelectorFactory;
import org.junit.platform.engine.TestSource;
public class FieldSelectorFactory implements TestSelectorFactory {
@Override
public boolean supports(TestSource testSource) {
return testSource instanceof FieldSource;
}
@Override
public String getContainerName(TestSource testSource) {
return ((FieldSource) testSource).getClassName();
}
@Override
public String getSelectorName(TestSource testSource) {
return ((FieldSource) testSource).getFieldName();
}
}
```
It solves the problem of adding support for applying the same filtering
logic Surefire now applies to methods, to other test sources (`FieldSource` in
this case).
In case you're unfamiliar with ArchUnit, here's what an ArchUnit test might
look like:
```
@AnalyzeClasses(packages = "com.tngtech.archunit.example.layers")
public class CodingRulesTest {
@ArchTest
private final ArchRule loggers_should_be_private_static_final =
fields().that().haveRawType(Logger.class)
.should().bePrivate()
.andShould().beStatic()
.andShould().beFinal()
.because("we agreed on this convention");
}
```
As you can see, test cases are represented by *fields*, and not *methods*.
This is also why the default Surefire `include / exclude` filters do not work.
> JUnit5 SPI do not exist with same purpose?
Yes, of course it exists, and that's exactly what ArchUnit does under the
hood. There's no way to influence Surefire filtering logic from inside a JUnit
extension, though.
I've already verified providing this implementation of the new SPI in
ArchUnit solves [the linked ArchUnit
issue](https://github.com/TNG/ArchUnit/issues/641) for Surefire. I'm now about
to suggest similar extensibility to other build tools.
--
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824921536
##
File path: surefire-providers/surefire-junit-platform/pom.xml
##
@@ -136,6 +136,47 @@
+
+ org.apache.maven.plugins
+ maven-jar-plugin
+
+
+ api-jar
+ package
+
+jar
+
+
+api
Review comment:
> Can you explain how the customer would implement the interface
TestSelectorFactory you have introduced? What types of sources can be filtered
and how they can be configured?
Absolutely.
Here is my implementation for ArchUnit's
[`FieldSelector`](https://github.com/TNG/ArchUnit/blob/2f3ff7dccbe3e3d8900604801fd545dd0c2e70d8/archunit-junit/junit5/engine-api/src/main/java/com/tngtech/archunit/junit/FieldSelector.java):
```
package com.tngtech.archunit.junit.surefire;
import com.tngtech.archunit.junit.FieldSource;
import org.apache.maven.surefire.junitplatform.TestSelectorFactory;
import org.junit.platform.engine.TestSource;
public class FieldSelectorFactory implements TestSelectorFactory {
@Override
public boolean supports(TestSource testSource) {
return testSource instanceof FieldSource;
}
@Override
public String getContainerName(TestSource testSource) {
return ((FieldSource) testSource).getClassName();
}
@Override
public String getSelectorName(TestSource testSource) {
return ((FieldSource) testSource).getFieldName();
}
}
```
It solves the problem of adding support for applying the same filtering
logic Surefire now applies to methods, to other test sources (`FieldSource` in
this case).
In case you're unfamiliar with ArchUnit, here's what an ArchUnit test might
look like:
```
@AnalyzeClasses(packages = "com.tngtech.archunit.example.layers")
public class CodingRulesTest {
@ArchTest
private final ArchRule loggers_should_be_private_static_final =
fields().that().haveRawType(Logger.class)
.should().bePrivate()
.andShould().beStatic()
.andShould().beFinal()
.because("we agreed on this convention");
}
```
As you can see, test cases are represented by *fields*, and not *methods*.
This is also why the default Surefire `include / exclude` filters do not work.
> JUnit5 SPI do not exist with same purpose?
Yes, of course it exists, and that's exactly what ArchUnit does under the
hood. There's no way to influence Surefire filtering logic from inside a JUnit
extension, though.
I've already verified providing this implementation of the new SPI in
ArchUnit solves [the linked ArchUnit
issue](https://github.com/TNG/ArchUnit/issues/641) for Surefire. I'm now about
to suggest similar extensibility to other build tools.
--
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-jxr] slawekjaranowski merged pull request #48: Bump slf4j-api from 1.7.32 to 1.7.36
slawekjaranowski merged pull request #48: URL: https://github.com/apache/maven-jxr/pull/48 -- 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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824930706
##
File path: surefire-providers/surefire-junit-platform/pom.xml
##
@@ -136,6 +136,47 @@
+
+ org.apache.maven.plugins
+ maven-jar-plugin
+
+
+ api-jar
+ package
+
+jar
+
+
+api
Review comment:
Also, if I understand correctly, here:
> The plugin has configuration of class/methods. If somebody changes this in
the SPI, then what you be valid? Configuration or SPI?
You're asking what happens if someone overwrites the service to something
else than `MethodSelectorFactory`. The answer is here:
```
private Collection loadSelectorFactories()
{
return StreamSupport.stream( ServiceLoader.load(
TestSelectorFactory.class ).spliterator(), false )
.collect( Collectors.toSet() );
}
```
Basically, there's no 'changing the SPI'. `MethodSelectorFactory` is always
provided as the default implementation, and extending libraries can only add
new service implementations. `MethodSelectorFactory` **cannot be resigned from,
though**.
Thus, for those users who do not extend this SPI in any way, the behavior of
Surefire will be consistent with the behavior before this PR.
> There are other two SPI modules surefire-extensions-spi (for the forked
JVM) and surefire-extensions-api (for the plugin process)
Yes, and unfortunately, they do not fit my use case. I *could* implement a
custom `SurefireProvider`, but that would basically mean re-implementing the
current `JUnitPlatformProvider`, which is 99% suitable but completely closed
for extension. This minuscule SPI introduction is really the smallest possible
change that solves the problem without affecting other plugin users.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824921536
##
File path: surefire-providers/surefire-junit-platform/pom.xml
##
@@ -136,6 +136,47 @@
+
+ org.apache.maven.plugins
+ maven-jar-plugin
+
+
+ api-jar
+ package
+
+jar
+
+
+api
Review comment:
> Can you explain how the customer would implement the interface
TestSelectorFactory you have introduced? What types of sources can be filtered
and how they can be configured?
Absolutely.
Here is my implementation for ArchUnit's
[`FieldSelector`](https://github.com/TNG/ArchUnit/blob/2f3ff7dccbe3e3d8900604801fd545dd0c2e70d8/archunit-junit/junit5/engine-api/src/main/java/com/tngtech/archunit/junit/FieldSelector.java):
```
package com.tngtech.archunit.junit.surefire;
import com.tngtech.archunit.junit.FieldSource;
import org.apache.maven.surefire.junitplatform.TestSelectorFactory;
import org.junit.platform.engine.TestSource;
public class FieldSelectorFactory implements TestSelectorFactory {
@Override
public boolean supports(TestSource testSource) {
return testSource instanceof FieldSource;
}
@Override
public String getContainerName(TestSource testSource) {
return ((FieldSource) testSource).getClassName();
}
@Override
public String getSelectorName(TestSource testSource) {
return ((FieldSource) testSource).getFieldName();
}
}
```
It solves the problem of adding support for applying the same filtering
logic Surefire now applies to methods, to other test sources (`FieldSource` in
this case). I'm now about to suggest similar extensibility to other build
tools.
I've already verified providing this implementation of the new SPI in
ArchUnit solves [the linked ArchUnit
issue](https://github.com/TNG/ArchUnit/issues/641) for Surefire.
--
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824921536
##
File path: surefire-providers/surefire-junit-platform/pom.xml
##
@@ -136,6 +136,47 @@
+
+ org.apache.maven.plugins
+ maven-jar-plugin
+
+
+ api-jar
+ package
+
+jar
+
+
+api
Review comment:
> Can you explain how the customer would implement the interface
TestSelectorFactory you have introduced? What types of sources can be filtered
and how they can be configured?
Absolutely.
Here is my implementation for ArchUnit's
[`FieldSelector`](https://github.com/TNG/ArchUnit/blob/2f3ff7dccbe3e3d8900604801fd545dd0c2e70d8/archunit-junit/junit5/engine-api/src/main/java/com/tngtech/archunit/junit/FieldSelector.java):
```
package com.tngtech.archunit.junit.surefire;
import com.tngtech.archunit.junit.FieldSource;
import org.apache.maven.surefire.junitplatform.TestSelectorFactory;
import org.junit.platform.engine.TestSource;
public class FieldSelectorFactory implements TestSelectorFactory {
@Override
public boolean supports(TestSource testSource) {
return testSource instanceof FieldSource;
}
@Override
public String getContainerName(TestSource testSource) {
return ((FieldSource) testSource).getClassName();
}
@Override
public String getSelectorName(TestSource testSource) {
return ((FieldSource) testSource).getFieldName();
}
}
```
It solves the problem of adding support for applying the same filtering
logic Surefire now applies to methods, to other test sources (`FieldSource` in
this case).
I've already verified providing this implementation of the new SPI in
ArchUnit solves [the linked ArchUnit
issue](https://github.com/TNG/ArchUnit/issues/641) for Surefire.
--
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824930706
##
File path: surefire-providers/surefire-junit-platform/pom.xml
##
@@ -136,6 +136,47 @@
+
+ org.apache.maven.plugins
+ maven-jar-plugin
+
+
+ api-jar
+ package
+
+jar
+
+
+api
Review comment:
Also, if I understand correctly, here:
> The plugin has configuration of class/methods. If somebody changes this in
the SPI, then what you be valid? Configuration or SPI?
You're asking what happens if someone overwrites the service to something
else than `MethodSelectorFactory`. The answer is here:
```
private Collection loadSelectorFactories()
{
return StreamSupport.stream( ServiceLoader.load(
TestSelectorFactory.class ).spliterator(), false )
.collect( Collectors.toSet() );
}
```
Basically, there's 'no changing the SPI'. `MethodSelectorFactory` is always
provided as the default implementation, and extending libraries can only add
new service implementations. `MethodSelectorFactory` **cannot be resigned from,
though**.
Thus, for those users who do not extend this SPI in any way, the behavior of
Surefire will be consistent with the behavior before this PR.
##
File path: surefire-providers/surefire-junit-platform/pom.xml
##
@@ -136,6 +136,47 @@
+
+ org.apache.maven.plugins
+ maven-jar-plugin
+
+
+ api-jar
+ package
+
+jar
+
+
+api
Review comment:
Also, if I understand correctly, here:
> The plugin has configuration of class/methods. If somebody changes this in
the SPI, then what you be valid? Configuration or SPI?
You're asking what happens if someone overwrites the service to something
else than `MethodSelectorFactory`. The answer is here:
```
private Collection loadSelectorFactories()
{
return StreamSupport.stream( ServiceLoader.load(
TestSelectorFactory.class ).spliterator(), false )
.collect( Collectors.toSet() );
}
```
Basically, there's no 'changing the SPI'. `MethodSelectorFactory` is always
provided as the default implementation, and extending libraries can only add
new service implementations. `MethodSelectorFactory` **cannot be resigned from,
though**.
Thus, for those users who do not extend this SPI in any way, the behavior of
Surefire will be consistent with the behavior before this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824930706
##
File path: surefire-providers/surefire-junit-platform/pom.xml
##
@@ -136,6 +136,47 @@
+
+ org.apache.maven.plugins
+ maven-jar-plugin
+
+
+ api-jar
+ package
+
+jar
+
+
+api
Review comment:
Also, if I understand correctly, here:
> The plugin has configuration of class/methods. If somebody changes this in
the SPI, then what you be valid? Configuration or SPI?
You're asking what happens if someone overwrites the service to something
else than `MethodSelectorFactory`. The answer is here:
```
private Collection loadSelectorFactories()
{
return StreamSupport.stream( ServiceLoader.load(
TestSelectorFactory.class ).spliterator(), false )
.collect( Collectors.toSet() );
}
```
Basically, there's 'no changing the SPI'. `MethodSelectorFactory` is always
provided as the default implementation, and extending libraries can only add
new service implementations.
Thus, for those users who do not extend this SPI in any way, the behavior of
Surefire will be consistent with the behavior before this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824930706
##
File path: surefire-providers/surefire-junit-platform/pom.xml
##
@@ -136,6 +136,47 @@
+
+ org.apache.maven.plugins
+ maven-jar-plugin
+
+
+ api-jar
+ package
+
+jar
+
+
+api
Review comment:
Also, if I understand correctly, here:
> The plugin has configuration of class/methods. If somebody changes this in
the SPI, then what you be valid? Configuration or SPI?
You're asking what happens if someone overwrites the service to something
else than `MethodSelectorFactory`. The answer is here:
```
private Collection loadSelectorFactories()
{
return StreamSupport.stream( ServiceLoader.load(
TestSelectorFactory.class ).spliterator(), false )
.collect( Collectors.toSet() );
}
```
Basically, there's no overwriting. `MethodSelectorFactory` is always
provided as the default implementation, and extending libraries can only add
new service implementations.
Thus, for those users who do not extend this SPI in any way, the behavior of
Surefire will be consistent with the behavior before this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824920327
##
File path:
surefire-api/src/main/java/org/apache/maven/surefire/api/testset/TestListResolver.java
##
@@ -195,13 +195,13 @@ public boolean shouldRun( Class testClass, String
methodName )
/**
* Returns {@code true} if satisfies {@code testClassFile} and {@code
methodName} filter.
*
- * @param testClassFile format must be e.g. "my/package/MyTest.class"
including class extension; or null
- * @param methodName real test-method name; or null
+ * @param containerName format must be e.g. "my/package/MyTest.class"
including class extension; or null
Review comment:
The attribute names of this method have been changed to reflect their
new meaning. The second parameter to this method, for instance, will no longer
only ever represent method names. That's the entire purpose of this PR.
Would you care to explain why you would expect the parameters to retain
their original names?
--
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487: URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824914180 ## File path: pom.xml ## @@ -532,8 +532,7 @@ src/test/resources/**/* src/test/resources/**/*.css **/*.jj - src/main/resources/META-INF/services/org.apache.maven.surefire.api.provider.SurefireProvider - +src/main/resources/META-INF/services/** Review comment: Not sure I follow. This was an intentional change, otherwise Rat would expect a license inside [META-INF/services/org.apache.maven.surefire.junitplatform.TestSelectorFactory](https://github.com/apache/maven-surefire/pull/487/files#diff-c7cece3a6cc077f79ed38dae264e97961c801cb107a602888ff19464dbbf4a54) Should I add an entry here for that specific file instead? -- 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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487: URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824914180 ## File path: pom.xml ## @@ -532,8 +532,7 @@ src/test/resources/**/* src/test/resources/**/*.css **/*.jj - src/main/resources/META-INF/services/org.apache.maven.surefire.api.provider.SurefireProvider - +src/main/resources/META-INF/services/** Review comment: Not sure I follow. This was an intentional change, otherwise Rat would expect to embed a license inside [META-INF/services/org.apache.maven.surefire.junitplatform.TestSelectorFactory](https://github.com/apache/maven-surefire/pull/487/files#diff-c7cece3a6cc077f79ed38dae264e97961c801cb107a602888ff19464dbbf4a54) Should I add an entry here for that specific file instead? -- 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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487: URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824922994 ## File path: surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java ## @@ -70,13 +39,47 @@ import org.junit.platform.launcher.TestIdentifier; import org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder; +import java.io.IOException; +import java.io.StringReader; +import java.io.UncheckedIOException; +import java.util.ArrayList; +import java.util.Collection; +import java.util.HashMap; +import java.util.LinkedHashSet; +import java.util.List; +import java.util.Map; +import java.util.Optional; +import java.util.Properties; +import java.util.ServiceLoader; +import java.util.logging.Logger; +import java.util.stream.Collectors; +import java.util.stream.StreamSupport; + +import static java.util.Arrays.stream; +import static java.util.Collections.emptyMap; +import static java.util.Optional.empty; +import static java.util.Optional.of; +import static java.util.logging.Level.WARNING; +import static java.util.stream.Collectors.toList; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.EXCLUDE_JUNIT5_ENGINES_PROP; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.INCLUDE_JUNIT5_ENGINES_PROP; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.TESTNG_EXCLUDEDGROUPS_PROP; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.TESTNG_GROUPS_PROP; +import static org.apache.maven.surefire.api.report.ConsoleOutputCapture.startCapture; +import static org.apache.maven.surefire.api.report.RunMode.NORMAL_RUN; +import static org.apache.maven.surefire.api.report.RunMode.RERUN_TEST_AFTER_FAILURE; +import static org.apache.maven.surefire.api.util.TestsToRun.fromClass; +import static org.apache.maven.surefire.shared.utils.StringUtils.isBlank; +import static org.junit.platform.engine.discovery.DiscoverySelectors.selectClass; +import static org.junit.platform.engine.discovery.DiscoverySelectors.selectUniqueId; +import static org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder.request; + /** * JUnit 5 Platform Provider. * * @since 2.22.0 */ -public class JUnitPlatformProvider -extends AbstractProvider +public class JUnitPlatformProvider extends AbstractProvider Review comment: I've reformatted this class according to `maven_checks` after getting checkstyle violations. Let me try to revert unrelated 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
[GitHub] [maven-surefire] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824921536
##
File path: surefire-providers/surefire-junit-platform/pom.xml
##
@@ -136,6 +136,47 @@
+
+ org.apache.maven.plugins
+ maven-jar-plugin
+
+
+ api-jar
+ package
+
+jar
+
+
+api
Review comment:
Absolutely.
Here is my implementation for ArchUnit's
[`FieldSelector`](https://github.com/TNG/ArchUnit/blob/2f3ff7dccbe3e3d8900604801fd545dd0c2e70d8/archunit-junit/junit5/engine-api/src/main/java/com/tngtech/archunit/junit/FieldSelector.java):
```
package com.tngtech.archunit.junit.surefire;
import com.tngtech.archunit.junit.FieldSource;
import org.apache.maven.surefire.junitplatform.TestSelectorFactory;
import org.junit.platform.engine.TestSource;
public class FieldSelectorFactory implements TestSelectorFactory {
@Override
public boolean supports(TestSource testSource) {
return testSource instanceof FieldSource;
}
@Override
public String getContainerName(TestSource testSource) {
return ((FieldSource) testSource).getClassName();
}
@Override
public String getSelectorName(TestSource testSource) {
return ((FieldSource) testSource).getFieldName();
}
}
```
It solves the problem of adding support for applying the same filtering
logic Surefire now applies to methods, to other test sources (`FieldSource` in
this case).
I've already verified providing this implementation of the new SPI in
ArchUnit solves [the linked ArchUnit
issue](https://github.com/TNG/ArchUnit/issues/641) for Surefire.
--
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824920327
##
File path:
surefire-api/src/main/java/org/apache/maven/surefire/api/testset/TestListResolver.java
##
@@ -195,13 +195,13 @@ public boolean shouldRun( Class testClass, String
methodName )
/**
* Returns {@code true} if satisfies {@code testClassFile} and {@code
methodName} filter.
*
- * @param testClassFile format must be e.g. "my/package/MyTest.class"
including class extension; or null
- * @param methodName real test-method name; or null
+ * @param containerName format must be e.g. "my/package/MyTest.class"
including class extension; or null
Review comment:
The attribute names of this method have been changed to reflect their
new meaning. The second parameter to this method, for instance, will no longer
only ever represent method names. That's the entire purpose of this PR.
Would you care to explain why you would expect the parameters to retain
their original name?
--
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824920327
##
File path:
surefire-api/src/main/java/org/apache/maven/surefire/api/testset/TestListResolver.java
##
@@ -195,13 +195,13 @@ public boolean shouldRun( Class testClass, String
methodName )
/**
* Returns {@code true} if satisfies {@code testClassFile} and {@code
methodName} filter.
*
- * @param testClassFile format must be e.g. "my/package/MyTest.class"
including class extension; or null
- * @param methodName real test-method name; or null
+ * @param containerName format must be e.g. "my/package/MyTest.class"
including class extension; or null
Review comment:
The attribute names of this method have been changed to reflect their
new meaning. The second parameter to this method, for instance, will no longer
only ever represent method names. That's the entire purpose of this PR.
Please explain why you would expect the parameters to retain their original
name.
--
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824920327
##
File path:
surefire-api/src/main/java/org/apache/maven/surefire/api/testset/TestListResolver.java
##
@@ -195,13 +195,13 @@ public boolean shouldRun( Class testClass, String
methodName )
/**
* Returns {@code true} if satisfies {@code testClassFile} and {@code
methodName} filter.
*
- * @param testClassFile format must be e.g. "my/package/MyTest.class"
including class extension; or null
- * @param methodName real test-method name; or null
+ * @param containerName format must be e.g. "my/package/MyTest.class"
including class extension; or null
Review comment:
The attribute names of this method have been changed to reflect their
new meaning. The second parameter to this method, for instance, will no longer
only ever represent method names. That's the entire purpose of this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487: URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824914180 ## File path: pom.xml ## @@ -532,8 +532,7 @@ src/test/resources/**/* src/test/resources/**/*.css **/*.jj - src/main/resources/META-INF/services/org.apache.maven.surefire.api.provider.SurefireProvider - +src/main/resources/META-INF/services/** Review comment: Not sure I follow. This was an intentional change, otherwise Rat would expect to embed a license inside [META-INF/services/org.apache.maven.surefire.junitplatform.TestSelectorFactory](https://github.com/apache/maven-surefire/pull/487/files#diff-c7cece3a6cc077f79ed38dae264e97961c801cb107a602888ff19464dbbf4a54) -- 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] crizzis commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
crizzis commented on a change in pull request #487: URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824914180 ## File path: pom.xml ## @@ -532,8 +532,7 @@ src/test/resources/**/* src/test/resources/**/*.css **/*.jj - src/main/resources/META-INF/services/org.apache.maven.surefire.api.provider.SurefireProvider - +src/main/resources/META-INF/services/** Review comment: Not sure I follow. This was an intentional change, otherwise Rat would expect to embed a license inside `[META-INF/services/org.apache.maven.surefire.junitplatform.TestSelectorFactory](https://github.com/apache/maven-surefire/pull/487/files#diff-c7cece3a6cc077f79ed38dae264e97961c801cb107a602888ff19464dbbf4a54)` -- 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] [Assigned] (MDEP-761) Tree plugin does not terminate with 3.2.0
[
https://issues.apache.org/jira/browse/MDEP-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MDEP-761:
-
Assignee: Sylwester Lachiewicz
> Tree plugin does not terminate with 3.2.0
> -
>
> Key: MDEP-761
> URL: https://issues.apache.org/jira/browse/MDEP-761
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Jan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.3.0
>
>
> We use a tool called WhiteSource that analyzes our dependencies for security
> issues. It uses the the following call to maven deps plugin to get the
> dependencies:
> {code}mvn dependency:tree -DoutputFile=whitesource_mvn_dependency_tree.txt
> -Dverbose -DoutputType=text -T1 -B {code}
> This works and takes ~15seconds with version 3.1.2, after upgrading to 3.2.0,
> this call does not terminate after 15 minutes and runs into a timeout.
> When starting maven with "-X" I can see thousands of those debug messages
> flowing through, it looks like it is scanning the whole local maven
> repository:
> {code}
> [DEBUG] Writing tracking file
> C:\Users\myuser\.m2\repository\org\jboss\spec\jboss-specs-parent\1.0.0.Beta2\_remote.repositories
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for
> https://my-repo
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https://my-repo with username=myuser, password=*** via localhost:
> [DEBUG] Writing tracking file
> C:\Users\myuser\.m2\repository\org\jboss\spec\javax\interceptor\jboss-interceptors-api_1.1_spec\1.0.0.Beta1\_remote.repositories
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for
> https://my-repo
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https://my-repo with username=myuser, password=*** via localhost:
> [DEBUG] Writing tracking file
> C:\Users\myuser\.m2\repository\org\jboss\spec\jboss-specs-parent\1.0.0.Beta1\_remote.repositories
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for
> https://my-repo
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https://my-repo with username=myuser, password=*** via localhost:
> [DEBUG] Writing tracking file
> C:\Users\myuser\.m2\repository\org\testng\testng\5.10\_remote.repositories
> [DEBUG] Verifying availability of
> C:\Users\myuser\.m2\repository\org\apache\derby\derby\10.12.1.1\derby-10.12.1.1.pom
> from [devcloud-bci-mvn (https://my-repo, default, releases+snapshots),
> artifactory-central-mirror (https://my-repo, default, releases), central
> (https://repo.maven.apache.org/maven2, default, releases)]
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for
> https://my-repo
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https://my-repo with username=myuser, password=*** via localhost:
> [DEBUG] Writing tracking file
> C:\Users\myuser\.m2\repository\org\apache\derby\derby\10.12.1.1\_remote.repositories
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-verifier] slawekjaranowski commented on a change in pull request #11: [MSHARED-871] add basic documentation
slawekjaranowski commented on a change in pull request #11: URL: https://github.com/apache/maven-verifier/pull/11#discussion_r824859977 ## File path: src/site/markdown/index.md ## @@ -0,0 +1,24 @@ + + +# About Apache Verifier Maven Component + +Provides a test harness for Maven integration tests. This is a library which can be used in own Java-based integration tests. Look at the [Getting Started guide](./getting-started.html) for more information on how to use it. + +Other example usages can be found in the integration tests of the [Apache Maven Remote Resources Plugin](https://github.com/apache/maven-remote-resources-plugin/blob/maven-remote-resources-plugin-1.7.0/src/test/java/org/apache/maven/plugin/resources/remote/it/IT_FilterLocalOverride.java). Review comment: It is simple test ... If we want to show more complicated usage I will link to Maven Integration project as reference https://github.com/apache/maven-integration-testing ## File path: src/site/markdown/getting-started.md ## @@ -0,0 +1,94 @@ + + +# Getting Started + +## Overview + +Using the `Verifier` consists out of three different phases + +1. Configure +2. Run +3. Verify Review comment: no needed table of content for short document ## File path: src/site/markdown/getting-started.md ## @@ -0,0 +1,94 @@ + + +# Getting Started + +## Overview + +Using the `Verifier` consists out of three different phases + +1. Configure +2. Run +3. Verify + +## Configure + +The `Verifier` instance is constructed in the simplest case with just one argument taking the path name of the base directory containing the `pom.xml` of the project you want to build. + +``` +String baseDir = ... +Verifier verifier = new Verifier(baseDir); +``` + +The configuration can be further tweaked with additional setter methods and/or constructors taking more parameters. + +### System Properties + +The following systen properties/environment variables are evaluated + +| System Property | Description | Review comment: Please add to table: Which properties are required? What is default values / behavior if property is not set? ## File path: src/site/markdown/getting-started.md ## @@ -0,0 +1,94 @@ + + +# Getting Started + +## Overview + +Using the `Verifier` consists out of three different phases + +1. Configure +2. Run +3. Verify + +## Configure + +The `Verifier` instance is constructed in the simplest case with just one argument taking the path name of the base directory containing the `pom.xml` of the project you want to build. + +``` +String baseDir = ... +Verifier verifier = new Verifier(baseDir); Review comment: please follow maven convention, space after and before parentheses ## File path: src/site/markdown/getting-started.md ## @@ -0,0 +1,94 @@ + + +# Getting Started + +## Overview + +Using the `Verifier` consists out of three different phases + +1. Configure +2. Run +3. Verify + +## Configure + +The `Verifier` instance is constructed in the simplest case with just one argument taking the path name of the base directory containing the `pom.xml` of the project you want to build. + +``` +String baseDir = ... +Verifier verifier = new Verifier(baseDir); +``` + +The configuration can be further tweaked with additional setter methods and/or constructors taking more parameters. + +### System Properties + +The following systen properties/environment variables are evaluated + +| System Property | Description | +| --- | --- | +| `verifier.forkMode` | The following values are supported: `auto` uses the forked launcher when environment variables are set`embedder` always uses the embedded launcherany other value leads to always using the forked launcher +| `maven.home` | The directory containing the Maven executable in `bin/mvn` | +| `user.home` | Set by JRE, used for determining Maven default local repository path or the fallback Maven executable | +| `maven.bootclasspath` | Only relevant if Maven home could be determined and the embedded launcher is being used. Determines the classpath of the launcher. May contain multiple path separated by the system dependent path separator. +| `classworlds.conf` | Only relevant if Maven home could be determined and the embedded launcher is being used. The configuration file used by [Plexus Classworlds Loader][plexus-classwords]. If not set defaults to `/bin/m2.conf`. | +| `maven.repo.local` | Contains the path of the local Maven repository | +| `maven.repo.local.layout` | Layout of the local Maven repository. Either `legacy` or `default` with the latter being the default. | + + +### Finding Maven Executable + +The following mechanism determines the binary which is used for executing Maven. This is + +- either the embedded launcher which uses +- the `org.apache.maven.cli.MavenCli` class loaded from the context class loader (in case Maven Home could not be determined) or +- the [Plexu
[GitHub] [maven-resolver] cstamas commented on pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…
cstamas commented on pull request #158: URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1065252914 One remark: maybe a config param to DISABLE skipper? As sometimes inspecting the "whole overloaded" graph is useful, no? And skipper is added always currently. So maybe an another skipper implementation that is "no-skip"? -- 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 edited a comment on pull request #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…
cstamas edited a comment on pull request #158: URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1065224093 The one failing IT fix: https://github.com/apache/maven-integration-testing/pull/140 Reason is simple: this IT "counts" ALL the resolution that maven (erm, resolver) does, and fails due substantial difference between "old" resolver (DFS and w/o skipper) and this PR (BFS + skipper). The PR above changes the Maven IT to not "lock down" the read POM count, but still assert that POMs are read only once. -- 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] laeubi edited a comment on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
laeubi edited a comment on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065231874 > Isn't that exactly the opposite of what is done for lifecycle participants and workspace readers at boot time ? Those are loaded from all registered extensions for all projects and are active for the whole build. But each of those are loaded from their own classloader (there is no shared one) if they are defined at the project level. If they are defined as core-extension they are all loaded from the "maven-core-realm", that's why I said if you want to be on the "global-scope" (thus all projects are sharing the same instance) you should use a maven-core extension. The whole caching-story for me sounds as if it is more suitable as a core-extension, for example tycho is defined on a per project level, but we check as the very first step that **all** projects in the reactor are using the same tycho version and fail the build if not. Neverless my goal is to make tycho a pure core-extension because project-scoped is much more limited and requires special care. -- 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] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
laeubi commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065231874 > Isn't that exactly the opposite of what is done for lifecycle participants and workspace readers at boot time ? Those are loaded from all registered extensions for all projects and are active for the whole build. But each of those are loaded from their own classloader (there is no shared one) if they are defined at the project level. If they are defined as core-extension they are all loaded from the "maven-core-realm", that's why I said if you want to be on the "global-scope" (thus all projects are sharing the same instance) you should use a maven-core extension. The whole caching-story for me sounds as if it is more suitable as a core-extension, for example tycho is defined on a per project level, but we check as the very first step that **all* projects in the reactor are using the same tycho version and fail the build if not. Neverless my goal is to make tycho a pure core-extension because project-scoped is much more limited and requires special care. -- 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] gnodet commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
gnodet commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065227468 > > > I would assume some kind of implicit inheritance wrt to extensions. Another way would be to create a realm that would have visibility on all extensions of the build and use that one for the whole build duration. > > I don't think all extensions should share the same class-space, especially with projects-scoped extension (in contrast to core-extension) they started to become only active after a while, there is a bootstrap phase in maven when there is actually no such thing like "project", also as explained before you most probably don't want that an extension magically becomes active just because another module defines it. If you like that an extension applies for all projects then it should be defined as a core-extension in `.mvn/extensions.xml` so they become part of the bootstrap-process. > > Thats also the reason why only core-extensions can participate in session-start because at that point there are no projects and thus any project-scoped extension is simply not accessible. Isn't that exactly the opposite of what is done for lifecycle participants and workspace readers at boot time ? Those are loaded from all registered extensions for all projects and are active for the whole build. -- 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 #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…
cstamas commented on pull request #158: URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1065224093 The one failing IT fix: https://github.com/apache/maven-integration-testing/pull/140 Reason is simple: this IT "counts" ALL the resolution that maven (erm, resolver) does, and fails due substantial difference between "old" resolver (DFS and w/o skipper) and this PR (BFS + skipper). -- 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-integration-testing] cstamas opened a new pull request #140: [MRESOLVER-247] IT update for resolver behaviour change
cstamas opened a new pull request #140: URL: https://github.com/apache/maven-integration-testing/pull/140 I tried to be least intrusive here (so I left old but added new values w/ explanation). Once MRESOLVER-247 is merged, and maven consumes it, this IT will fail, as maven will resolve LESS then this IT expects. This change adjusts numbers, and makes the two IT pass OK. -- 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] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
laeubi commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065215613 > I would assume some kind of implicit inheritance wrt to extensions. Another way would be to create a realm that would have visibility on all extensions of the build and use that one for the whole build duration. I don't think all extensions should share the same class-space, especially with projects-scoped extension (in contrast to core-extension) they started to become only active after a while, there is a bootstrap phase in maven when there is actually no such thing like "project", also as explained before you most probably don't want that an extension magically becomes active just because another module defines it. If you like that an extension applies for all projects then it should be defined as a core-extension in `.mvn/extensions.xml` so they become part of the bootstrap-process. Thats also the reason why only core-extensions can participate in session-start because at that point there are no projects and thus any project-scoped extension is simply not accessible. -- 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 #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…
cstamas commented on pull request #158:
URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1065181795
```
maven-integration-testing dcd63dc29413e5154df524002eea967521dd09fc
mvn master:
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]
MavenITmng4913UserPropertyVsDependencyPomPropertyTest>AbstractMavenIntegrationTestCase.runTest:265->testit:59
» Verification
[INFO]
[ERROR] Tests run: 890, Failures: 0, Errors: 1, Skipped: 0
[INFO] Total time: 23:30 min
mvn bfs*:
[INFO] Results:
[INFO]
[ERROR] Failures:
DT [ERROR]
MavenITmng3652UserAgentHeaderTest>AbstractMavenIntegrationTestCase.runTest:265->testmng3652_AdditionnalHttpHeaderConfiguredInSettings:334
expected:<[Maven Fu]> but was:<[Apache-Maven/4.0.0-alpha-1-SNAPSHOT (Java
11.0.14; Linux 5.13.0-35-generic)]>
DT [ERROR]
MavenITmng3652UserAgentHeaderTest>AbstractMavenIntegrationTestCase.runTest:265->testmng3652_UserAgentConfiguredInSettings:298
expected:<[Maven Fu]> but was:<[Apache-Maven/4.0.0-alpha-1-SNAPSHOT (Java
11.0.14; Linux 5.13.0-35-generic)]>
?? [ERROR]
MavenITmng5669ReadPomsOnce>AbstractMavenIntegrationTestCase.runTest:265->testWithBuildConsumer:131
[{org.apache.maven.model.io.inputSource=null null,
org.apache.maven.model.io.isStrict=true,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/pom.xml},
{org.apache.maven.model.io.inputSource=null null,
org.apache.maven.model.io.isStrict=true,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module1/pom.xml},
{org.apache.maven.model.io.inputSource=null null,
org.apache.maven.model.io.isStrict=true,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module2/pom.xml},
{org.apache.maven.model.io.inputSource=null null,
org.apache.maven.model.io.isStrict=true, org.apa
che.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/test-classes/mng-5669-read-poms-once/module3/pom.xml},
{transformerContext=org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1@29f0c4f2},
{org.apache.maven.model.io.inputSource=org.apache.maven:maven-model-builder:4.0.0-alpha-1-SNAPSHOT:super-pom
jar:file:/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/apache-maven/lib/maven-model-builder-4.0.0-alpha-1-SNAPSHOT.jar!/org/apache/maven/model/pom-4.0.0.xml,
xml:4.0.0=xml:4.0.0},
{transformerContext=org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1@7c3ebc6b},
{transformerContext=org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1@de18f63},
{transformerContext=org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1@54aca26f},
{org.apache.maven.model.io.isStrict=fa
lse,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/plugins/maven-plugins/23/maven-plugins-23.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/maven-parent/22/maven-parent-22.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/apache/11/apache-11.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-pl
ugin-3.1.pom}, {org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/plugins/maven-plugins/24/maven-plugins-24.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/maven-parent/23/maven-parent-23.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/apache/13/apache-13.pom},
{org.apache.maven.model.io.isStrict=false,
org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/repo/org/apache/maven/plugins/maven-surefire-plugin/2.12.4/maven-surefire-plugin-2.12.4.pom},
{org.apache
[jira] [Closed] (JXR-165) Upgrade Maven Reporting to 3.1.0
[ https://issues.apache.org/jira/browse/JXR-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed JXR-165. --- Resolution: Fixed > Upgrade Maven Reporting to 3.1.0 > > > Key: JXR-165 > URL: https://issues.apache.org/jira/browse/JXR-165 > Project: Maven JXR > Issue Type: Dependency upgrade > Components: maven2 jxr plugin >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-jxr] slawekjaranowski merged pull request #52: [JXR-165] Upgrade Maven Reporting to 3.1.0
slawekjaranowski merged pull request #52: URL: https://github.com/apache/maven-jxr/pull/52 -- 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] gnodet commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
gnodet commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065159566 > > Thoughts ? > > Looks like a good idea. > > > the top level project's realm is used by default during the duration of the build > > I'm not sure why this should be the case... The "top level project" is not meant to be something special when it comes to classloading. Just assume the top-level is just an aggregator that includes all projects as modules (with the modules using individual parents) why should I want it to be used as the CCL root? I would assume some kind of implicit inheritance wrt to extensions. Another way would be to create a realm that would have visibility on all extensions of the build and use that one for the whole build duration. This would get rid of the `attachToThread` method completely. -- 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] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
laeubi commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065135431 > Thoughts ? Looks like a good idea. > the top level project's realm is used by default during the duration of the build I'm not sure why this should be the case... The "top level project" is not meant to be something special when it comes to classloading. Just assume the top-level is just an aggregator that includes all projects as modules (with the modules using individual parents) why should I want it to be used as the CCL root? -- 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-shared-utils] slawekjaranowski merged pull request #95: (doc) Throw more descriptive NPEx
slawekjaranowski merged pull request #95: URL: https://github.com/apache/maven-shared-utils/pull/95 -- 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] gnodet commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
gnodet commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065129222 @laeubi I've pushed another commit to discuss / experiment with. There are only two remaining calls to `BuildCommon.attachToThread` which are now clearly scoped in a block that grabs / restores the TCCL. In short: * the top level project's realm is used by default during the duration of the build * if any project defines extensions, this realm is used instead when building that project Thoughts ? -- 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 #158: MRESOLVER-247: Introduce skipper to avoid unnecessary dependency reso…
cstamas commented on pull request #158: URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1065122240 ``` mvn 3.8.4: Total time:40.749 s Total files: 4675 Total bytes: 169M mvn master: Total time:38.446 s Total files: 4673 Total bytes: 169M mvn bfs: Total time:33.510 s Total files: 4556 Total bytes: 168M ``` (all 3 building current mvn master 97c1e4b4aa73f5851801fdf5e17f013dd46a6b3e w/ empty local repo, primed proxy, no tests executed) (files/bytes are count of files and total size in bytes of local repo AFTER build done) -- 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-verifier] slawekjaranowski commented on pull request #9: [MSHARED-1043] Deprecate methods leveraging JUnit4 assertions
slawekjaranowski commented on pull request #9: URL: https://github.com/apache/maven-verifier/pull/9#issuecomment-1065120081 Better stats is usage per version, like: https://mvnrepository.com/artifact/org.apache.maven.shared/maven-verifier -- 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-verifier] slawekjaranowski commented on pull request #9: [MSHARED-1043] Deprecate methods leveraging JUnit4 assertions
slawekjaranowski commented on pull request #9: URL: https://github.com/apache/maven-verifier/pull/9#issuecomment-1065118967 We shouldn't stop development based on simple usage. Eg. now many project migrate to JUnit 5 or use other test frameworks than JUnit 4. We shouldn't implicate which framework should be used by final project. In my feel many projects do not upgrade their dependency, so it is their decision. -- 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] (MRESOLVER-242) When no remote checksums provided by layout, transfer inevitably fails/warns
[
https://issues.apache.org/jira/browse/MRESOLVER-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-242:
--
Description:
On remote transfer, if layout does not provide remote checksums (as Javadoc
states: it MAY return empty collection), remote transfer either WARNs or fails
(if repository policy is WARN of FAIL respectively) always. This is wrong IMHO.
OTOH, layout intentionally does not return remote checksums in some cases, like
GPG signature is, if the default Maven2RepositoryLayoutEx is used.
Hence, this causes that (sub)artifacts like checksums and signatures are NOT
resolvable using resolver, due that above (they are deemed to always fail).
Hence, a proposed solution is:
* change of semantics: when layout does not provide remote checksums, skip
checksum validation of remote checksums (as there is no such thing as "checksum
of a checksum" or in many cases "checksum of a signature").
* make resolver layout extensible re "artifacts with omitted checksums" instead
to have baked in only one extension: {{.asc}}
was:
On remote transfer, if layout does not provide remote checksums (as Javadoc
states: it MAY return empty collection), remote transfer either WARNs or fails
(if repository policy is WARN of FAIL respectively) always. This is wrong IMHO.
OTOH, layout intentionally does not return remote checksums in some cases, like
GPG signature is, if the default Maven2RepositoryLayoutEx is used.
Hence, this causes that (sub)artifacts like checksums and signatures are NOT
resolvable using resolver, due that above (they are deemed to always fail).
Hence, a proposed solution is:
* change of semantics: when layout does not provide remote checksums, skip
checksum validation of remote checksums (as there is no such thing as "checksum
of a checksum" or in many cases "checksum of a signature").
* make resolver layout "aware" of signatures, just like it is aware of
checksums and make them extensible/configurable
Optionally:
* implement signing/signature verification services
> When no remote checksums provided by layout, transfer inevitably fails/warns
>
>
> Key: MRESOLVER-242
> URL: https://issues.apache.org/jira/browse/MRESOLVER-242
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
>
> On remote transfer, if layout does not provide remote checksums (as Javadoc
> states: it MAY return empty collection), remote transfer either WARNs or
> fails (if repository policy is WARN of FAIL respectively) always. This is
> wrong IMHO.
> OTOH, layout intentionally does not return remote checksums in some cases,
> like GPG signature is, if the default Maven2RepositoryLayoutEx is used.
> Hence, this causes that (sub)artifacts like checksums and signatures are NOT
> resolvable using resolver, due that above (they are deemed to always fail).
> Hence, a proposed solution is:
> * change of semantics: when layout does not provide remote checksums, skip
> checksum validation of remote checksums (as there is no such thing as
> "checksum of a checksum" or in many cases "checksum of a signature").
> * make resolver layout extensible re "artifacts with omitted checksums"
> instead to have baked in only one extension: {{.asc}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MRESOLVER-241) Resolver checksum calculation should be driven by layout
[
https://issues.apache.org/jira/browse/MRESOLVER-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-241:
--
Description:
Currently, whether connector calculates checksums or not is driven by
{{Layout.ChecksumLocation}}, but this is wrong, as some artifacts (like
signatures) may not have checksum locations returned by layout, and hence, is
*shutting down complete checksum calculation*. That, on the other hand, fails
remote transport in case of FAIL checksum policy.
This change alone does NOT fix special cases like "resolving from remote
signature", but makes a step to fix it.
The fact that {{Layout.ChecksumLocation}} is empty does not mean anything else,
that resolver should not expect on remote checksum (REMOTE_EXTERNAL), but not
shut down completely checksum validation as other mechanisms (REMOTE_INCLUDED
or PROVIDED) should still kick in, if applicable.
was:
Currently, whether connector calculates checksums or not is driven by
{{Layout.ChecksumLocation}}, but this is wrong, as some artifacts (like
signatures) may not have checksum locations returned by layout, and hence, is
shutting down complete checksum calculation. That, on the other hand, fails
remote transport in case of FAIL checksum policy.
This change alone does NOT fix special cases like "resolving from remote
signature", but makes a step to fix it.
> Resolver checksum calculation should be driven by layout
>
>
> Key: MRESOLVER-241
> URL: https://issues.apache.org/jira/browse/MRESOLVER-241
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
>
> Currently, whether connector calculates checksums or not is driven by
> {{Layout.ChecksumLocation}}, but this is wrong, as some artifacts (like
> signatures) may not have checksum locations returned by layout, and hence, is
> *shutting down complete checksum calculation*. That, on the other hand, fails
> remote transport in case of FAIL checksum policy.
> This change alone does NOT fix special cases like "resolving from remote
> signature", but makes a step to fix it.
> The fact that {{Layout.ChecksumLocation}} is empty does not mean anything
> else, that resolver should not expect on remote checksum (REMOTE_EXTERNAL),
> but not shut down completely checksum validation as other mechanisms
> (REMOTE_INCLUDED or PROVIDED) should still kick in, if applicable.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
laeubi commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065068471 > For the record, the lookup of the `MojosExecutionStrategy` which was introduced by [1954d51](https://github.com/apache/maven/commit/1954d51ff2841045b4af8a515ad0719805269d8d) is definitely wrong and the lookup should be either performed explicitly using the container or better with an injected `Provider` as explained in [Guice](https://github.com/google/guice/wiki/InjectingProviders#providers-for-mixing-scopes). Also just for the record: You won't have noticed this bug without the fix applied in https://github.com/apache/maven/commit/e327be3d85918a23a5ba48d752143a6dbf8b83f7 and that's why I'm so eager to fix bad usage of CCL/leakage as these hides hard to track problems you can spend hours of debugging and banging your head on the wall, even though most of the time people don't feel its a problem or even don't think its worth a change see https://issues.apache.org/jira/browse/CAMEL-10456 for another nasty problem in that category. -- 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-verifier] elharo commented on pull request #9: [MSHARED-1043] Deprecate methods leveraging JUnit4 assertions
elharo commented on pull request #9: URL: https://github.com/apache/maven-verifier/pull/9#issuecomment-1065067750 Thanks for the link to mvnrepository. That's more usages than I would have guessed. My gut is that we're not going to remove these methods. Too many projects depend on them already. I think we're better off living with what we have. -- 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-verifier] elharo commented on pull request #9: [MSHARED-1043] Deprecate methods leveraging JUnit4 assertions
elharo commented on pull request #9: URL: https://github.com/apache/maven-verifier/pull/9#issuecomment-1065066209 It's the standard way, assuming step 2 can in fact be done. Far too often, step 2 never happens and the deprecated code is never removed and supported forever. -- 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] laeubi edited a comment on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
laeubi edited a comment on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065058784 > I'll fix it by injecting a `Provider` in the constructor and will do the actual lookup in the method when using the component. > So let's consider the scoping problem solved please. Alright. > The problem here is a _visibility_ problem across realms. Even with the lookup fixed, the code without the current PR will still have no visibility on the required bean which is registered as an extension on the project which is being built. If you want to have "project-visibility" when fetching the `Provider` use `BuilderCommon.attachToThread( session.getCurrentProject() );` there (but please reset the TCCL afterwards ;-) > I think we want the maven classloader, core extensions and build extensions to be used to lookup the beans. I agree about the first two but not the last one see `BuilderCommon.attachToThread` or alike should give you the desired effect. > I back this point by the fact that the code now between the `attachToThread` call and the restoration of the TCCL does not seem to actually perform any lookup or class loading. I also noticed that, but please also note the TODO (that was there before) that the author of that code (haven't diged in here) is sure if it is actually necessary, so probably it would be better to not call `BuilderCommon.attachToThread` at all here. > Which means that the purpose was to actually set the classloader to the correct value The purpose is to set the Thread loader to the one of the project while calling `projectBuilds.add( new ProjectSegment( project, taskSegment, copiedSession ) );` but even the author was not sure if it is actually incorrect... > One thing I don't really get in what you say : why do you consider that this PR does not fix the classloader leak ? The classloader is set to the extension class loader if one is provided and back to its original value after the build, so that looks ok to me... It is set back _after_ the build, but _while_ the build it leaks a (random) classloader and makes the project realm accessible to a number of (random) other items as you have proven with your extension. Please also take a look at where it is called in line 105 we have the "real" context-classloader (also note that the context clasloader might be different from the classlaoder used to actually load the current class!) https://github.com/apache/maven/blob/97c1e4b4aa73f5851801fdf5e17f013dd46a6b3e/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleStarter.java#L105-L127 in line 122 the the current CCL (**what is now is a random leaked from the previous call**) is fetched and further passed to another component as the `originalContextClassLoader` (even though called on the call site `oldClassloader`) and this value **is** actually used later on to restore the CCL **after** a `BuilderCommon.attachToThread` is called in https://github.com/apache/maven/blob/97c1e4b4aa73f5851801fdf5e17f013dd46a6b3e/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilder.java#L107-L158 just assume your extension is there and works, now I add another extension (e.g. a wagon-provider) and your extension suddenly fails with CNF or CCE (thats what my fix reveals without another extension being used), would you really desire/expect this? -- 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] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
laeubi commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065058784 > I'll fix it by injecting a `Provider` in the constructor and will do the actual lookup in the method when using the component. > So let's consider the scoping problem solved please. Alright. > The problem here is a _visibility_ problem across realms. Even with the lookup fixed, the code without the current PR will still have no visibility on the required bean which is registered as an extension on the project which is being built. If you want to have "project-visibility" use `BuilderCommon.attachToThread( session.getCurrentProject() );` (but please reset the TCCL afterwards ;-) > I think we want the maven classloader, core extensions and build extensions to be used to lookup the beans. I agree about the first two but not the last one see `BuilderCommon.attachToThread` or alike should give you the desired effect. > I back this point by the fact that the code now between the `attachToThread` call and the restoration of the TCCL does not seem to actually perform any lookup or class loading. I also noticed that, but please also note the TODO (that was there before) that the author of that code (haven't diged in here) is sure if it is actually necessary, so probably it would be better to not call `BuilderCommon.attachToThread` at all here. > Which means that the purpose was to actually set the classloader to the correct value The purpose is to set the Thread loader to the one of the project while calling `projectBuilds.add( new ProjectSegment( project, taskSegment, copiedSession ) );` but even the author was not sure if it is actually incorrect... > One thing I don't really get in what you say : why do you consider that this PR does not fix the classloader leak ? The classloader is set to the extension class loader if one is provided and back to its original value after the build, so that looks ok to me... It is set back _after_ the build, but _while_ the build it leaks a (random) classloader and makes the project realm accessible to a number of (random) other items as you have proven with your extension. Please also take a look at where it is called in line 105 we have the "real" context-classloader (also note that the context clasloader might be different from the classlaoder used to actually load the current class!) https://github.com/apache/maven/blob/97c1e4b4aa73f5851801fdf5e17f013dd46a6b3e/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleStarter.java#L105-L127 in line 122 the the current CCL (**what is now is a random leaked from the previous call**) is fetched and further passed to another component as the `originalContextClassLoader` (even though called on the call site `oldClassloader`) and this value **is** actually used later on to restore the CCL **after** a `BuilderCommon.attachToThread` is called in https://github.com/apache/maven/blob/97c1e4b4aa73f5851801fdf5e17f013dd46a6b3e/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilder.java#L107-L158 just assume your extension is there and works, now I add another extension (e.g. a wagon-provider) and your extension suddenly fails with CNF or CCE (thats what my fix reveals without another extension being used), would you really desire/expect this? -- 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] laeubi edited a comment on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
laeubi edited a comment on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1064296345 Just another observation, it seems `MojosExecutionStrategy` was just intorduced in maven `3.9.x` so how could it be a regression from `3.8.x`? -- 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] gnodet commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
gnodet commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065043792 For the record, the lookup of the `MojosExecutionStrategy` which was introduced by https://github.com/apache/maven/commit/1954d51ff2841045b4af8a515ad0719805269d8d is definitely wrong and the lookup should be either performed explicitely using the container or better with an injected `Provider` as explained in [Guice](https://github.com/google/guice/wiki/InjectingProviders#providers-for-mixing-scopes). It was developed explicitely for `m-build-cache-e` so it's meant to support looking up a session scoped bean, but the implicit injection done from the singleton scope to the session scope is definitely wrong. Which also raise the question about why is it allowed at all... but let's not diverge. This broken lookup will cause a problem when reusing the `MojoExecutor` which is a singleton and it would not lookup a new component if called again with in different session scope. I'll fix it by injecting a `Provider` in the constructor and will do the actual lookup in the method when using the component. So let's consider the scoping problem solved please. The problem here is a *visibility* problem across realms. Even with the lookup fixed, the code without the current PR will still have no visibility on the required bean which is registered as an extension on the project which is being built. When the simple lookup is done (i.e. a `container.lookup()` or a `provider.get()` call), I think we want the maven classloader, core extensions and build extensions to be used to lookup the beans. So this has to be set up, and that's not the case. In order to have those lookups working correctly, we need the correct class realm to be setup. The last project defining extension was used and it was leaking after the build. With the current PR, the top level project one is used and does not leak after the build. Looking at the code leads me to think that the fix from https://github.com/apache/maven/commit/e327be3d85918a23a5ba48d752143a6dbf8b83f7 is wrong, because it removes the visibility to the build extensions. I back this point by the fact that the code now between the `attachToThread` call and the restoration of the TCCL does not seem to actually perform any lookup or class loading. Which means that the purpose was to actually set the classloader to the correct value, which is what I'm trying to get back. One thing I don't really get in what you say : why do you consider that this PR does not fix the classloader leak ? The classloader is set to the extension class loader if one is provided and back to its original value after the build, so that looks ok to me... -- 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-2037) Allow for surefire-junit-platform's TestMethodFilter to support custom TestSources
[
https://issues.apache.org/jira/browse/SUREFIRE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504876#comment-17504876
]
Tibor Digana commented on SUREFIRE-2037:
[~crizzis_dna]
Pls describe very properly what you are aiming for in the JIRA in details.
Can you explain how the customer would implement the interface
TestSelectorFactory you have introduced? What types of sources can be filtered
and how they can be configured?
> Allow for surefire-junit-platform's TestMethodFilter to support custom
> TestSources
> --
>
> Key: SUREFIRE-2037
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2037
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Krzysztof Sierszeń
>Priority: Minor
>
> Since JUnit 5 allows for custom {{{}TestSource{}}}s to be configured,
> {{TestMethodFilter}} could provide a way for those sources to be recognized
> and filterable. This way, custom method sources will enjoy the same filtering
> capabilities that method sources do.
> For now, this change specifically targets ArchUnit's {{FieldSource}}, and I'm
> planning to use the solution provided to solve [the following
> issue|https://github.com/TNG/ArchUnit/issues/641].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
Tibor17 commented on a change in pull request #487: URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824635901 ## File path: surefire-providers/surefire-junit-platform/pom.xml ## @@ -136,6 +136,47 @@ + + org.apache.maven.plugins + maven-jar-plugin + + + api-jar + package + +jar + + +api Review comment: There are other two SPI modules `surefire-extensions-spi` (for the forked JVM) and `surefire-extensions-api` (for the plugin process) but nothing is suited for this scenario of providers. Can you explain how the customer would implement the interface `TestSelectorFactory` you have introduced? What types of sources can be filtered and how they can be configured? -- 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] (MSHADE-411) When Shade finds overlapping classes, clarify which class is added to final artifact
[ https://issues.apache.org/jira/browse/MSHADE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504869#comment-17504869 ] Michael Osipov commented on MSHADE-411: --- Obviously, the source artifact needs to indicates, no? Or first or last, etc? > When Shade finds overlapping classes, clarify which class is added to final > artifact > > > Key: MSHADE-411 > URL: https://issues.apache.org/jira/browse/MSHADE-411 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: John Hendrikx >Priority: Minor > > For example: > [WARNING] mediasystem-jfx-2.0.0-SNAPSHOT.jar, javafx-controls-16-win.jar > define 5 overlapping classes: > [WARNING] - javafx.scene.control.skin.SpinnerSkin$2 > [WARNING] - javafx.scene.control.skin.SpinnerSkin > [WARNING] - javafx.scene.control.skin.SpinnerSkin$1 > [WARNING] - javafx.scene.control.skin.SpinnerSkin$4 > [WARNING] - javafx.scene.control.skin.SpinnerSkin$3 > Here I purposely override the SpinnerSkin class to fix a bug. But it is > unclear which version eventually will make it in the uber.jar (I'm hoping it > takes it from the first jar listed). > I could not find anything on the website, faq, stackoverflow that clarifies > *which* version of the class gets included. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
Tibor17 commented on a change in pull request #487: URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824618154 ## File path: surefire-providers/surefire-junit-platform/pom.xml ## @@ -136,6 +136,47 @@ + + org.apache.maven.plugins + maven-jar-plugin + + + api-jar + package + +jar + + +api Review comment: This looks like a hack. Why you have introduced Apache SPI and you change the default behavior this way? JUnit5 SPI do not exist with same purpose? The plugin has configuration of class/methods. If somebody changes this in the SPI, then what you be valid? Configuration or SPI? **Pls describe very properly what you are aiming for in the JIRA in details.** -- 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 a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
Tibor17 commented on a change in pull request #487: URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824597956 ## File path: surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java ## @@ -70,13 +39,47 @@ import org.junit.platform.launcher.TestIdentifier; import org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder; +import java.io.IOException; +import java.io.StringReader; +import java.io.UncheckedIOException; +import java.util.ArrayList; +import java.util.Collection; +import java.util.HashMap; +import java.util.LinkedHashSet; +import java.util.List; +import java.util.Map; +import java.util.Optional; +import java.util.Properties; +import java.util.ServiceLoader; +import java.util.logging.Logger; +import java.util.stream.Collectors; +import java.util.stream.StreamSupport; + +import static java.util.Arrays.stream; +import static java.util.Collections.emptyMap; +import static java.util.Optional.empty; +import static java.util.Optional.of; +import static java.util.logging.Level.WARNING; +import static java.util.stream.Collectors.toList; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.EXCLUDE_JUNIT5_ENGINES_PROP; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.INCLUDE_JUNIT5_ENGINES_PROP; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.TESTNG_EXCLUDEDGROUPS_PROP; +import static org.apache.maven.surefire.api.booter.ProviderParameterNames.TESTNG_GROUPS_PROP; +import static org.apache.maven.surefire.api.report.ConsoleOutputCapture.startCapture; +import static org.apache.maven.surefire.api.report.RunMode.NORMAL_RUN; +import static org.apache.maven.surefire.api.report.RunMode.RERUN_TEST_AFTER_FAILURE; +import static org.apache.maven.surefire.api.util.TestsToRun.fromClass; +import static org.apache.maven.surefire.shared.utils.StringUtils.isBlank; +import static org.junit.platform.engine.discovery.DiscoverySelectors.selectClass; +import static org.junit.platform.engine.discovery.DiscoverySelectors.selectUniqueId; +import static org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder.request; + /** * JUnit 5 Platform Provider. * * @since 2.22.0 */ -public class JUnitPlatformProvider -extends AbstractProvider +public class JUnitPlatformProvider extends AbstractProvider Review comment: It is very hard to separate reasonable and non-reasonable changes. I guess you wanted to make some specific improvement in this class. Do not press CTRL+ALT+L because there is again unnecessary 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
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
Tibor17 commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824589850
##
File path:
surefire-api/src/main/java/org/apache/maven/surefire/api/testset/TestListResolver.java
##
@@ -195,13 +195,13 @@ public boolean shouldRun( Class testClass, String
methodName )
/**
* Returns {@code true} if satisfies {@code testClassFile} and {@code
methodName} filter.
*
- * @param testClassFile format must be e.g. "my/package/MyTest.class"
including class extension; or null
- * @param methodName real test-method name; or null
+ * @param containerName format must be e.g. "my/package/MyTest.class"
including class extension; or null
Review comment:
Don't change this class, it has nothing to do with what you are aiming
for. Rather do not make any additional refactoring because it is very hard to
separate reasonable and non-reasonable changes. I guess you wanted to make some
specific improvement in JUnit5 provider. Do not press CTRL+ALT+L because there
is again unnecessary 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
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
Tibor17 commented on a change in pull request #487: URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824590490 ## File path: pom.xml ## @@ -532,8 +532,7 @@ src/test/resources/**/* src/test/resources/**/*.css **/*.jj - src/main/resources/META-INF/services/org.apache.maven.surefire.api.provider.SurefireProvider - +src/main/resources/META-INF/services/** Review comment: Don't change this POM, it has nothing to do with what you are aiming for. Rather do not make any additional refactoring because it is very hard to separate reasonable and non-reasonable changes. I guess you wanted to make some specific improvement in JUnit5 provider. Do not press CTRL+L because there is again unnecessary 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
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #487: [SUREFIRE-2037] Allow for surefire-junit-platform's TestMethodFilter …
Tibor17 commented on a change in pull request #487:
URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824589850
##
File path:
surefire-api/src/main/java/org/apache/maven/surefire/api/testset/TestListResolver.java
##
@@ -195,13 +195,13 @@ public boolean shouldRun( Class testClass, String
methodName )
/**
* Returns {@code true} if satisfies {@code testClassFile} and {@code
methodName} filter.
*
- * @param testClassFile format must be e.g. "my/package/MyTest.class"
including class extension; or null
- * @param methodName real test-method name; or null
+ * @param containerName format must be e.g. "my/package/MyTest.class"
including class extension; or null
Review comment:
Don't change this class, it has nothing to do with what you are aiming
for. Rather do not make any additional refactoring because it is very hard to
separate reasonable and non-reasonable changes. I guess you wanted to make some
specific improvement in JUnit5 provider. Do not press CTRL+L because there is
again unnecessary 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
[GitHub] [maven] laeubi commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
laeubi commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1064962195 > I tend to think that the current design is somewhat broken if whenever you need to lookup a component, you need to go through a complex setup in order to find where to load the component from. You don't need it "whenever you lookup" you only need it for the specific cases of where you have a project-scoped extension and that is required to isolate the class-realms to not leak classes from one project into another. > The plexus container has support for importing from various _visible_ realms. I think at each stage of the build (after entering the session scope, during the build of a given project, during the execution of a mojo), a corresponding realm should be setup and associated to the TCCL so that lookups can be performed with the correct visibility and scope. Sure why not, but then your extension would still not work in a session-scoped nor a singelton created in "root scope"... So your usage has only worked due to a bug (as far as I can tell from the provided information here) and I don't see how it could work with other ways of class-loader isolation. > so that's definitely not an issue. So I'm really confused *what* is the issue then? As from the code, your problematic component is to be used in a singleton injected and called, how is it (and why) supposed to work if it is defined in a project scope? `extensions.xml` is exactly the place to place such "global for all" plugins, the `pom.xml` is not ... If one likes to "break" the rules then additional setup is required, unless maven supports better ways, e.g. `@ProjectScoped` but then still someone has to setup this scope at distinct points (e.g. wen executing the mojos of a project and can't assume it works everywhere... so most probably `MojoExecutor` has to not reference the `MojoExecutionStrategy` in the constructor but look it up in the actual call. -- 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] gnodet commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
gnodet commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1064950742 > Just for references as I recently added support for project-scoped WorkspaceReaders, if you like to support such components one needs to add explicit support for them similar to: > > [...] > > as you see, the calling code should also be aware that there are _multiple_ items and has to handle this (combine, call in a row, throw exception ...). I tend to think that the current design is somewhat broken if whenever you need to lookup a component, you need to go through a complex setup in order to find where to load the component from. The plexus container has support for importing from various _visible_ realms. I think at each stage of the build (after entering the session scope, during the build of a given project, during the execution of a mojo), a corresponding realm should be setup and associated to the TCCL so that lookups can be performed with the correct visibility and scope. Failing to setup such a realm with result in an inability to do loops correctly : as you explained for looking up a list, but for a single component, you'd have to deal with priority, ordering and all concerns that should be left to the container. > > but other think defining extensions in the pom is preferable > > Just in case you don't know it (and to save you from to much hassle) it is no longer required to define core-extensions in `lib/ext` you can simply define them in `.mvn/extensions.xml` of the project, and I think that's what you actually try to arcive by your "master-project-classloader" see here for the documentation: https://maven.apache.org/ref/3.8.4/maven-embedder/core-extensions.html > > You can take a look here for an example of the tycho-build extension that is a core-extension: https://github.com/eclipse/tycho/tree/master/tycho-its/projects/reactor.makeBehaviour Thx, I did set up the tests for the `m-build-cache-e` using `.mvn/extensions.xml` so that's definitely not an issue. -- 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-plugin] slawekjaranowski closed pull request #205: Exclude vulnerable commons-beanutils-1.7.0 from maven-reporting-impl …
slawekjaranowski closed pull request #205: URL: https://github.com/apache/maven-dependency-plugin/pull/205 -- 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-plugin] slawekjaranowski commented on pull request #205: Exclude vulnerable commons-beanutils-1.7.0 from maven-reporting-impl …
slawekjaranowski commented on pull request #205: URL: https://github.com/apache/maven-dependency-plugin/pull/205#issuecomment-1064929057 We have direct dependency to commons-beanutils 1.9.4, so excluding is not needed. https://github.com/apache/maven-dependency-plugin/pull/177 https://issues.apache.org/jira/browse/MDEP-797 But thanks for proposition and collaborations. -- 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] (MRESOLVER-245) Isolate Hazelcast tests
[ https://issues.apache.org/jira/browse/MRESOLVER-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504789#comment-17504789 ] Hudson commented on MRESOLVER-245: -- Build succeeded in Jenkins: Maven » Maven TLP » maven-resolver » master #11 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-resolver/job/master/11/ > Isolate Hazelcast tests > --- > > Key: MRESOLVER-245 > URL: https://issues.apache.org/jira/browse/MRESOLVER-245 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 1.8.0 > > > The named-locks-hazelcast module uses Hazelcast. The IT tests were not > properly isolated, so Hazelcast instances are able to discover other > Hazelcast instances running locally or on same network. This causes sporadic > IT failures, usually on CI, where multiple permutations are being run > possibly next to each other. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MRESOLVER-245) Isolate Hazelcast tests
[ https://issues.apache.org/jira/browse/MRESOLVER-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MRESOLVER-245. - > Isolate Hazelcast tests > --- > > Key: MRESOLVER-245 > URL: https://issues.apache.org/jira/browse/MRESOLVER-245 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 1.8.0 > > > The named-locks-hazelcast module uses Hazelcast. The IT tests were not > properly isolated, so Hazelcast instances are able to discover other > Hazelcast instances running locally or on same network. This causes sporadic > IT failures, usually on CI, where multiple permutations are being run > possibly next to each other. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MRESOLVER-245) Isolate Hazelcast tests
[ https://issues.apache.org/jira/browse/MRESOLVER-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák resolved MRESOLVER-245. --- Resolution: Fixed > Isolate Hazelcast tests > --- > > Key: MRESOLVER-245 > URL: https://issues.apache.org/jira/browse/MRESOLVER-245 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 1.8.0 > > > The named-locks-hazelcast module uses Hazelcast. The IT tests were not > properly isolated, so Hazelcast instances are able to discover other > Hazelcast instances running locally or on same network. This causes sporadic > IT failures, usually on CI, where multiple permutations are being run > possibly next to each other. -- This message was sent by Atlassian Jira (v8.20.1#820001)
