[jira] [Commented] (MCOMPILER-514) Cant stack compiler plugin argument variations
[
https://issues.apache.org/jira/browse/MCOMPILER-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645146#comment-17645146
]
Delany commented on MCOMPILER-514:
--
Ok here's my workaround
{code:java}
-Xep:SuppressWarningsWithoutExplanation:WARN
...
-Xlint:all,-processing
-XDcompilePolicy=byfile
-Xplugin:ErrorProne -XepDisableAllChecks ${build.ep}
...
EPE
EPE
-Xep:${EPE}:ERROR
EPW
EPW
-Xep:${EPW}:WARN
EPP
EPP
-XepPatchLocation:IN_PLACE -XepPatchChecks:${EPP}
{code}
Then if I want the build to fail with DefaultCharset violations
{code:java}
./mvnw -DEPE=DefaultCharset {code}
> Cant stack compiler plugin argument variations
> --
>
> Key: MCOMPILER-514
> URL: https://issues.apache.org/jira/browse/MCOMPILER-514
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.10.1
>Reporter: Delany
>Priority: Major
>
> This works
> {code:java}
>
> -Xlint:all,-processing
> -Xlint:all
> -XDcompilePolicy=byfile
> -Xplugin:ErrorProne
> -Xplugin:ErrorProne
> {code}
> But this
> {code:java}
>
> -Xlint:all,-processing
> -Xlint:all
> -XDcompilePolicy=byfile
> -Xplugin:ErrorProne
> -Xplugin:ErrorProne -XepDisableAllChecks
> {code}
> fails with this
> {noformat}
> [ERROR] org.apache.maven.cli.MavenCli - plug-in not found:
> ErrorProne{noformat}
> There is no problem stacking -Xlint argument variations, or stacking the
> -Xplugin argument (provided the argument is the same.) But it dies when the
> -Xplugin argument varies. Why should this be?
> Use case? I have separate profiles for activating various errorprone
> bugpatterns. I want a default configuration in place unless I activate one of
> these profiles. I dont want to have to edit source code every time to check a
> different bugpattern.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MINVOKER-313) Get rid of maven-artifact-transfer
[ https://issues.apache.org/jira/browse/MINVOKER-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MINVOKER-313: Assignee: Slawomir Jaranowski > Get rid of maven-artifact-transfer > -- > > Key: MINVOKER-313 > URL: https://issues.apache.org/jira/browse/MINVOKER-313 > Project: Maven Invoker Plugin > Issue Type: Improvement >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.4.0 > > > maven-artifact-transfer is used in install mojo. > Maven resolver should be used instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] marcphilipp commented on a diff in pull request #749: Add more discriminating properties to the daemon
marcphilipp commented on code in PR #749:
URL: https://github.com/apache/maven-mvnd/pull/749#discussion_r1044217427
##
common/src/main/java/org/mvndaemon/mvnd/common/Environment.java:
##
@@ -94,9 +94,16 @@ public enum Environment {
// Maven properties
//
/** The path to the Maven local repository */
-MAVEN_REPO_LOCAL("maven.repo.local", null, null, OptionType.PATH,
Flags.NONE),
+MAVEN_REPO_LOCAL("maven.repo.local", null, null, OptionType.PATH,
Flags.DISCRIMINATING | Flags.OPTIONAL),
/** The location of the maven settings file */
-MAVEN_SETTINGS("maven.settings", null, null, OptionType.PATH, Flags.NONE,
"mvn:-s", "mvn:--settings"),
+MAVEN_SETTINGS(
+"maven.settings",
+null,
+null,
+OptionType.PATH,
+Flags.DISCRIMINATING | Flags.OPTIONAL,
+"mvn:-s",
+"mvn:--settings"),
Review Comment:
@oehme Should this also apply to `-gs` and `--global-settings`?
--
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-invoker] slawekjaranowski commented on a diff in pull request #58: [MSHARED-1151] Upgrade parent to version 38
slawekjaranowski commented on code in PR #58: URL: https://github.com/apache/maven-invoker/pull/58#discussion_r1044218133 ## pom.xml: ## @@ -103,21 +103,6 @@ under the License. - Review Comment: We need overide checkstyle configuration, please look at: https://issues.apache.org/jira/browse/MPOM-371 Please check site output for checkstyle report, after: ``` mvn site -P reporting ``` ## .git-blame-ignore-revs: ## @@ -0,0 +1,21 @@ +# +# 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. +# + +# Change maven code style +354a1c24661e50e0a61ab8e6c47b27119f49e506 Review Comment: I afraid that this will change after PR merge - even with rebase We need it in separate 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-parent] slawekjaranowski merged pull request #98: [MPOM-377] Add space before close empty elements in poms
slawekjaranowski merged PR #98: URL: https://github.com/apache/maven-parent/pull/98 -- 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] (MPOM-377) Add space before close empty elements in poms
[ https://issues.apache.org/jira/browse/MPOM-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645190#comment-17645190 ] Hudson commented on MPOM-377: - Build failed in Jenkins: Maven » Maven TLP » maven-parent » master #72 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-parent/job/master/72/ > Add space before close empty elements in poms > - > > Key: MPOM-377 > URL: https://issues.apache.org/jira/browse/MPOM-377 > Project: Maven POMs > Issue Type: Improvement > Components: maven >Affects Versions: MAVEN-38 >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: MAVEN-39 > > > Release plugin add space before close empty elements, > it is a bug in release plugin - content of pom should be reformatted. > As workaround we can add a space by spotless also. > Without it release can break. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPOM-377) Add space before close empty elements in poms
[ https://issues.apache.org/jira/browse/MPOM-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-377. Resolution: Fixed > Add space before close empty elements in poms > - > > Key: MPOM-377 > URL: https://issues.apache.org/jira/browse/MPOM-377 > Project: Maven POMs > Issue Type: Improvement > Components: maven >Affects Versions: MAVEN-38 >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: MAVEN-39 > > > Release plugin add space before close empty elements, > it is a bug in release plugin - content of pom should be reformatted. > As workaround we can add a space by spotless also. > Without it release can break. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet merged pull request #861: [MNG-7578] Fallback on Linux executable in Windows for findTool utility
gnodet merged PR #861: URL: https://github.com/apache/maven/pull/861 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7578) Building Linux image on Windows impossible (patch incuded)
[
https://issues.apache.org/jira/browse/MNG-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645198#comment-17645198
]
ASF GitHub Bot commented on MNG-7578:
-
gnodet merged PR #861:
URL: https://github.com/apache/maven/pull/861
> Building Linux image on Windows impossible (patch incuded)
> --
>
> Key: MNG-7578
> URL: https://issues.apache.org/jira/browse/MNG-7578
> Project: Maven
> Issue Type: Bug
> Components: Core, Toolchains
>Affects Versions: 3.8.6
>Reporter: Eugen Labun
>Assignee: Maarten Mulders
>Priority: Major
>
> If you try to find `javac` in a Linux JDK using `Toolchain.findTool()`
> method, this will fail when the build is running on Windows, since the
> implementation
> [JavaToolchainImpl#findTool()|https://github.com/apache/maven/blob/maven-3.8.6/maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainImpl.java#L74-L86]
> appends ".exe" to the toolName (causing `javac.exe` is not found):
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" ); //NOI18N
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName + ( Os.isFamily( "windows" )
> ? ".exe" : "" ) ); // NOI18N
> if ( tool.exists() )
> {
> return tool;
> }
> }
> return null;
>}
> {code}
> The current workaround is to manually add a fake `javac.exe` file to the JDK
> `bin` directory. See [tool chain issue (building linux image on windows
> machine)|https://github.com/moditect/moditect/issues/107] in moditect project.
> The `findTool` method could yet easily be changed to search for exact
> `toolName` as requested, with a fallback to `toolName.exe` for backward
> compatibility:
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" );
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName );
> if ( tool.exists() )
> {
> return tool;
> }
> File toolExe = new File( bin, toolName + ".exe" );
> if ( toolExe.exists() )
> {
> return toolExe;
> }
> }
> return null;
>}
> {code}
> This would solve the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7578) Building Linux image on Windows impossible (patch incuded)
[
https://issues.apache.org/jira/browse/MNG-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645199#comment-17645199
]
Hudson commented on MNG-7578:
-
Build failed in Jenkins: Maven » Maven TLP » maven » master #151
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/151/
> Building Linux image on Windows impossible (patch incuded)
> --
>
> Key: MNG-7578
> URL: https://issues.apache.org/jira/browse/MNG-7578
> Project: Maven
> Issue Type: Bug
> Components: Core, Toolchains
>Affects Versions: 3.8.6
>Reporter: Eugen Labun
>Assignee: Maarten Mulders
>Priority: Major
>
> If you try to find `javac` in a Linux JDK using `Toolchain.findTool()`
> method, this will fail when the build is running on Windows, since the
> implementation
> [JavaToolchainImpl#findTool()|https://github.com/apache/maven/blob/maven-3.8.6/maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainImpl.java#L74-L86]
> appends ".exe" to the toolName (causing `javac.exe` is not found):
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" ); //NOI18N
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName + ( Os.isFamily( "windows" )
> ? ".exe" : "" ) ); // NOI18N
> if ( tool.exists() )
> {
> return tool;
> }
> }
> return null;
>}
> {code}
> The current workaround is to manually add a fake `javac.exe` file to the JDK
> `bin` directory. See [tool chain issue (building linux image on windows
> machine)|https://github.com/moditect/moditect/issues/107] in moditect project.
> The `findTool` method could yet easily be changed to search for exact
> `toolName` as requested, with a fallback to `toolName.exe` for backward
> compatibility:
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" );
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName );
> if ( tool.exists() )
> {
> return tool;
> }
> File toolExe = new File( bin, toolName + ".exe" );
> if ( toolExe.exists() )
> {
> return toolExe;
> }
> }
> return null;
>}
> {code}
> This would solve the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7578) Building Linux image on Windows impossible (patch incuded)
[
https://issues.apache.org/jira/browse/MNG-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-7578.
Fix Version/s: 4.0.0-alpha-3
Resolution: Fixed
> Building Linux image on Windows impossible (patch incuded)
> --
>
> Key: MNG-7578
> URL: https://issues.apache.org/jira/browse/MNG-7578
> Project: Maven
> Issue Type: Bug
> Components: Core, Toolchains
>Affects Versions: 3.8.6
>Reporter: Eugen Labun
>Assignee: Maarten Mulders
>Priority: Major
> Fix For: 4.0.0-alpha-3
>
>
> If you try to find `javac` in a Linux JDK using `Toolchain.findTool()`
> method, this will fail when the build is running on Windows, since the
> implementation
> [JavaToolchainImpl#findTool()|https://github.com/apache/maven/blob/maven-3.8.6/maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainImpl.java#L74-L86]
> appends ".exe" to the toolName (causing `javac.exe` is not found):
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" ); //NOI18N
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName + ( Os.isFamily( "windows" )
> ? ".exe" : "" ) ); // NOI18N
> if ( tool.exists() )
> {
> return tool;
> }
> }
> return null;
>}
> {code}
> The current workaround is to manually add a fake `javac.exe` file to the JDK
> `bin` directory. See [tool chain issue (building linux image on windows
> machine)|https://github.com/moditect/moditect/issues/107] in moditect project.
> The `findTool` method could yet easily be changed to search for exact
> `toolName` as requested, with a fallback to `toolName.exe` for backward
> compatibility:
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" );
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName );
> if ( tool.exists() )
> {
> return tool;
> }
> File toolExe = new File( bin, toolName + ".exe" );
> if ( toolExe.exists() )
> {
> return toolExe;
> }
> }
> return null;
>}
> {code}
> This would solve the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-invoker] slawekjaranowski commented on a diff in pull request #58: [MSHARED-1151] Upgrade parent to version 38
slawekjaranowski commented on code in PR #58: URL: https://github.com/apache/maven-invoker/pull/58#discussion_r1044254151 ## src/main/java/org/apache/maven/shared/invoker/CommandLineConfigurationException.java: ## @@ -1,3 +1,21 @@ +/* + * 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 Review Comment: Please check duplicate license headers try: ``` git grep -c "Licensed to the Apache Software Foundation" | grep -v ":1" ``` -- 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-300) Introduce new API as replacement for FileTransform API
[ https://issues.apache.org/jira/browse/MRESOLVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-300: -- Fix Version/s: 1.9.3 > Introduce new API as replacement for FileTransform API > -- > > Key: MRESOLVER-300 > URL: https://issues.apache.org/jira/browse/MRESOLVER-300 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.3 > > > Introduce new API as replacement for deprecated FileTransform API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] oehme commented on a diff in pull request #749: Add more discriminating properties to the daemon
oehme commented on code in PR #749:
URL: https://github.com/apache/maven-mvnd/pull/749#discussion_r1044286021
##
common/src/main/java/org/mvndaemon/mvnd/common/Environment.java:
##
@@ -94,9 +94,16 @@ public enum Environment {
// Maven properties
//
/** The path to the Maven local repository */
-MAVEN_REPO_LOCAL("maven.repo.local", null, null, OptionType.PATH,
Flags.NONE),
+MAVEN_REPO_LOCAL("maven.repo.local", null, null, OptionType.PATH,
Flags.DISCRIMINATING | Flags.OPTIONAL),
/** The location of the maven settings file */
-MAVEN_SETTINGS("maven.settings", null, null, OptionType.PATH, Flags.NONE,
"mvn:-s", "mvn:--settings"),
+MAVEN_SETTINGS(
+"maven.settings",
+null,
+null,
+OptionType.PATH,
+Flags.DISCRIMINATING | Flags.OPTIONAL,
+"mvn:-s",
+"mvn:--settings"),
Review Comment:
Yes, it should, but from a cursory look at this class it's not yet supported
at all. I also think that the Java Home should be discriminating and that the
actual content of the settings.xml should be considered as well, but all of
these seemed out of scope for 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
[jira] [Created] (MRESOLVER-306) Make GenericVersionScheme.parseVersionConstraint(...) throw exception when comma separated version are passed
Konrad Windszus created MRESOLVER-306:
-
Summary: Make GenericVersionScheme.parseVersionConstraint(...)
throw exception when comma separated version are passed
Key: MRESOLVER-306
URL: https://issues.apache.org/jira/browse/MRESOLVER-306
Project: Maven Resolver
Issue Type: Improvement
Components: Resolver
Reporter: Konrad Windszus
Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
called an unexpected Object is returned which returns {{false}} for every
version passed to {{VersionConstraint.containsVersion}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-306) Make GenericVersionScheme.parseVersionConstraint(...) throw exception when comma separated version are passed
[
https://issues.apache.org/jira/browse/MRESOLVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MRESOLVER-306:
--
Description:
Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
called an unexpected Object is returned which returns {{false}} for every
version passed to {{VersionConstraint.containsVersion}} and also returns other
values for {{VersionConstraint.getVersion().compareTo(some other version)}}}
than {{VersionRange.getRecommendedVersion().compareTo(some other version)}}
(https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
Instead passing such invalid string should lead to an
{{InvalidVersionSpecificationException}}.
was:Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}}
is called an unexpected Object is returned which returns {{false}} for every
version passed to {{VersionConstraint.containsVersion}}.
> Make GenericVersionScheme.parseVersionConstraint(...) throw exception when
> comma separated version are passed
> -
>
> Key: MRESOLVER-306
> URL: https://issues.apache.org/jira/browse/MRESOLVER-306
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
> called an unexpected Object is returned which returns {{false}} for every
> version passed to {{VersionConstraint.containsVersion}} and also returns
> other values for {{VersionConstraint.getVersion().compareTo(some other
> version)}}} than {{VersionRange.getRecommendedVersion().compareTo(some other
> version)}}
> (https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
> Instead passing such invalid string should lead to an
> {{InvalidVersionSpecificationException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-306) Make GenericVersionScheme.parseVersionConstraint(...) throw exception when comma-separated version not starting with "(" or "[" are passed
[
https://issues.apache.org/jira/browse/MRESOLVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MRESOLVER-306:
--
Summary: Make GenericVersionScheme.parseVersionConstraint(...) throw
exception when comma-separated version not starting with "(" or "[" are passed
(was: Make GenericVersionScheme.parseVersionConstraint(...) throw exception
when comma separated version are passed)
> Make GenericVersionScheme.parseVersionConstraint(...) throw exception when
> comma-separated version not starting with "(" or "[" are passed
> --
>
> Key: MRESOLVER-306
> URL: https://issues.apache.org/jira/browse/MRESOLVER-306
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
> called an unexpected Object is returned which returns {{false}} for every
> version passed to {{VersionConstraint.containsVersion}} and also returns
> other values for {{VersionConstraint.getVersion().compareTo(some other
> version)}}} than {{VersionRange.getRecommendedVersion().compareTo(some other
> version)}}
> (https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
> Instead passing such invalid string should lead to an
> {{InvalidVersionSpecificationException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-306) Make GenericVersionScheme.parseVersionConstraint(...) throw exception when comma-separated version not starting with "(" or "[" are passed
[
https://issues.apache.org/jira/browse/MRESOLVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MRESOLVER-306:
--
Description:
Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
called an unexpected Object is returned which returns {{false}} for every
version passed to {{VersionConstraint.containsVersion}} and also returns other
values for {{VersionConstraint.getVersion().compareTo(some other version)}}}
than
{{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
other version)}}
(https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
Instead passing such invalid string should lead to an
{{InvalidVersionSpecificationException}}.
was:
Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
called an unexpected Object is returned which returns {{false}} for every
version passed to {{VersionConstraint.containsVersion}} and also returns other
values for {{VersionConstraint.getVersion().compareTo(some other version)}}}
than {{VersionRange.getRecommendedVersion().compareTo(some other version)}}
(https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
Instead passing such invalid string should lead to an
{{InvalidVersionSpecificationException}}.
> Make GenericVersionScheme.parseVersionConstraint(...) throw exception when
> comma-separated version not starting with "(" or "[" are passed
> --
>
> Key: MRESOLVER-306
> URL: https://issues.apache.org/jira/browse/MRESOLVER-306
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
> called an unexpected Object is returned which returns {{false}} for every
> version passed to {{VersionConstraint.containsVersion}} and also returns
> other values for {{VersionConstraint.getVersion().compareTo(some other
> version)}}} than
> {{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
> other version)}}
> (https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
> Instead passing such invalid string should lead to an
> {{InvalidVersionSpecificationException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-306) Make GenericVersionScheme.parseVersionConstraint(...) throw exception when comma-separated version not starting with "(" or "[" are passed
[
https://issues.apache.org/jira/browse/MRESOLVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MRESOLVER-306:
--
Description:
Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
called an unexpected Object is returned which returns {{false}} for every
version passed to {{VersionConstraint.containsVersion}} and also returns other
values for {{VersionConstraint.getVersion().compareTo(some other version)}}
than
{{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
other version)}}
(https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
Instead passing such invalid string should lead to an
{{InvalidVersionSpecificationException}}.
was:
Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
called an unexpected Object is returned which returns {{false}} for every
version passed to {{VersionConstraint.containsVersion}} and also returns other
values for {{VersionConstraint.getVersion().compareTo(some other version)}}}
than
{{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
other version)}}
(https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
Instead passing such invalid string should lead to an
{{InvalidVersionSpecificationException}}.
> Make GenericVersionScheme.parseVersionConstraint(...) throw exception when
> comma-separated version not starting with "(" or "[" are passed
> --
>
> Key: MRESOLVER-306
> URL: https://issues.apache.org/jira/browse/MRESOLVER-306
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
> called an unexpected Object is returned which returns {{false}} for every
> version passed to {{VersionConstraint.containsVersion}} and also returns
> other values for {{VersionConstraint.getVersion().compareTo(some other
> version)}} than
> {{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
> other version)}}
> (https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
> Instead passing such invalid string should lead to an
> {{InvalidVersionSpecificationException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-compiler-plugin] gnodet opened a new pull request, #159: Make compileSourceRoots read/write so that it can be used in multi-release jars without issuing a warning
gnodet opened a new pull request, #159: URL: https://github.com/apache/maven-compiler-plugin/pull/159 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MCOMPILER) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MCOMPILER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MCOMPILER-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-306) Make GenericVersionScheme.parseVersionConstraint(...) throw exception when comma-separated version string not starting with "(" or "[" is passed
[
https://issues.apache.org/jira/browse/MRESOLVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MRESOLVER-306:
--
Summary: Make GenericVersionScheme.parseVersionConstraint(...) throw
exception when comma-separated version string not starting with "(" or "[" is
passed (was: Make GenericVersionScheme.parseVersionConstraint(...) throw
exception when comma-separated version not starting with "(" or "[" are passed)
> Make GenericVersionScheme.parseVersionConstraint(...) throw exception when
> comma-separated version string not starting with "(" or "[" is passed
>
>
> Key: MRESOLVER-306
> URL: https://issues.apache.org/jira/browse/MRESOLVER-306
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
> called an unexpected Object is returned which returns {{false}} for every
> version passed to {{VersionConstraint.containsVersion}} and also returns
> other values for {{VersionConstraint.getVersion().compareTo(some other
> version)}} than
> {{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
> other version)}}
> (https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
> Instead passing such invalid string should lead to an
> {{InvalidVersionSpecificationException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-306) Make GenericVersionScheme.parseVersionConstraint(...) throw exception when comma-separated version string not starting with "(" or "[" is passed
[
https://issues.apache.org/jira/browse/MRESOLVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MRESOLVER-306:
--
Description:
Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
called an unexpected Object is returned which returns {{false}} for every
version passed to {{VersionConstraint.containsVersion}} and also returns other
values for {{VersionConstraint.getVersion().compareTo(some other version)}}
than
{{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
other version)}}
(https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
Instead passing such invalid string should lead to an
{{InvalidVersionSpecificationException}}.
For a real-life example of such invalid version ranges refer to
https://github.com/mybatis/parent/issues/401.
was:
Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
called an unexpected Object is returned which returns {{false}} for every
version passed to {{VersionConstraint.containsVersion}} and also returns other
values for {{VersionConstraint.getVersion().compareTo(some other version)}}
than
{{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
other version)}}
(https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
Instead passing such invalid string should lead to an
{{InvalidVersionSpecificationException}}.
> Make GenericVersionScheme.parseVersionConstraint(...) throw exception when
> comma-separated version string not starting with "(" or "[" is passed
>
>
> Key: MRESOLVER-306
> URL: https://issues.apache.org/jira/browse/MRESOLVER-306
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
> called an unexpected Object is returned which returns {{false}} for every
> version passed to {{VersionConstraint.containsVersion}} and also returns
> other values for {{VersionConstraint.getVersion().compareTo(some other
> version)}} than
> {{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
> other version)}}
> (https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
> Instead passing such invalid string should lead to an
> {{InvalidVersionSpecificationException}}.
> For a real-life example of such invalid version ranges refer to
> https://github.com/mybatis/parent/issues/401.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNGSITE-503) add .well-known/security.txt
Benjamin Marwell created MNGSITE-503: Summary: add .well-known/security.txt Key: MNGSITE-503 URL: https://issues.apache.org/jira/browse/MNGSITE-503 Project: Maven Project Web Site Issue Type: Improvement Reporter: Benjamin Marwell Assignee: Benjamin Marwell As per consensus on the mailing list (+1 from [~rmannibucau] and me), we should add a file `.well-known/security.txt`. I will prepare a PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-doxia] dependabot[bot] opened a new pull request, #129: Bump annotations from 15.0 to 23.1.0
dependabot[bot] opened a new pull request, #129: URL: https://github.com/apache/maven-doxia/pull/129 Bumps [annotations](https://github.com/JetBrains/java-annotations) from 15.0 to 23.1.0. Release notes Sourced from https://github.com/JetBrains/java-annotations/releases";>annotations's releases. 23.1.0 Added new annotation: `@ApiStatus.Obsolete 23.0.0 Added new annotations: @BlockingExecutor and @NonBlockingExecutor. 22.0.0 Added new annotations: @Blocking and @NonBlocking. 21.0.1 Multi-Release Jar: Manifest fixed 21.0.0 Added new annotation: @UnknownNullability. Proper JPMS module. 20.1.0 Added TYPE_USE target for PropertyKey annotation. 20.0.0 Added new annotation: @MustBeInvokedByOverriders. Added new annotation: @VisibleForTesting. Added TYPE_USE target for NonNls annotation. String attributes of annotations are marked as @NonNls where applicable. Documentation for @Nls and @NonNls updated: now they could be used as meta-annotations. Documentation added for @Subst annotation. 19.0.0 Added new annotations: @Unmodifiable and @UnmodifiableView. Added TYPE_USE target for Nls annotation. Improved the documentation for @Language, @Pattern, @RegExp, and @ApiStatus.Internal annotations. Fixed Automatic-Module-Name for Java 5. 18.0.0 Added new annotation family @ApiStatus.* Added new annotation @Debug.Renderer 17.0.0 Added new annotation: @Range 16.0.3 Added Automatic-Module-Name to MANIFEST.MF 16.0.2 Improved the documentation for the @Contract annotation. 16.0.1 No release notes provided. Changelog Sourced from https://github.com/JetBrains/java-annotations/blob/master/CHANGELOG.md";>annotations's changelog. Version 23.1.0 Added new annotation: @ApiStatus.Obsolete. Version 23.0.0 Added new annotations: @BlockingExecutor and @NonBlockingExecutor. Version 22.0.0 Added new annotations: @Blocking and @NonBlocking. Version 21.0.1 Multi-Release Jar: Manifest fixed Version 21.0.0 Added new annotation: @UnknownNullability. Proper JPMS module. JdkConstants deprecated. Version 20.1.0 Added TYPE_USE target for PropertyKey annotation. Version 20.0.0 Added new annotation: @MustBeInvokedByOverriders. Added new annotation: @VisibleForTesting. Added TYPE_USE target for NonNls annotation. String attributes of annotations are marked as @NonNls where applicable. Documentation for @Nls and @NonNls updated: now they could be used as meta-annotations. Documentation added for @Subst annotation. Version 19.0.0 Added new annotations: @Unmodifiable and @UnmodifiableView. Added TYPE_USE target for Nls annotation. Improved the documentation for @Language, @Pattern, @RegExp, and @ApiStatus.Internal annotations. Fixed Automatic-Module-Name for Java 5. Version 18.0.0 Added new annotation family @ApiStatus.* Added new annotation @Debug.Renderer Version 17.0.0 Added new annotation: @Range ... (truncated) Commits See full diff in https://github.com/JetBrains/java-annotations/commits/23.1.0";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Depe
[GitHub] [maven-doxia] dependabot[bot] commented on pull request #113: Bump annotations from 15.0 to 23.0.0
dependabot[bot] commented on PR #113: URL: https://github.com/apache/maven-doxia/pull/113#issuecomment-1344220956 Superseded by #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-doxia] dependabot[bot] closed pull request #113: Bump annotations from 15.0 to 23.0.0
dependabot[bot] closed pull request #113: Bump annotations from 15.0 to 23.0.0 URL: https://github.com/apache/maven-doxia/pull/113 -- 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-invoker] psiroky commented on a diff in pull request #58: [MSHARED-1151] Upgrade parent to version 38
psiroky commented on code in PR #58: URL: https://github.com/apache/maven-invoker/pull/58#discussion_r1044405730 ## .git-blame-ignore-revs: ## @@ -0,0 +1,21 @@ +# +# 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. +# + +# Change maven code style +354a1c24661e50e0a61ab8e6c47b27119f49e506 Review Comment: Yeah, I'll remove it from 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
[jira] [Commented] (SUREFIRE-2103) and causing Java heap space issue.
[ https://issues.apache.org/jira/browse/SUREFIRE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645275#comment-17645275 ] Elliotte Rusty Harold commented on SUREFIRE-2103: - Thanks. This sounds like a bug we should fix. That said, it is very bad practice for any test, integration or unit, to write 1 GB of logs. In fact it's bad practice for a test to write 1 MB of logs. Tests should log detailed failure information for any test that fails, and absolutely nothing for any test that passes. Otherwise the information you need to debug a failing test is lost in a sea of log junk no one cares about and no one will ever read. Irrespective of whether we fix this bug, I strongly recommend fixing the tests to log far, far less data. > and causing Java heap space issue. > - > > Key: SUREFIRE-2103 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2103 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M5, 3.0.0-M6 >Reporter: parita jivani >Priority: Blocker > > We have Java test projects, which has different integration and UI tests. We > are upgrading failsafe and surefire version from 2.17 to 3.0.0-M5. After > upgrade few projects were failing with Java heap space. After analysing the > issue, we got to know that failsafe reports creation is causing the memory > issue. Failsafe plugin is writing and elements > with log details. In our case, build logs contains huge data of script > execution logs(around >= 1GB). While creating failsafe report, failsafe > plugin is writing entire logs to *.xml report and causing failure due to java > heap space. > > For issue resolution my suggestion is to get some configuration to > unable/disable option for tags would really help. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SUREFIRE-2022) MAVEN - PluginExecutionException
[
https://issues.apache.org/jira/browse/SUREFIRE-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved SUREFIRE-2022.
-
Resolution: Cannot Reproduce
> MAVEN - PluginExecutionException
>
>
> Key: SUREFIRE-2022
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2022
> Project: Maven Surefire
> Issue Type: Bug
> Environment: SNAPSHOT : 0.1
> Maven: 3.8.4
> Maven-Surefire : 2.19
>Reporter: Jo Jaafar
>Assignee: Tibor Digana
>Priority: Blocker
> Labels: newbie
> Fix For: waiting-for-apache-feedback
>
> Attachments: directory-list.PNG, screenshot-1.png
>
> Original Estimate: 68h
> Remaining Estimate: 68h
>
> The issue started whereby the maven surefire plugin is turn up failed. even
> before this theres issue with maven 2.4.1 but i have upgraded to maven 3.8.4.
> As whole and by right it should solve the mentioned issues. But still
> appeared.
>
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] Failed to
> execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test
> (default-test) on project ABCApplications _Automation: Execution default-test
> of goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
> testSuiteXmlFiles0 has null value -> [Help 1]{color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] {color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] To see the
> full stack trace of the errors, re-run Maven with the -e switch.{color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] Re-run
> Maven using the -X switch to enable full debug logging.{color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] {color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] For more
> information about the errors and possible solutions, please read the
> following articles:{color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException{color}
> {color:#11}The process
> 'C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.4\bin\mvn.cmd' failed
> with exit code 1{color}
> {color:#11}Could not retrieve code analysis results - Maven run
> failed.{color}
> {color:#11}No test result files matching
> D:\a\1\s{color}{color:#aa0982}\*{color}{color:#994cc3}*{color}{color:#994cc3}\surefire-reports\TEST-{color}{color:#994cc3}*{color}{color:#11}.xml
> were found, so publishing JUnit test results is being skipped.{color}
> {color:#11}##[{color}{color:#403f53}error{color}{color:#11}]Build
> failed.{color}
> {color:#11}Finishing: Maven pom.xml{color}
>
> Since im new to JAVA (recently change). Theres alot of gray area on this.
> Hope everyone who see this can help me on this. its already prolong for quite
> sometime.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2103) and causing Java heap space issue.
[ https://issues.apache.org/jira/browse/SUREFIRE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated SUREFIRE-2103: Priority: Critical (was: Blocker) > and causing Java heap space issue. > - > > Key: SUREFIRE-2103 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2103 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M5, 3.0.0-M6 >Reporter: parita jivani >Priority: Critical > > We have Java test projects, which has different integration and UI tests. We > are upgrading failsafe and surefire version from 2.17 to 3.0.0-M5. After > upgrade few projects were failing with Java heap space. After analysing the > issue, we got to know that failsafe reports creation is causing the memory > issue. Failsafe plugin is writing and elements > with log details. In our case, build logs contains huge data of script > execution logs(around >= 1GB). While creating failsafe report, failsafe > plugin is writing entire logs to *.xml report and causing failure due to java > heap space. > > For issue resolution my suggestion is to get some configuration to > unable/disable option for tags would really help. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SUREFIRE-2022) MAVEN - PluginExecutionException
[
https://issues.apache.org/jira/browse/SUREFIRE-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed SUREFIRE-2022.
---
Can reopen if more details are forthcoming
> MAVEN - PluginExecutionException
>
>
> Key: SUREFIRE-2022
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2022
> Project: Maven Surefire
> Issue Type: Bug
> Environment: SNAPSHOT : 0.1
> Maven: 3.8.4
> Maven-Surefire : 2.19
>Reporter: Jo Jaafar
>Assignee: Tibor Digana
>Priority: Blocker
> Labels: newbie
> Fix For: waiting-for-apache-feedback
>
> Attachments: directory-list.PNG, screenshot-1.png
>
> Original Estimate: 68h
> Remaining Estimate: 68h
>
> The issue started whereby the maven surefire plugin is turn up failed. even
> before this theres issue with maven 2.4.1 but i have upgraded to maven 3.8.4.
> As whole and by right it should solve the mentioned issues. But still
> appeared.
>
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] Failed to
> execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test
> (default-test) on project ABCApplications _Automation: Execution default-test
> of goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
> testSuiteXmlFiles0 has null value -> [Help 1]{color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] {color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] To see the
> full stack trace of the errors, re-run Maven with the -e switch.{color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] Re-run
> Maven using the -X switch to enable full debug logging.{color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] {color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] For more
> information about the errors and possible solutions, please read the
> following articles:{color}
> {color:#11}[{color}{color:#403f53}ERROR{color}{color:#11}] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException{color}
> {color:#11}The process
> 'C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.4\bin\mvn.cmd' failed
> with exit code 1{color}
> {color:#11}Could not retrieve code analysis results - Maven run
> failed.{color}
> {color:#11}No test result files matching
> D:\a\1\s{color}{color:#aa0982}\*{color}{color:#994cc3}*{color}{color:#994cc3}\surefire-reports\TEST-{color}{color:#994cc3}*{color}{color:#11}.xml
> were found, so publishing JUnit test results is being skipped.{color}
> {color:#11}##[{color}{color:#403f53}error{color}{color:#11}]Build
> failed.{color}
> {color:#11}Finishing: Maven pom.xml{color}
>
> Since im new to JAVA (recently change). Theres alot of gray area on this.
> Hope everyone who see this can help me on this. its already prolong for quite
> sometime.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SUREFIRE-2087) rerunFailingTestsCount incorrectly marks failed parametrized test as pass
[ https://issues.apache.org/jira/browse/SUREFIRE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved SUREFIRE-2087. - Resolution: Not A Problem "If 1st iteration of the test passes and the 2nd one fails, it still marks the test as flaky passed." That sounds correct. If there's something I'm missing about this and you can point to docs that say otherwise, please reopen. A reproducible example might also help. > rerunFailingTestsCount incorrectly marks failed parametrized test as pass > - > > Key: SUREFIRE-2087 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2087 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M4 >Reporter: Ramanan Rajendran >Priority: Critical > > rerunFailingTestsCount is not working as expected with junit5 > `@ParameterizedTest` > If 1st iteration of the test passes and the 2nd one fails, it still marks the > test as flaky passed. > Eg: In the following run, iteration 1 with input A passed but iteration 2 > with input B failed. Iteration 2 was rerun 2 times and failed in all the > attempts. Instead of failing TestA, it's marked as flaky giving an overall > pass for the test suite. I believe it's using the Run 1 PASS as a gate to > mark the whole test as a pass. > > [INFO] Run 1: PASS > [ERROR] Run 2: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 3: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 4: TestA.iteration2:101 1 expectation failed. > <400> doesn't match actual status code <401>. > > Tests run: 23, Failures: 0, Errors: 0, Skipped: 2, Flakes: 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SUREFIRE-2087) rerunFailingTestsCount incorrectly marks failed parametrized test as pass
[ https://issues.apache.org/jira/browse/SUREFIRE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed SUREFIRE-2087. --- > rerunFailingTestsCount incorrectly marks failed parametrized test as pass > - > > Key: SUREFIRE-2087 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2087 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M4 >Reporter: Ramanan Rajendran >Priority: Critical > > rerunFailingTestsCount is not working as expected with junit5 > `@ParameterizedTest` > If 1st iteration of the test passes and the 2nd one fails, it still marks the > test as flaky passed. > Eg: In the following run, iteration 1 with input A passed but iteration 2 > with input B failed. Iteration 2 was rerun 2 times and failed in all the > attempts. Instead of failing TestA, it's marked as flaky giving an overall > pass for the test suite. I believe it's using the Run 1 PASS as a gate to > mark the whole test as a pass. > > [INFO] Run 1: PASS > [ERROR] Run 2: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 3: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 4: TestA.iteration2:101 1 expectation failed. > <400> doesn't match actual status code <401>. > > Tests run: 23, Failures: 0, Errors: 0, Skipped: 2, Flakes: 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2027) Flaky test AsyncSocketTest
[
https://issues.apache.org/jira/browse/SUREFIRE-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645279#comment-17645279
]
Elliotte Rusty Harold commented on SUREFIRE-2027:
-
Agreed this should not be part of the standard suite. Where should we move it?
> Flaky test AsyncSocketTest
> --
>
> Key: SUREFIRE-2027
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2027
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Olivier Lamy
>Priority: Critical
>
> This looks to be a flaky test
> {quote}{\{Error: Tests run: 193, Failures: 0, Errors: 1, Skipped: 0, Time
> elapsed: 16.435 s <<< FAILURE! - in org.apache.maven.JUnit4SuiteTest }}
> {\{Error: org.apache.maven.surefire.api.util.internal.AsyncSocketTest.test
> Time elapsed: 5.311 s <<< ERROR! }}
> {{[694|https://github.com/apache/maven-surefire/runs/5349295808?check_suite_focus=true#step:7:694]java.lang.AssertionError:
> }}
> {{[695|https://github.com/apache/maven-surefire/runs/5349295808?check_suite_focus=true#step:7:695]}}
> {{[696|https://github.com/apache/maven-surefire/runs/5349295808?check_suite_focus=true#step:7:696]Expecting
> actual: }}
> {{[697|https://github.com/apache/maven-surefire/runs/5349295808?check_suite_focus=true#step:7:697]
> 1237L }}
> {{[698|https://github.com/apache/maven-surefire/runs/5349295808?check_suite_focus=true#step:7:698]to
> be less than: }}
> {{[699|https://github.com/apache/maven-surefire/runs/5349295808?check_suite_focus=true#step:7:699]
> 1000L }}
> {{[700|https://github.com/apache/maven-surefire/runs/5349295808?check_suite_focus=true#step:7:700]
> at
> org.apache.maven.surefire.api.util.internal.AsyncSocketTest.test(AsyncSocketTest.java:185)}}
> {quote}
>
> The code here
> [https://github.com/apache/maven-surefire/blob/3050d2e32b957bbc98112979c27e977a39933fa6/surefire-api/src/test/java/org/apache/maven/surefire/api/util/internal/AsyncSocketTest.java#L182]
> is making some assumptions which really depends on the network of the node
> where tests are running. Time to transfer data on a node cannot be evaluate
> with such strict figures it depends how busy is the operating system.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-1941) Allow overriding PpidChecker OS command line in POM configuration
[
https://issues.apache.org/jira/browse/SUREFIRE-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated SUREFIRE-1941:
Priority: Major (was: Critical)
> Allow overriding PpidChecker OS command line in POM configuration
> -
>
> Key: SUREFIRE-1941
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1941
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.22.2
>Reporter: Marc Batchelor
>Priority: Major
>
> There are many Linux and Unix variants. The PpidChecker has received several
> fixes over time to handle various edge cases when checking to make sure that
> the process is still alive. When PpidChecker doesn't detect that the test is
> running because of some variant behavior as it relates to the output format
> of /bin/ps, the developer's only recourse is to disable forking which makes
> the test execution take longer.
> This improvement would allow a configuration setting to override the default
> command issued to the operating system to provide the process status in the
> form that PpidChecker can use.
> For example:
> {noformat}
>
> ...
>
> /other/bin/ps -o etime:1=,pid:1= -p %d
>
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-invoker] psiroky commented on a diff in pull request #58: [MSHARED-1151] Upgrade parent to version 38
psiroky commented on code in PR #58: URL: https://github.com/apache/maven-invoker/pull/58#discussion_r1044416395 ## src/main/java/org/apache/maven/shared/invoker/CommandLineConfigurationException.java: ## @@ -1,3 +1,21 @@ +/* + * 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 Review Comment: Huh, that's bad. I somehow relied on spotless to actually do the reformatting properly. I guess it can't really detect the existing header, since it is after the package statement and looks list like any other comment. Anyway, thanks for spotting this. Will fix 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
[jira] [Closed] (SUREFIRE-2123) Custom TestEngine Tests Not Counted in Result
[ https://issues.apache.org/jira/browse/SUREFIRE-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed SUREFIRE-2123. --- > Custom TestEngine Tests Not Counted in Result > - > > Key: SUREFIRE-2123 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2123 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Affects Versions: 2.22.2 >Reporter: Chua Chee Seng >Priority: Major > Labels: newbie > > I am working on an TestEngine implementation for ScalaTest, when mvn test run > with Surefire 2.22.2 it able to detects the TestEngine implementation through > SPI, discover and execute methods are called and the passed in > EngineExecutionListener methods are called, but weirdly enough the executed > tests are not included in the result count. Is there additional effort we > need to do for Surefire to include the executed tests in the result? > > Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SUREFIRE-2123) Custom TestEngine Tests Not Counted in Result
[ https://issues.apache.org/jira/browse/SUREFIRE-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved SUREFIRE-2123. - Resolution: Cannot Reproduce > Custom TestEngine Tests Not Counted in Result > - > > Key: SUREFIRE-2123 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2123 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Affects Versions: 2.22.2 >Reporter: Chua Chee Seng >Priority: Major > Labels: newbie > > I am working on an TestEngine implementation for ScalaTest, when mvn test run > with Surefire 2.22.2 it able to detects the TestEngine implementation through > SPI, discover and execute methods are called and the passed in > EngineExecutionListener methods are called, but weirdly enough the executed > tests are not included in the result count. Is there additional effort we > need to do for Surefire to include the executed tests in the result? > > Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-invoker] psiroky commented on a diff in pull request #58: [MSHARED-1151] Upgrade parent to version 38
psiroky commented on code in PR #58: URL: https://github.com/apache/maven-invoker/pull/58#discussion_r1044420174 ## pom.xml: ## @@ -103,21 +103,6 @@ under the License. - Review Comment: Will take a look. Thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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] elharo commented on a diff in pull request #574: [SUREFIRE-1887] Trim stacktraces to include relevant lines
elharo commented on code in PR #574: URL: https://github.com/apache/maven-surefire/pull/574#discussion_r1044420785 ## surefire-api/src/test/java/org/apache/maven/surefire/api/report/LegacyPojoStackTraceWriterTest.java: ## @@ -64,14 +65,18 @@ public void testWriteTrimmedTraceToString() MockThrowable t = new MockThrowable( stackTrace ); LegacyPojoStackTraceWriter w = new LegacyPojoStackTraceWriter( "TestSurefire3", "testQuote", t ); String out = w.writeTrimmedTraceToString(); -String expected = "junit.framework.AssertionFailedError: blah\n" + " at junit.framework.Assert.fail(Assert.java:47)\n" + "at TestSurefire3.testQuote(TestSurefire3.java:23)\n"; +String expected = "junit.framework.AssertionFailedError: blah\n" Review Comment: I'm confused. This seems to add an extra line to the output and not remove anything. Is there a test that shows these changes making stack traces simpler? -- 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] (MNGSITE-503) add .well-known/security.txt
[ https://issues.apache.org/jira/browse/MNGSITE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MNGSITE-503: - Description: As per consensus on the mailing list (+1 from [~rmannibucau] and me), we should add a file `.well-known/security.txt`. I will prepare a PR. References: * [.well-known/security.txt at maven.apache.org (mail-archive.com)|https://www.mail-archive.com/dev@maven.apache.org/msg128366.html] * [.well-known/security.txt at maven.apache.org-Apache Mail Archives|https://lists.apache.org/thread/tvfg1lx9nd72c9t4t4s3zlx6l0tpnmwy] was: As per consensus on the mailing list (+1 from [~rmannibucau] and me), we should add a file `.well-known/security.txt`. I will prepare a PR. > add .well-known/security.txt > > > Key: MNGSITE-503 > URL: https://issues.apache.org/jira/browse/MNGSITE-503 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: security > > As per consensus on the mailing list (+1 from [~rmannibucau] and me), we > should add a file `.well-known/security.txt`. > I will prepare a PR. > References: > * [.well-known/security.txt at maven.apache.org > (mail-archive.com)|https://www.mail-archive.com/dev@maven.apache.org/msg128366.html] > * [.well-known/security.txt at maven.apache.org-Apache Mail > Archives|https://lists.apache.org/thread/tvfg1lx9nd72c9t4t4s3zlx6l0tpnmwy] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-site] bmarwell opened a new pull request, #354: [MNGSITE-503] add .well-known/security.txt
bmarwell opened a new pull request, #354: URL: https://github.com/apache/maven-site/pull/354 References: * [.well-known/security.txt at maven.apache.org (mail-archive.com)](https://www.mail-archive.com/dev@maven.apache.org/msg128366.html) * [.well-known/security.txt at maven.apache.org-Apache Mail Archives](https://lists.apache.org/thread/tvfg1lx9nd72c9t4t4s3zlx6l0tpnmwy) -- 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] (MNGSITE-503) add .well-known/security.txt
[ https://issues.apache.org/jira/browse/MNGSITE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645284#comment-17645284 ] ASF GitHub Bot commented on MNGSITE-503: bmarwell opened a new pull request, #354: URL: https://github.com/apache/maven-site/pull/354 References: * [.well-known/security.txt at maven.apache.org (mail-archive.com)](https://www.mail-archive.com/dev@maven.apache.org/msg128366.html) * [.well-known/security.txt at maven.apache.org-Apache Mail Archives](https://lists.apache.org/thread/tvfg1lx9nd72c9t4t4s3zlx6l0tpnmwy) > add .well-known/security.txt > > > Key: MNGSITE-503 > URL: https://issues.apache.org/jira/browse/MNGSITE-503 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: security > > As per consensus on the mailing list (+1 from [~rmannibucau] and me), we > should add a file `.well-known/security.txt`. > I will prepare a PR. > References: > * [.well-known/security.txt at maven.apache.org > (mail-archive.com)|https://www.mail-archive.com/dev@maven.apache.org/msg128366.html] > * [.well-known/security.txt at maven.apache.org-Apache Mail > Archives|https://lists.apache.org/thread/tvfg1lx9nd72c9t4t4s3zlx6l0tpnmwy] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1887) Test Failures should not dump stack.
[ https://issues.apache.org/jira/browse/SUREFIRE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645287#comment-17645287 ] Elliotte Rusty Harold commented on SUREFIRE-1887: - I don't think this is right. Per docs, trimStackTrace controls "Whether to trim the stack trace in the reports to just the lines within the test, or show the full trace." However SUREFIRE-1887 is about something different, removing the lines from the framework code, not the user's own code. I'm not sure we can change the existing option to make that possible. It might need a new option instead. > Test Failures should not dump stack. > - > > Key: SUREFIRE-1887 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1887 > Project: Maven Surefire > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Maarten Mulders >Priority: Major > Attachments: image-2022-10-29-12-56-00-008.png, > image-2022-10-29-12-56-10-482.png, image-2022-10-29-12-57-02-825.png, > image-2022-10-29-13-01-36-151.png, maven-surefire-test-project.zip > > > Typical failing test output from the Maven surefire plugin dumps a lot of > internal state. This is incorrect. > > The purpose of the surefire plugin is to run the user's tests. These tests > are expected to fail much of the time. This a normal state. The test failure > should be reported, but this is in no way a failure of surefire itself. There > is no reason surefire should print its own stack. Indeed, this simply > obscures the real failure in the user's own code. > > ``` > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test > (default-test) on project dependencies: There are test failures. > Please refer to > /home/runner/work/cloud-opensource-java/cloud-opensource-java/dependencies/target/surefire-reports > for the individual test results. > Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump > and [date].dumpstream. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:498) > at org.apache.maven.wrapper.BootstrapMainStarter.start > (BootstrapMainStarter.java:39) > at org.apache.maven.wrapper.WrapperExecutor.execute > (WrapperExecutor.java:122) > at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:61) > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-surefire] elharo commented on pull request #574: [SUREFIRE-1887] Trim stacktraces to include relevant lines
elharo commented on PR #574: URL: https://github.com/apache/maven-surefire/pull/574#issuecomment-1344272774 I don't think this is right. Per docs, trimStackTrace controls "Whether to trim the stack trace in the reports to just the lines within the test, or show the full trace." This PR changes that behavior. At a minimum the docs need to be updated in the same PR. However SUREFIRE-1887 is about something different, removing the lines from the framework code, not the user's own code. I'm not sure we can change the existing option to make that possible. It might need a new option 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] elharo commented on pull request #581: Don't list minor bugs in specific outdated versions on the home page
elharo commented on PR #581: URL: https://github.com/apache/maven-surefire/pull/581#issuecomment-1344273736 Some of the CI jobs might be broken: C:\Users\jenkins\AppData\Local\Temp\jenkins-Maven-maven-box-maven-surefire-PR-581-1\maven-failsafe-plugin\target\it does not exist. -- 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-scripting-plugin] rmannibucau commented on pull request #5: [MSCRIPTING-9] - basic java scripting support
rmannibucau commented on PR #5: URL: https://github.com/apache/maven-scripting-plugin/pull/5#issuecomment-1344282710 Anything pending on this one? (just trying to see if we should try to move it forward or not) -- 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-site] kwin commented on a diff in pull request #353: [INFRA] add autolink refs
kwin commented on code in PR #353: URL: https://github.com/apache/maven-site/pull/353#discussion_r1044456788 ## .asf.yaml: ## @@ -9,6 +9,28 @@ github: squash: true merge: false rebase: true + autolink_jira: +- MNG +- MNGSITE +- MSITE +- MINSTALL +- MPIR +- MANTTASKS +- MGPG +- SUREFIRE +- MENFORCER +- DOXIASITETOOLS +- MPLUGIN +- MWRAPPER +- MSHARED +- MSKINS +- MPOM +- ARCHETYPE +- ARCHETYPES +- INFRA +- MASSEMBLY +- FELIX Review Comment: Shouldn’t we restrict the list to Maven JIRA projects? Do you really expect a FELIX JIRA ID appear in the commit messages of the Maven Site? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-300) Introduce new API as replacement for FileTransform API
[ https://issues.apache.org/jira/browse/MRESOLVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-300: -- Fix Version/s: (was: 1.9.3) > Introduce new API as replacement for FileTransform API > -- > > Key: MRESOLVER-300 > URL: https://issues.apache.org/jira/browse/MRESOLVER-300 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Introduce new API as replacement for deprecated FileTransform API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas closed pull request #226: [MRESOLVER-300] Alternate transform API
cstamas closed pull request #226: [MRESOLVER-300] Alternate transform API URL: https://github.com/apache/maven-resolver/pull/226 -- 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-site] slawekjaranowski commented on a diff in pull request #354: [MNGSITE-503] add .well-known/security.txt
slawekjaranowski commented on code in PR #354: URL: https://github.com/apache/maven-site/pull/354#discussion_r1044477516 ## content/filtered-resources/.well-known/security.txt: ## @@ -0,0 +1,6 @@ +Contact: mailto:secur...@apache.org +Contact: mailto:secur...@maven.apache.org Review Comment: Is there such address, lists? -- 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 #226: [MRESOLVER-300] Alternate transform API
cstamas commented on PR #226: URL: https://github.com/apache/maven-resolver/pull/226#issuecomment-1344339917 This is on hold for now, more on related IIRA 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
[jira] [Commented] (MRESOLVER-300) Introduce new API as replacement for FileTransform API
[ https://issues.apache.org/jira/browse/MRESOLVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645304#comment-17645304 ] Tamas Cservenak commented on MRESOLVER-300: --- This is on hold, and will be probably dropped, as Tranform API is about to be dropped altogether, once "consumer POM" feature is redone in Maven. > Introduce new API as replacement for FileTransform API > -- > > Key: MRESOLVER-300 > URL: https://issues.apache.org/jira/browse/MRESOLVER-300 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Introduce new API as replacement for deprecated FileTransform API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-300) Introduce new API as replacement for FileTransform API
[ https://issues.apache.org/jira/browse/MRESOLVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645305#comment-17645305 ] ASF GitHub Bot commented on MRESOLVER-300: -- cstamas closed pull request #226: [MRESOLVER-300] Alternate transform API URL: https://github.com/apache/maven-resolver/pull/226 > Introduce new API as replacement for FileTransform API > -- > > Key: MRESOLVER-300 > URL: https://issues.apache.org/jira/browse/MRESOLVER-300 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Introduce new API as replacement for deprecated FileTransform API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-300) Introduce new API as replacement for FileTransform API
[ https://issues.apache.org/jira/browse/MRESOLVER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645307#comment-17645307 ] ASF GitHub Bot commented on MRESOLVER-300: -- cstamas commented on PR #226: URL: https://github.com/apache/maven-resolver/pull/226#issuecomment-1344339917 This is on hold for now, more on related IIRA issue. > Introduce new API as replacement for FileTransform API > -- > > Key: MRESOLVER-300 > URL: https://issues.apache.org/jira/browse/MRESOLVER-300 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Introduce new API as replacement for deprecated FileTransform API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNGSITE-503) add .well-known/security.txt
[ https://issues.apache.org/jira/browse/MNGSITE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645306#comment-17645306 ] ASF GitHub Bot commented on MNGSITE-503: slawekjaranowski commented on code in PR #354: URL: https://github.com/apache/maven-site/pull/354#discussion_r1044477516 ## content/filtered-resources/.well-known/security.txt: ## @@ -0,0 +1,6 @@ +Contact: mailto:secur...@apache.org +Contact: mailto:secur...@maven.apache.org Review Comment: Is there such address, lists? > add .well-known/security.txt > > > Key: MNGSITE-503 > URL: https://issues.apache.org/jira/browse/MNGSITE-503 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: security > > As per consensus on the mailing list (+1 from [~rmannibucau] and me), we > should add a file `.well-known/security.txt`. > I will prepare a PR. > References: > * [.well-known/security.txt at maven.apache.org > (mail-archive.com)|https://www.mail-archive.com/dev@maven.apache.org/msg128366.html] > * [.well-known/security.txt at maven.apache.org-Apache Mail > Archives|https://lists.apache.org/thread/tvfg1lx9nd72c9t4t4s3zlx6l0tpnmwy] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-invoker] slawekjaranowski closed pull request #57: Bump maven-shared-components from 35 to 38
slawekjaranowski closed pull request #57: Bump maven-shared-components from 35 to 38 URL: https://github.com/apache/maven-invoker/pull/57 -- 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-invoker] dependabot[bot] commented on pull request #57: Bump maven-shared-components from 35 to 38
dependabot[bot] commented on PR #57: URL: https://github.com/apache/maven-invoker/pull/57#issuecomment-1344347752 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2087) rerunFailingTestsCount incorrectly marks failed parametrized test as pass
[
https://issues.apache.org/jira/browse/SUREFIRE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645318#comment-17645318
]
Basil Crow commented on SUREFIRE-2087:
--
{quote}A reproducible example might also help.
{quote}
[~elharo] Have you read the second half of SUREFIRE-2087 (comment)?
> rerunFailingTestsCount incorrectly marks failed parametrized test as pass
> -
>
> Key: SUREFIRE-2087
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2087
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Ramanan Rajendran
>Priority: Critical
>
> rerunFailingTestsCount is not working as expected with junit5
> `@ParameterizedTest`
> If 1st iteration of the test passes and the 2nd one fails, it still marks the
> test as flaky passed.
> Eg: In the following run, iteration 1 with input A passed but iteration 2
> with input B failed. Iteration 2 was rerun 2 times and failed in all the
> attempts. Instead of failing TestA, it's marked as flaky giving an overall
> pass for the test suite. I believe it's using the Run 1 PASS as a gate to
> mark the whole test as a pass.
>
> [INFO] Run 1: PASS
> [ERROR] Run 2: TestA.iteration2:101 1 expectation failed.
> Expected status code <400> doesn't match actual status code <401>.
> [ERROR] Run 3: TestA.iteration2:101 1 expectation failed.
> Expected status code <400> doesn't match actual status code <401>.
> [ERROR] Run 4: TestA.iteration2:101 1 expectation failed.
> <400> doesn't match actual status code <401>.
>
> Tests run: 23, Failures: 0, Errors: 0, Skipped: 2, Flakes: 1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-invoker] psiroky commented on a diff in pull request #58: [MSHARED-1151] Upgrade parent to version 38
psiroky commented on code in PR #58: URL: https://github.com/apache/maven-invoker/pull/58#discussion_r1044518853 ## pom.xml: ## @@ -103,21 +103,6 @@ under the License. - Review Comment: Alright, I *think* I managed to replicate the fixes in this commit - https://github.com/apache/maven-parent/pull/94/commits/7faf877810e4f37b40ff0c4b55dd3936b81d48d6. Please take a look, since I am not 100% sure about removing plugin configuration elements coming from parent (e.g. the header file via `headerLocation`). The checkstyle now only reports ~50 WARNs, which was the case before as well I believe (checked via `mvn site -Preporting`. The configuration override is somewhat messy, so alternative would be to wait with this upgrade until the parent version 39 is released. Or if you can think of a better way to do the override, I am all ears. -- 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-invoker] psiroky commented on a diff in pull request #58: [MSHARED-1151] Upgrade parent to version 38
psiroky commented on code in PR #58:
URL: https://github.com/apache/maven-invoker/pull/58#discussion_r1044522392
##
src/main/java/org/apache/maven/shared/invoker/DefaultInvoker.java:
##
@@ -63,99 +58,78 @@
private InvocationOutputHandler errorHandler = DEFAULT_OUTPUT_HANDLER;
/** {@inheritDoc} */
-public InvocationResult execute( InvocationRequest request )
-throws MavenInvocationException
-{
+public InvocationResult execute(InvocationRequest request) throws
MavenInvocationException {
MavenCommandLineBuilder cliBuilder = new MavenCommandLineBuilder();
-if ( logger != null )
-{
-cliBuilder.setLogger( logger );
+if (logger != null) {
+cliBuilder.setLogger(logger);
}
-if ( localRepositoryDirectory != null )
-{
-cliBuilder.setLocalRepositoryDirectory( localRepositoryDirectory );
+if (localRepositoryDirectory != null) {
+cliBuilder.setLocalRepositoryDirectory(localRepositoryDirectory);
}
-if ( mavenHome != null )
-{
-cliBuilder.setMavenHome( mavenHome );
+if (mavenHome != null) {
+cliBuilder.setMavenHome(mavenHome);
}
-if ( mavenExecutable != null )
-{
-cliBuilder.setMavenExecutable( mavenExecutable );
+if (mavenExecutable != null) {
+cliBuilder.setMavenExecutable(mavenExecutable);
}
-if ( workingDirectory != null )
-{
-cliBuilder.setBaseDirectory( workingDirectory );
+if (workingDirectory != null) {
+cliBuilder.setBaseDirectory(workingDirectory);
}
Commandline cli;
-try
-{
-cli = cliBuilder.build( request );
-}
-catch ( CommandLineConfigurationException e )
-{
-throw new MavenInvocationException( "Error configuring command
line", e );
+try {
+cli = cliBuilder.build(request);
+} catch (CommandLineConfigurationException e) {
+throw new MavenInvocationException("Error configuring command
line", e);
}
DefaultInvocationResult result = new DefaultInvocationResult();
-try
-{
-int exitCode = executeCommandLine( cli, request,
request.getTimeoutInSeconds() );
+try {
+int exitCode = executeCommandLine(cli, request,
request.getTimeoutInSeconds());
-result.setExitCode( exitCode );
-}
-catch ( CommandLineException e )
-{
-result.setExecutionException( e );
+result.setExitCode(exitCode);
+} catch (CommandLineException e) {
+result.setExecutionException(e);
}
return result;
}
-private int executeCommandLine( Commandline cli, InvocationRequest
request, int timeoutInSeconds )
-throws CommandLineException
-{
+private int executeCommandLine(Commandline cli, InvocationRequest request,
int timeoutInSeconds)
+throws CommandLineException {
int result;
-InputStream inputStream = request.getInputStream( this.inputStream );
-InvocationOutputHandler outputHandler = request.getOutputHandler(
this.outputHandler );
-InvocationOutputHandler errorHandler = request.getErrorHandler(
this.errorHandler );
+InputStream inputStream = request.getInputStream(this.inputStream);
+InvocationOutputHandler outputHandler =
request.getOutputHandler(this.outputHandler);
+InvocationOutputHandler errorHandler =
request.getErrorHandler(this.errorHandler);
-if ( getLogger().isDebugEnabled() )
-{
-getLogger().debug( "Executing: " + cli );
+if (getLogger().isDebugEnabled()) {
+getLogger().debug("Executing: " + cli);
}
-if ( request.isBatchMode() )
-{
-if ( inputStream != null )
-{
-getLogger().info( "Executing in batch mode. The configured
input stream will be ignored." );
+if (request.isBatchMode()) {
+if (inputStream != null) {
+getLogger().info("Executing in batch mode. The configured
input stream will be ignored.");
}
-result = CommandLineUtils.executeCommandLine( cli, outputHandler,
errorHandler, timeoutInSeconds );
-}
-else
-{
-if ( inputStream == null )
-{
-getLogger().warn( "Maven will be executed in interactive mode"
-+ ", but no input stream has been configured for this
MavenInvoker instance." );
-
-result = CommandLineUtils.executeCommandLine( cli,
outputHandler, errorHandler, timeoutInSeconds );
-}
-else
-{
-result = CommandLineUtils.executeCommandLine( cli,
inputStream, outputHand
[jira] [Commented] (MRESOLVER-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645333#comment-17645333
]
Tamas Cservenak commented on MRESOLVER-305:
---
I don't get why MRESOLVER-166 did not implement this feature in connector
factory? As
org.eclipse.aether.impl.RepositoryConnectorProvider#newRepositoryConnector
should really throw
NoRepositoryConnectorException only, and everything remains same (and all is
covered), instead to have that block you [~kwin] refs to, that throws
NoRepositoryConnectorEx within try-catch just to have catch it immediately...
Obviously, the intent is to prevent REMOTE ACCESS, and connector is about
that...
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:364)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.e
[jira] [Comment Edited] (MRESOLVER-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645333#comment-17645333
]
Tamas Cservenak edited comment on MRESOLVER-305 at 12/9/22 3:04 PM:
I don't get why MRESOLVER-166 did not implement this feature in connector
factory? As
org.eclipse.aether.impl.RepositoryConnectorProvider#newRepositoryConnector
should really throw
NoRepositoryConnectorException only, and everything remains same (and all
execution paths are covered), instead to have that block you [~kwin] refs to,
that throws NoRepositoryConnectorEx within try-catch just to have catch it
immediately... Obviously, the intent is to prevent REMOTE ACCESS, and connector
is about that...
was (Author: cstamas):
I don't get why MRESOLVER-166 did not implement this feature in connector
factory? As
org.eclipse.aether.impl.RepositoryConnectorProvider#newRepositoryConnector
should really throw
NoRepositoryConnectorException only, and everything remains same (and all is
covered), instead to have that block you [~kwin] refs to, that throws
NoRepositoryConnectorEx within try-catch just to have catch it immediately...
Obviously, the intent is to prevent REMOTE ACCESS, and connector is about
that...
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.c
[jira] [Commented] (MRESOLVER-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645334#comment-17645334
]
Tamas Cservenak commented on MRESOLVER-305:
---
I do think this is only about REMOTE access, so local repository cached things
should NOT be affected...
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:364)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by:
> org.apache.maven.wagon.providers.http.httpcl
[GitHub] [maven-resolver] cstamas opened a new pull request, #228: [MRESOLVER-305] Handle blocked state at connector level
cstamas opened a new pull request, #228: URL: https://github.com/apache/maven-resolver/pull/228 As blocked is really about block remote access. Locally cached things should not be affected, but current solution did not cover all execution paths. --- https://issues.apache.org/jira/browse/MRESOLVER-305 -- 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-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645335#comment-17645335
]
ASF GitHub Bot commented on MRESOLVER-305:
--
cstamas opened a new pull request, #228:
URL: https://github.com/apache/maven-resolver/pull/228
As blocked is really about block remote access. Locally cached things should
not be affected, but current solution did not cover all execution paths.
---
https://issues.apache.org/jira/browse/MRESOLVER-305
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:364)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecu
[GitHub] [maven-parent] slawekjaranowski merged pull request #93: Bump spotless-maven-plugin from 2.27.1 to 2.28.0
slawekjaranowski merged PR #93: URL: https://github.com/apache/maven-parent/pull/93 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MPOM-379) Bump spotless-maven-plugin from 2.27.1 to 2.28.0
Slawomir Jaranowski created MPOM-379: Summary: Bump spotless-maven-plugin from 2.27.1 to 2.28.0 Key: MPOM-379 URL: https://issues.apache.org/jira/browse/MPOM-379 Project: Maven POMs Issue Type: Dependency upgrade Components: maven Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: MAVEN-39 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPOM-379) Bump spotless-maven-plugin from 2.27.1 to 2.28.0
[ https://issues.apache.org/jira/browse/MPOM-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-379. Resolution: Fixed > Bump spotless-maven-plugin from 2.27.1 to 2.28.0 > > > Key: MPOM-379 > URL: https://issues.apache.org/jira/browse/MPOM-379 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: maven >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: MAVEN-39 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet opened a new pull request, #906: [MNG-7505] Disable reportPlugins processing if m-site-p >= 3.7.0 is used
gnodet opened a new pull request, #906: URL: https://github.com/apache/maven/pull/906 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7505) Remove ReportingConverter
[
https://issues.apache.org/jira/browse/MNG-7505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645341#comment-17645341
]
ASF GitHub Bot commented on MNG-7505:
-
gnodet opened a new pull request, #906:
URL: https://github.com/apache/maven/pull/906
Following this checklist to help us incorporate your
contribution quickly and easily:
- [ ] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MNG) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line
and body.
- [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you
replace `MNG-XXX`
and `SUMMARY` with the appropriate JIRA issue. Best practice is to
use the JIRA issue
title in the pull request title and in the first line of the commit
message.
- [ ] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [ ] You have run the [Core IT][core-its] successfully.
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [ ] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> Remove ReportingConverter
> -
>
> Key: MNG-7505
> URL: https://issues.apache.org/jira/browse/MNG-7505
> Project: Maven
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> In m-site-p 3.7 configuration parameter {{reportPlugins}} was removed -
> MSITE-792
> So converting from reporting sections to {{reportPlugins}} option of m-site-p
> is not needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-306) Make GenericVersionScheme.parseVersionConstraint(...) throw exception when comma-separated version string not starting with "(" or "[" is passed
[
https://issues.apache.org/jira/browse/MRESOLVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645347#comment-17645347
]
Konrad Windszus commented on MRESOLVER-306:
---
It turned out that the ordering imposed by both
{{org.apache.maven.artifact.versioning.DefaultArtifactVersion}} and
{{org.eclipse.aether.util.version.GenericVersion}} is the same, i.e.
# Version("1,2,3") < Version("2")
# Version("1,2,3") < Version("4")
# Version("1,2,3") < Version("1.0.1")
# Version("1,2,3") > Version("1")
Both treat the the version ("1,2,3") as version containing out of 5 individual
parts:
# number 1
# string ","
# number 2
# string ","
# number 3
and compare each part individually. Therefore although "1,2,3" is probably not
what was intended is is a perfectly valid version constraint consisting out of
a single (unusual) version string.
> Make GenericVersionScheme.parseVersionConstraint(...) throw exception when
> comma-separated version string not starting with "(" or "[" is passed
>
>
> Key: MRESOLVER-306
> URL: https://issues.apache.org/jira/browse/MRESOLVER-306
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
> called an unexpected Object is returned which returns {{false}} for every
> version passed to {{VersionConstraint.containsVersion}} and also returns
> other values for {{VersionConstraint.getVersion().compareTo(some other
> version)}} than
> {{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
> other version)}}
> (https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
> Instead passing such invalid string should lead to an
> {{InvalidVersionSpecificationException}}.
> For a real-life example of such invalid version ranges refer to
> https://github.com/mybatis/parent/issues/401.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-306) Make GenericVersionScheme.parseVersionConstraint(...) throw exception when comma-separated version string not starting with "(" or "[" is passed
[
https://issues.apache.org/jira/browse/MRESOLVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed MRESOLVER-306.
-
Resolution: Invalid
> Make GenericVersionScheme.parseVersionConstraint(...) throw exception when
> comma-separated version string not starting with "(" or "[" is passed
>
>
> Key: MRESOLVER-306
> URL: https://issues.apache.org/jira/browse/MRESOLVER-306
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
> called an unexpected Object is returned which returns {{false}} for every
> version passed to {{VersionConstraint.containsVersion}} and also returns
> other values for {{VersionConstraint.getVersion().compareTo(some other
> version)}} than
> {{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
> other version)}}
> (https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
> Instead passing such invalid string should lead to an
> {{InvalidVersionSpecificationException}}.
> For a real-life example of such invalid version ranges refer to
> https://github.com/mybatis/parent/issues/401.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-306) Make GenericVersionScheme.parseVersionConstraint(...) throw exception when comma-separated version string not starting with "(" or "[" is passed
[
https://issues.apache.org/jira/browse/MRESOLVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645347#comment-17645347
]
Konrad Windszus edited comment on MRESOLVER-306 at 12/9/22 3:36 PM:
It turned out that the ordering imposed by both
{{org.apache.maven.artifact.versioning.DefaultArtifactVersion}} and
{{org.eclipse.aether.util.version.GenericVersion}} is the same, i.e.
# Version("1,2,3") < Version("2")
# Version("1,2,3") < Version("4")
# Version("1,2,3") < Version("1.0.1")
# Version("1,2,3") > Version("1")
Both treat the the version ("1,2,3") as version containing out of 5 individual
parts:
# number 1
# string ","
# number 2
# string ","
# number 3
and compare each part individually. Therefore although "1,2,3" is probably not
what was intended is is a perfectly valid version constraint consisting out of
a single (unusual) version string and therefore must not be rejected.
was (Author: kwin):
It turned out that the ordering imposed by both
{{org.apache.maven.artifact.versioning.DefaultArtifactVersion}} and
{{org.eclipse.aether.util.version.GenericVersion}} is the same, i.e.
# Version("1,2,3") < Version("2")
# Version("1,2,3") < Version("4")
# Version("1,2,3") < Version("1.0.1")
# Version("1,2,3") > Version("1")
Both treat the the version ("1,2,3") as version containing out of 5 individual
parts:
# number 1
# string ","
# number 2
# string ","
# number 3
and compare each part individually. Therefore although "1,2,3" is probably not
what was intended is is a perfectly valid version constraint consisting out of
a single (unusual) version string.
> Make GenericVersionScheme.parseVersionConstraint(...) throw exception when
> comma-separated version string not starting with "(" or "[" is passed
>
>
> Key: MRESOLVER-306
> URL: https://issues.apache.org/jira/browse/MRESOLVER-306
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently when {{GenericVersionScheme.parseVersionConstraint("1,2,3")}} is
> called an unexpected Object is returned which returns {{false}} for every
> version passed to {{VersionConstraint.containsVersion}} and also returns
> other values for {{VersionConstraint.getVersion().compareTo(some other
> version)}} than
> {{o.a.m.artifact.versioning.VersionRange.getRecommendedVersion().compareTo(some
> other version)}}
> (https://github.com/apache/maven/blob/55431cd267af1f4131f6fcb4c3b0d9c2c49641bf/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java#L65)
> Instead passing such invalid string should lead to an
> {{InvalidVersionSpecificationException}}.
> For a real-life example of such invalid version ranges refer to
> https://github.com/mybatis/parent/issues/401.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] kwin commented on a diff in pull request #228: [MRESOLVER-305] Handle blocked state at connector level
kwin commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044577421
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
we should probably have some tests, because to me it is not clear where this
exception is caught and logged. Does it prevent other remote repos from being
tried or not?
--
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-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645350#comment-17645350
]
ASF GitHub Bot commented on MRESOLVER-305:
--
kwin commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044577421
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
we should probably have some tests, because to me it is not clear where this
exception is caught and logged. Does it prevent other remote repos from being
tried or not?
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:364)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #228: [MRESOLVER-305] Handle blocked state at connector level
cstamas commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044588589
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
if you look from where this block was _removed_, it is in same try-catch
where this method is invoked (and throws this exception). This basically
prevents any "remote access" to blocked repositories.
--
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-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645358#comment-17645358
]
ASF GitHub Bot commented on MRESOLVER-305:
--
cstamas commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044588589
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
if you look from where this block was _removed_, it is in same try-catch
where this method is invoked (and throws this exception). This basically
prevents any "remote access" to blocked repositories.
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:364)
> at org.eclipse.aether.util.concurr
[GitHub] [maven-resolver] kwin commented on a diff in pull request #228: [MRESOLVER-305] Handle blocked state at connector level
kwin commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044590603
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
But if I have 1 blocked remote repo and one not-blocked one I expect the
latter to be used instead (if possible). Resolving should only fail if the
requested artifact/metadata could not be delivered from any non-blocked remote
repo.
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
But if I have one blocked remote repo and one not-blocked one I expect the
latter to be used instead (if possible). Resolving should only fail if the
requested artifact/metadata could not be delivered from any non-blocked remote
repo.
--
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-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645360#comment-17645360
]
ASF GitHub Bot commented on MRESOLVER-305:
--
kwin commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044590603
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
But if I have 1 blocked remote repo and one not-blocked one I expect the
latter to be used instead (if possible). Resolving should only fail if the
requested artifact/metadata could not be delivered from any non-blocked remote
repo.
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
But if I have one blocked remote repo and one not-blocked one I expect the
latter to be used instead (if possible). Resolving should only fail if the
requested artifact/metadata could not be delivered from any non-blocked remote
repo.
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpCli
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #228: [MRESOLVER-305] Handle blocked state at connector level
cstamas commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044588589
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
if you look from where this block was _removed_, it is in same try-catch
where this method is invoked (and throws this exception). This move basically
prevents any "remote access" to blocked repositories, not just for one case
like originally. But yes, I agree, we do need test, I thought to reuse existing
ones (are there any?)
--
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-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645361#comment-17645361
]
ASF GitHub Bot commented on MRESOLVER-305:
--
cstamas commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044588589
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
if you look from where this block was _removed_, it is in same try-catch
where this method is invoked (and throws this exception). This move basically
prevents any "remote access" to blocked repositories, not just for one case
like originally. But yes, I agree, we do need test, I thought to reuse existing
ones (are there any?)
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.conn
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #228: [MRESOLVER-305] Handle blocked state at connector level
cstamas commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044593073
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
Yes, as connector provider provides connector _for one given remote repo_
(is param on method), so it will happily provide connector instance for other
non-blocked remote repositories
--
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-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645364#comment-17645364
]
ASF GitHub Bot commented on MRESOLVER-305:
--
cstamas commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044593073
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
Yes, as connector provider provides connector _for one given remote repo_
(is param on method), so it will happily provide connector instance for other
non-blocked remote repositories
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:364)
> at org.eclipse.aether.util.concurrency.Runnabl
[GitHub] [maven-resolver] kwin commented on a diff in pull request #228: [MRESOLVER-305] Handle blocked state at connector level
kwin commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044594871
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
Ok, sorry, now I see the related catch block in
https://github.com/apache/maven-resolver/blob/752756f123cde40249f3d87490d3c2daa957127e/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L584
and indeed that should work just as expected.
--
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-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645365#comment-17645365
]
ASF GitHub Bot commented on MRESOLVER-305:
--
kwin commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044594871
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
Ok, sorry, now I see the related catch block in
https://github.com/apache/maven-resolver/blob/752756f123cde40249f3d87490d3c2daa957127e/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L584
and indeed that should work just as expected.
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
[GitHub] [maven-resolver] kwin commented on a diff in pull request #228: [MRESOLVER-305] Handle blocked state at connector level
kwin commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044594871
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
Ok, sorry, now I see the related catch block in
https://github.com/apache/maven-resolver/blob/752756f123cde40249f3d87490d3c2daa957127e/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L584
and
https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultMetadataResolver.java#L631
and indeed that should work just as expected.
--
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-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645367#comment-17645367
]
ASF GitHub Bot commented on MRESOLVER-305:
--
kwin commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044594871
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
Ok, sorry, now I see the related catch block in
https://github.com/apache/maven-resolver/blob/752756f123cde40249f3d87490d3c2daa957127e/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L584
and
https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultMetadataResolver.java#L631
and indeed that should work just as expected.
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclips
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #228: [MRESOLVER-305] Handle blocked state at connector level
cstamas commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044618718
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
Yes, in short: resolver will refuse to provide any connector for blocked
RemoteRepository instances. Everywhere.
--
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-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645378#comment-17645378
]
ASF GitHub Bot commented on MRESOLVER-305:
--
cstamas commented on code in PR #228:
URL: https://github.com/apache/maven-resolver/pull/228#discussion_r1044618718
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositoryConnectorProvider.java:
##
@@ -109,6 +109,20 @@ public RepositoryConnector newRepositoryConnector(
RepositorySystemSession sessi
throws NoRepositoryConnectorException
{
requireNonNull( repository, "remote repository cannot be null" );
+
+if ( repository.isBlocked() )
+{
+if ( repository.getMirroredRepositories().isEmpty() )
+{
+throw new NoRepositoryConnectorException( repository, "Blocked
repository: " + repository );
Review Comment:
Yes, in short: resolver will refuse to provide any connector for blocked
RemoteRepository instances. Everywhere.
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:364)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.ec
[jira] [Commented] (SUREFIRE-2087) rerunFailingTestsCount incorrectly marks failed parametrized test as pass
[ https://issues.apache.org/jira/browse/SUREFIRE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645388#comment-17645388 ] Elliotte Rusty Harold commented on SUREFIRE-2087: - I have read it and I still think this is all working as intended. perhaps I'm missing something, but so far I don't see it. > rerunFailingTestsCount incorrectly marks failed parametrized test as pass > - > > Key: SUREFIRE-2087 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2087 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M4 >Reporter: Ramanan Rajendran >Priority: Critical > > rerunFailingTestsCount is not working as expected with junit5 > `@ParameterizedTest` > If 1st iteration of the test passes and the 2nd one fails, it still marks the > test as flaky passed. > Eg: In the following run, iteration 1 with input A passed but iteration 2 > with input B failed. Iteration 2 was rerun 2 times and failed in all the > attempts. Instead of failing TestA, it's marked as flaky giving an overall > pass for the test suite. I believe it's using the Run 1 PASS as a gate to > mark the whole test as a pass. > > [INFO] Run 1: PASS > [ERROR] Run 2: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 3: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 4: TestA.iteration2:101 1 expectation failed. > <400> doesn't match actual status code <401>. > > Tests run: 23, Failures: 0, Errors: 0, Skipped: 2, Flakes: 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2087) rerunFailingTestsCount incorrectly marks failed parametrized test as pass
[ https://issues.apache.org/jira/browse/SUREFIRE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645390#comment-17645390 ] Elliotte Rusty Harold commented on SUREFIRE-2087: - OK, maybe I see it. The issue is specifically with parameterized tests. Note that "Instead of failing TestA, it's marked as flaky giving an overall pass for the test suite." is still WAI. That is, Test A should be marked as a pass, not failed. > rerunFailingTestsCount incorrectly marks failed parametrized test as pass > - > > Key: SUREFIRE-2087 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2087 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M4 >Reporter: Ramanan Rajendran >Priority: Critical > > rerunFailingTestsCount is not working as expected with junit5 > `@ParameterizedTest` > If 1st iteration of the test passes and the 2nd one fails, it still marks the > test as flaky passed. > Eg: In the following run, iteration 1 with input A passed but iteration 2 > with input B failed. Iteration 2 was rerun 2 times and failed in all the > attempts. Instead of failing TestA, it's marked as flaky giving an overall > pass for the test suite. I believe it's using the Run 1 PASS as a gate to > mark the whole test as a pass. > > [INFO] Run 1: PASS > [ERROR] Run 2: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 3: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 4: TestA.iteration2:101 1 expectation failed. > <400> doesn't match actual status code <401>. > > Tests run: 23, Failures: 0, Errors: 0, Skipped: 2, Flakes: 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2087) rerunFailingTestsCount incorrectly marks failed parametrized test as pass
[
https://issues.apache.org/jira/browse/SUREFIRE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645399#comment-17645399
]
Basil Crow commented on SUREFIRE-2087:
--
The difference in behavior between the {{expected}} and {{actual}} modules of
[https://github.com/basil/SUREFIRE-2087-mre] says it all. We have been impacted
by this in the Jenkins project: after switching from
{{org.apache.maven.surefire.junit4.JUnit4Provider}} to
{{org.apache.maven.surefire.junitplatform.JUnitPlatformProvider}} for our
(predominantly JUnit 4 based) test suite, someone made a change that broke a
test. But Maven erroneously classified it as a flaky test and marked the
overall run as successful, which caused the bug to go unnoticed. Later on, that
bug resulted in a security vulnerability which required an emergency release to
correct. So this is a very real problem that has affected us. We worked around
the issue first by removing parameterization from the test in question, then by
disabling {{rerunFailingTestsCount}} entirely, the latter of which forced us to
spend months making our test suite less flaky.
> rerunFailingTestsCount incorrectly marks failed parametrized test as pass
> -
>
> Key: SUREFIRE-2087
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2087
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Ramanan Rajendran
>Priority: Critical
>
> rerunFailingTestsCount is not working as expected with junit5
> `@ParameterizedTest`
> If 1st iteration of the test passes and the 2nd one fails, it still marks the
> test as flaky passed.
> Eg: In the following run, iteration 1 with input A passed but iteration 2
> with input B failed. Iteration 2 was rerun 2 times and failed in all the
> attempts. Instead of failing TestA, it's marked as flaky giving an overall
> pass for the test suite. I believe it's using the Run 1 PASS as a gate to
> mark the whole test as a pass.
>
> [INFO] Run 1: PASS
> [ERROR] Run 2: TestA.iteration2:101 1 expectation failed.
> Expected status code <400> doesn't match actual status code <401>.
> [ERROR] Run 3: TestA.iteration2:101 1 expectation failed.
> Expected status code <400> doesn't match actual status code <401>.
> [ERROR] Run 4: TestA.iteration2:101 1 expectation failed.
> <400> doesn't match actual status code <401>.
>
> Tests run: 23, Failures: 0, Errors: 0, Skipped: 2, Flakes: 1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] elharo commented on pull request #581: Don't list minor bugs in specific outdated versions on the home page
elharo commented on PR #581: URL: https://github.com/apache/maven-surefire/pull/581#issuecomment-1344565387 Jenkins passes. Many of the cloudbees CIs look broken. -- 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] (MCOMPILER-501) compileSourceRoots parameter should be writable
[
https://issues.apache.org/jira/browse/MCOMPILER-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MCOMPILER-501:
--
Fix Version/s: 3.11.0
> compileSourceRoots parameter should be writable
>
>
> Key: MCOMPILER-501
> URL: https://issues.apache.org/jira/browse/MCOMPILER-501
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.11.0
>
>
> {{compileSourceRoots}} is used many times in configuration, eg to build
> project for multi release in single project pattern:
> [https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml]
> so should be writable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MCOMPILER-501) compileSourceRoots parameter should be writable
[
https://issues.apache.org/jira/browse/MCOMPILER-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MCOMPILER-501:
-
Assignee: Guillaume Nodet
> compileSourceRoots parameter should be writable
>
>
> Key: MCOMPILER-501
> URL: https://issues.apache.org/jira/browse/MCOMPILER-501
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Guillaume Nodet
>Priority: Major
>
> {{compileSourceRoots}} is used many times in configuration, eg to build
> project for multi release in single project pattern:
> [https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml]
> so should be writable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-compiler-plugin] gnodet merged pull request #159: [MCOMPILER-501] compileSourceRoots parameter should be writable
gnodet merged PR #159: URL: https://github.com/apache/maven-compiler-plugin/pull/159 -- 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] [Closed] (MCOMPILER-501) compileSourceRoots parameter should be writable
[
https://issues.apache.org/jira/browse/MCOMPILER-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MCOMPILER-501.
-
Resolution: Fixed
> compileSourceRoots parameter should be writable
>
>
> Key: MCOMPILER-501
> URL: https://issues.apache.org/jira/browse/MCOMPILER-501
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.11.0
>
>
> {{compileSourceRoots}} is used many times in configuration, eg to build
> project for multi release in single project pattern:
> [https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml]
> so should be writable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-site] bmarwell commented on a diff in pull request #354: [MNGSITE-503] add .well-known/security.txt
bmarwell commented on code in PR #354: URL: https://github.com/apache/maven-site/pull/354#discussion_r1044674863 ## content/filtered-resources/.well-known/security.txt: ## @@ -0,0 +1,6 @@ +Contact: mailto:secur...@apache.org +Contact: mailto:secur...@maven.apache.org Review Comment: Yes, you can repeat this according to RFCs. The first address is the general a.o address which can be found on the linked security policy website. The second one SHOULD exist. It's an address (mailing list) which is created for each PMC. -- 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] (MNGSITE-503) add .well-known/security.txt
[ https://issues.apache.org/jira/browse/MNGSITE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645415#comment-17645415 ] ASF GitHub Bot commented on MNGSITE-503: bmarwell commented on code in PR #354: URL: https://github.com/apache/maven-site/pull/354#discussion_r1044674863 ## content/filtered-resources/.well-known/security.txt: ## @@ -0,0 +1,6 @@ +Contact: mailto:secur...@apache.org +Contact: mailto:secur...@maven.apache.org Review Comment: Yes, you can repeat this according to RFCs. The first address is the general a.o address which can be found on the linked security policy website. The second one SHOULD exist. It's an address (mailing list) which is created for each PMC. > add .well-known/security.txt > > > Key: MNGSITE-503 > URL: https://issues.apache.org/jira/browse/MNGSITE-503 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: security > > As per consensus on the mailing list (+1 from [~rmannibucau] and me), we > should add a file `.well-known/security.txt`. > I will prepare a PR. > References: > * [.well-known/security.txt at maven.apache.org > (mail-archive.com)|https://www.mail-archive.com/dev@maven.apache.org/msg128366.html] > * [.well-known/security.txt at maven.apache.org-Apache Mail > Archives|https://lists.apache.org/thread/tvfg1lx9nd72c9t4t4s3zlx6l0tpnmwy] -- This message was sent by Atlassian Jira (v8.20.10#820010)
