[jira] [Commented] (MRESOLVER-370) Lock factory should dump lock states on failure
[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731900#comment-17731900
]
ASF GitHub Bot commented on MRESOLVER-370:
--
cstamas commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1227565749
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##
@@ -43,7 +43,7 @@ public abstract class NamedLockSupport implements NamedLock {
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
-this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
+this.state = factory.isDiagnosticEnabled() ? new ConcurrentHashMap<>()
: null;
Review Comment:
Due this above (and absence of session, plus the life-span of factory and
lock instance across many sessions), I'd change "diag" switch just to be a Java
system property... @gnodet WDYT?
> Lock factory should dump lock states on failure
> ---
>
> Key: MRESOLVER-370
> URL: https://issues.apache.org/jira/browse/MRESOLVER-370
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.11
>
>
> When adapter "gives up" (as it could not acquire required lock), the error
> currently states "how many retries were against which lock". This gives
> information only about failed lock, but lacks the "whole picture".
> Proposed change: in case of lock failure, factory should dump out all lock
> states (may be huge on big builds), as that would allow simpler
> identification of possible problems. All this could be sorted out at "high
> level" (so no need to fiddle with file locks, hazelcast or redisson), but for
> memory constraints it should NOT be enabled by default, this "diagnostic"
> should be turned off by default, but possible by users to turn on if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-369) Expose configuration for update check manager where to apply policy
[
https://issues.apache.org/jira/browse/MRESOLVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-369:
--
Fix Version/s: (was: 1.9.11)
> Expose configuration for update check manager where to apply policy
> ---
>
> Key: MRESOLVER-369
> URL: https://issues.apache.org/jira/browse/MRESOLVER-369
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
> and metadata. This causes problems when we want to "discover new versions"
> (or similar use case, that relies on fresh metadata), but metadata is never
> updated due remote repository update policy of "never", so only -U make it
> work as expected. -U OTOH is like shooting with cannon onto bird, as it
> updates many many more as well, not only the one metadata we are interested
> in.
> Moreover, since Maven3 artifacts are immutable.
> So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
> accepts values "all" (like today) and "metadata" (does not applies policy to
> artifacts, if artifact present, no update needed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7167) Support MavenProject Installer/Deployer
[ https://issues.apache.org/jira/browse/MNG-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731898#comment-17731898 ] Guillaume Nodet commented on MNG-7167: -- I think this will be addressed when the v4 api starts being used. > Support MavenProject Installer/Deployer > --- > > Key: MNG-7167 > URL: https://issues.apache.org/jira/browse/MNG-7167 > Project: Maven > Issue Type: New Feature >Reporter: Robert Scholte >Priority: Major > Fix For: 4.0.x-candidate > > > Maven Compat used to have the ArtifactInstaller and ArtifactDeployer, but > these are superseded by the Aether/Maven Artifact Resolvers. > However, [Maven Artifact > Transer|http://maven.apache.org/shared/maven-artifact-transfer/] has a > ProjectInstaller and ProjectDeployer that don't belong there. > Maven Artifact Transfer should be a bridge to the different implementations > of Aether, handling artifacts, whereas this is too Maven specific. > The logic behind ProjectInstaller/ProjectDeployer is required by several > plugin, being at least maven-install-plugin, maven-deploy-plugin and > maven-invoker-plugin. > It would make sense if Maven itself provided these as APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7167) Support MavenProject Installer/Deployer
[ https://issues.apache.org/jira/browse/MNG-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7167. Resolution: Won't Fix > Support MavenProject Installer/Deployer > --- > > Key: MNG-7167 > URL: https://issues.apache.org/jira/browse/MNG-7167 > Project: Maven > Issue Type: New Feature >Reporter: Robert Scholte >Priority: Major > Fix For: 4.0.x-candidate > > > Maven Compat used to have the ArtifactInstaller and ArtifactDeployer, but > these are superseded by the Aether/Maven Artifact Resolvers. > However, [Maven Artifact > Transer|http://maven.apache.org/shared/maven-artifact-transfer/] has a > ProjectInstaller and ProjectDeployer that don't belong there. > Maven Artifact Transfer should be a bridge to the different implementations > of Aether, handling artifacts, whereas this is too Maven specific. > The logic behind ProjectInstaller/ProjectDeployer is required by several > plugin, being at least maven-install-plugin, maven-deploy-plugin and > maven-invoker-plugin. > It would make sense if Maven itself provided these as APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731887#comment-17731887
]
Benjamin Marwell commented on MBUILDCACHE-61:
-
Yes. Maybe I should have slapped 'needs documentation' on it.
> XXMM hash algorithm does not work on Java 17
>
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Priority: Major
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
> constituent[21]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
> constituent[22]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
> constituent[23]:
>
[jira] [Updated] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MBUILDCACHE-61:
Labels: documentation (was: )
> XXMM hash algorithm does not work on Java 17
>
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: documentation
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
> constituent[21]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
> constituent[22]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
> constituent[23]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-core-3.9.2.jar
>
[jira] [Commented] (MSHARED-1270) Deprecate maven-artifact-transfer
[ https://issues.apache.org/jira/browse/MSHARED-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731788#comment-17731788 ] ASF GitHub Bot commented on MSHARED-1270: - gnodet opened a new pull request, #93: URL: https://github.com/apache/maven-artifact-transfer/pull/93 (no comment) > Deprecate maven-artifact-transfer > - > > Key: MSHARED-1270 > URL: https://issues.apache.org/jira/browse/MSHARED-1270 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-artifact-transfer >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-artifact-transfer] gnodet opened a new pull request, #93: [MSHARED-1270] Deprecate maven-artifact-transfer
gnodet opened a new pull request, #93: URL: https://github.com/apache/maven-artifact-transfer/pull/93 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7806) Plugins verification - remove used in module(s) report
[
https://issues.apache.org/jira/browse/MNG-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MNG-7806:
-
Description:
When we report issues for plugins we show sections {{Used in module(s)}} for
projects with many modules it can make more mess than usability.
So we can remove it - it is more important where plugin is defined
was:
When we report issues for plugins we show sections {{Used in module(s)}} for
projects with many modules it can make more mess than usability.
So we can remove it -
> Plugins verification - remove used in module(s) report
> --
>
> Key: MNG-7806
> URL: https://issues.apache.org/jira/browse/MNG-7806
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> When we report issues for plugins we show sections {{Used in module(s)}} for
> projects with many modules it can make more mess than usability.
> So we can remove it - it is more important where plugin is defined
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7806) Plugins verification - remove used in module(s) report
[
https://issues.apache.org/jira/browse/MNG-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MNG-7806:
-
Description:
When we report issues for plugins we show sections {{Used in module(s)}} for
projects with many modules it can make more mess than usability.
So we can remove it -
was:
When we report issues for plugins we show sections {{Used in module(s)}} for
projects with many modules it can make more mess than usability.
We can show only a few first locations.
> Plugins verification - remove used in module(s) report
> --
>
> Key: MNG-7806
> URL: https://issues.apache.org/jira/browse/MNG-7806
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> When we report issues for plugins we show sections {{Used in module(s)}} for
> projects with many modules it can make more mess than usability.
> So we can remove it -
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7806) Plugins verification - remove used in module(s) report
[
https://issues.apache.org/jira/browse/MNG-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MNG-7806:
-
Summary: Plugins verification - remove used in module(s) report (was:
Plugins verification - limit the number of reported items by used in module(s))
> Plugins verification - remove used in module(s) report
> --
>
> Key: MNG-7806
> URL: https://issues.apache.org/jira/browse/MNG-7806
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> When we report issues for plugins we show sections {{Used in module(s)}} for
> projects with many modules it can make more mess than usability.
> We can show only a few first locations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-archiver] dependabot[bot] commented on pull request #36: Bump slf4j-simple from 1.7.36 to 2.0.7
dependabot[bot] commented on PR #36: URL: https://github.com/apache/maven-archiver/pull/36#issuecomment-1588127237 OK, I won't notify you about version 2.x.x again, unless you re-open this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-archiver] dependabot[bot] closed pull request #36: Bump slf4j-simple from 1.7.36 to 2.0.7
dependabot[bot] closed pull request #36: Bump slf4j-simple from 1.7.36 to 2.0.7 URL: https://github.com/apache/maven-archiver/pull/36 -- 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] (MSOURCES-137) Artifacts generated by maven-source-plugin are not reproducible because they depend on the umask
Andreas Veithen created MSOURCES-137:
Summary: Artifacts generated by maven-source-plugin are not
reproducible because they depend on the umask
Key: MSOURCES-137
URL: https://issues.apache.org/jira/browse/MSOURCES-137
Project: Maven Source Plugin
Issue Type: Bug
Affects Versions: 3.3.0
Reporter: Andreas Veithen
It appears that inside the archive created by maven-source-plugin, the
permissions of
{{META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties}}
depend on the current umask.
Steps to reproduce:
{code}
$ umask 022
$ mvn clean install
$ umask 002
$ mvn clean verify artifact:compare
{code}
This can be used on any project attaching a source jar (e.g.
https://github.com/apache/ws-axiom/).
Example diffoscope output:
{code}
--- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
+++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
│┄ Archive contents identical but files differ, possibly due to different
compression levels. Falling back to binary comparison.
├── zipinfo {}
│ @@ -14,9 +14,9 @@
│ -rw-r--r-- 2.0 unx 170 b- defN 22-Mar-13 11:17 META-INF/NOTICE
│ -rw-r--r-- 2.0 unx 1365 b- defN 22-Mar-13 11:17
org/apache/axiom/weaver/annotation/FactoryMethod.java
│ -rw-r--r-- 2.0 unx 1101 b- defN 22-Mar-13 11:17
org/apache/axiom/weaver/annotation/Inject.java
│ -rw-r--r-- 2.0 unx 1095 b- defN 22-Mar-13 11:17
org/apache/axiom/weaver/annotation/Mixin.java
│ -rw-r--r-- 2.0 unx 1100 b- defN 22-Mar-13 11:17
org/apache/axiom/weaver/annotation/Singleton.java
│ -rw-r--r-- 2.0 unx 1136 b- defN 22-Mar-13 11:17
org/apache/axiom/weaver/annotation/WeavablePackage.java
│ -rw-r--r-- 2.0 unx 1411 b- defN 22-Mar-13 11:17
META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.xml
│ --rw-r--r-- 2.0 unx 95 b- defN 22-Mar-13 11:17
META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties
│ +-rw-rw-r-- 2.0 unx 95 b- defN 22-Mar-13 11:17
META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties
│ 20 files, 19157 bytes uncompressed, 8089 bytes compressed: 57.8%
│ --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
├── +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
│ @@ -676,15 +676,15 @@
│ 2a30: a481 b020 4d45 5441 . ..META
│ 2a40: 2d49 4e46 2f6d 6176 656e 2f6f 7267 2e61 -INF/maven/org.a
│ 2a50: 7061 6368 652e 7773 2e63 6f6d 6d6f 6e73 pache.ws.commons
│ 2a60: 2e61 7869 6f6d 2f61 7869 6f6d 2d77 6561 .axiom/axiom-wea
│ 2a70: 7665 722d 616e 6e6f 7461 7469 6f6e 732f ver-annotations/
│ 2a80: 706f 6d2e 786d 6c50 4b01 0214 0314 pom.xmlPK...
│ 2a90: 0808 0022 5a6d 54b9 68bb 2558 005f ..."ZmT.h.%X..._
│ -2aa0: 0052 00a4 ...R
│ +2aa0: 0052 00b4 ...R
│ 2ab0: 81e8 2300 004d 4554 412d 494e 462f 6d61 ..#..META-INF/ma
│ 2ac0: 7665 6e2f 6f72 672e 6170 6163 6865 2e77 ven/org.apache.w
│ 2ad0: 732e 636f 6d6d 6f6e 732e 6178 696f 6d2f s.commons.axiom/
│ 2ae0: 6178 696f 6d2d 7765 6176 6572 2d61 6e6e axiom-weaver-ann
│ 2af0: 6f74 6174 696f 6e73 2f70 6f6d 2e70 726f otations/pom.pro
│ 2b00: 7065 7274 6965 7350 4b05 0600 0014 pertiesPK...
│ 2b10: 0014 0057 0600 00b0 2400 00 ...W$
{code}
Note that although maven-jar-plugin adds the same {{pom.properties}} file to
the archive, it isn't affected by this problem.
I discovered this while trying to check the reproducibility of Apache Axiom
builds in a Github Codespace, where file permissions are set in a peculiar way;
see https://github.com/orgs/community/discussions/26026.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1269) Deprecate maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731775#comment-17731775 ] ASF GitHub Bot commented on MSHARED-1269: - gnodet opened a new pull request, #154: URL: https://github.com/apache/maven-shared-utils/pull/154 (no comment) > Deprecate maven-shared-utils > > > Key: MSHARED-1269 > URL: https://issues.apache.org/jira/browse/MSHARED-1269 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1270) Deprecate maven-artifact-transfer
Guillaume Nodet created MSHARED-1270: Summary: Deprecate maven-artifact-transfer Key: MSHARED-1270 URL: https://issues.apache.org/jira/browse/MSHARED-1270 Project: Maven Shared Components Issue Type: New Feature Components: maven-artifact-transfer Reporter: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7202) settings.offline property not working
[
https://issues.apache.org/jira/browse/MNG-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-7202.
Assignee: Guillaume Nodet
Resolution: Won't Fix
> settings.offline property not working
> -
>
> Key: MNG-7202
> URL: https://issues.apache.org/jira/browse/MNG-7202
> Project: Maven
> Issue Type: Bug
> Components: POM, Settings
>Affects Versions: 3.8.1
> Environment: Debian 10.10, OpenJDK 11.0.12, Maven 3.8.1
>Reporter: AO Industries, Inc.
>Assignee: Guillaume Nodet
>Priority: Minor
> Attachments: pom.xml
>
>
> The documentation cites ${settings.offline} as a means to determine if the
> current build is offline: [https://maven.apache.org/settings.html#properties]
> For the life of me, I cannot get anything from a ${settings.offline} property
> in any way. ${settings.localRepository} works, though.
> ---
> I hope to use ${settings.offline} within a maven-antrun-plugin target to
> avoid some WSDL GET requests when operating offline.
> ---
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7202) settings.offline property not working
[
https://issues.apache.org/jira/browse/MNG-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731770#comment-17731770
]
Guillaume Nodet edited comment on MNG-7202 at 6/12/23 8:36 PM:
---
This works perfectly well in my case.
{code}
➜ maven ✗ mvn help:evaluate -Dexpression=settings.offline -N -q -DforceStdout
-o
true%
{code}
The [evaluator
code|https://github.com/apache/maven/blob/22d2b47c04c8b14faf24954a1a903c210d40f58d/maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java#L260]
is using reflection to evaluate the property.
was (Author: gnt):
This works perfectly well in my case.
{code}
➜ maven ✗ mvn help:evaluate -Dexpression=settings.offline -N -q -DforceStdout
-o
true%
{code}
> settings.offline property not working
> -
>
> Key: MNG-7202
> URL: https://issues.apache.org/jira/browse/MNG-7202
> Project: Maven
> Issue Type: Bug
> Components: POM, Settings
>Affects Versions: 3.8.1
> Environment: Debian 10.10, OpenJDK 11.0.12, Maven 3.8.1
>Reporter: AO Industries, Inc.
>Priority: Minor
> Attachments: pom.xml
>
>
> The documentation cites ${settings.offline} as a means to determine if the
> current build is offline: [https://maven.apache.org/settings.html#properties]
> For the life of me, I cannot get anything from a ${settings.offline} property
> in any way. ${settings.localRepository} works, though.
> ---
> I hope to use ${settings.offline} within a maven-antrun-plugin target to
> avoid some WSDL GET requests when operating offline.
> ---
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7202) settings.offline property not working
[
https://issues.apache.org/jira/browse/MNG-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731770#comment-17731770
]
Guillaume Nodet commented on MNG-7202:
--
This works perfectly well in my case.
{code}
➜ maven ✗ mvn help:evaluate -Dexpression=settings.offline -N -q -DforceStdout
-o
true%
{code}
> settings.offline property not working
> -
>
> Key: MNG-7202
> URL: https://issues.apache.org/jira/browse/MNG-7202
> Project: Maven
> Issue Type: Bug
> Components: POM, Settings
>Affects Versions: 3.8.1
> Environment: Debian 10.10, OpenJDK 11.0.12, Maven 3.8.1
>Reporter: AO Industries, Inc.
>Priority: Minor
> Attachments: pom.xml
>
>
> The documentation cites ${settings.offline} as a means to determine if the
> current build is offline: [https://maven.apache.org/settings.html#properties]
> For the life of me, I cannot get anything from a ${settings.offline} property
> in any way. ${settings.localRepository} works, though.
> ---
> I hope to use ${settings.offline} within a maven-antrun-plugin target to
> avoid some WSDL GET requests when operating offline.
> ---
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7232) Make variables final whenever possible
[ https://issues.apache.org/jira/browse/MNG-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7232. Resolution: Won't Fix > Make variables final whenever possible > -- > > Key: MNG-7232 > URL: https://issues.apache.org/jira/browse/MNG-7232 > Project: Maven > Issue Type: Sub-task > Components: Integration Tests >Reporter: Arturo Bernal >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7255) Default value for groupId in dependencies
[ https://issues.apache.org/jira/browse/MNG-7255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7255: - Fix Version/s: 4.x / Backlog > Default value for groupId in dependencies > - > > Key: MNG-7255 > URL: https://issues.apache.org/jira/browse/MNG-7255 > Project: Maven > Issue Type: New Feature > Components: Core >Reporter: Richard Eckart de Castilho >Priority: Major > Fix For: 4.x / Backlog > > > Maven 4 plans to make the setting the version of a dependency optional using > the version of the project version of the current module as a default value. > How about applying the same mechanism to the groupId of dependencies - if > omitted, then the projectId of the current module (or if omitted in the > module, then of the parent) could be used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1269) Deprecate maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1269: - Component/s: maven-shared-utils > Deprecate maven-shared-utils > > > Key: MSHARED-1269 > URL: https://issues.apache.org/jira/browse/MSHARED-1269 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-archiver] dependabot[bot] opened a new pull request, #36: Bump slf4j-simple from 1.7.36 to 2.0.7
dependabot[bot] opened a new pull request, #36: URL: https://github.com/apache/maven-archiver/pull/36 Bumps [slf4j-simple](https://github.com/qos-ch/slf4j) from 1.7.36 to 2.0.7. Commits https://github.com/qos-ch/slf4j/commit/d6a21ae68f8a996bc24526f82ec46907e6688bc0;>d6a21ae update javadoc plugin to version 3.0.5 https://github.com/qos-ch/slf4j/commit/13950e51a62893eae6a5f6d9f842fe5554b7d4f4;>13950e5 prepare release 2.0.7 https://github.com/qos-ch/slf4j/commit/122e0c18dd59c1c7ef425e89e6097c07ee2358b9;>122e0c1 add LICENSE.txt files to all modules, rename LICENSE as LICENSE.txt when appr... https://github.com/qos-ch/slf4j/commit/2a8ca99cafe8a20c2dc57ed7297ec68c574b0b94;>2a8ca99 add license file to jar https://github.com/qos-ch/slf4j/commit/b363bb31ed08d3ad9761ccdca5e51bb2327c3287;>b363bb3 SLF4J-579: Export client packages of slf4j-api in version 1 https://github.com/qos-ch/slf4j/commit/2235d3c69829caf19e38ea980a86042cc3ffd1f3;>2235d3c Fully automate OSGi metadata creation and fix brocken OSGi-metadata in slf4j-... https://github.com/qos-ch/slf4j/commit/a5540ad51066b4b15132fdf27ead630519541d35;>a5540ad setup-java v3 https://github.com/qos-ch/slf4j/commit/1ed084cbc061f0bcbc9250867771550684be25fa;>1ed084c add missing distribution instruction to github action https://github.com/qos-ch/slf4j/commit/b2cb0174225d1163730a209a6a433068fa281903;>b2cb017 update github action versions https://github.com/qos-ch/slf4j/commit/fa6721a53eb4b2d13491400908f9ca76c7997300;>fa6721a add JDK 19 to CI build Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.7;>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 Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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-7302) Replace construction of FileInputStream and FileOutputStream objects with Files NIO APIs.
[
https://issues.apache.org/jira/browse/MNG-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731762#comment-17731762
]
ASF GitHub Bot commented on MNG-7302:
-
gnodet commented on code in PR #587:
URL: https://github.com/apache/maven/pull/587#discussion_r1227179496
##
maven-compat/src/test/java/org/apache/maven/artifact/AbstractArtifactComponentTestCase.java:
##
@@ -271,7 +271,7 @@ protected void createArtifact( Artifact artifact,
ArtifactRepository repository
{
artifactFile.getParentFile().mkdirs();
}
-try ( Writer writer = new OutputStreamWriter( new FileOutputStream(
artifactFile ), StandardCharsets.ISO_8859_1) )
+try ( Writer writer = new OutputStreamWriter( Files.newOutputStream(
artifactFile.toPath() ), StandardCharsets.ISO_8859_1) )
Review Comment:
This should use `Files.newBufferedWriter` instead imho
> Replace construction of FileInputStream and FileOutputStream objects with
> Files NIO APIs.
> -
>
> Key: MNG-7302
> URL: https://issues.apache.org/jira/browse/MNG-7302
> Project: Maven
> Issue Type: Sub-task
>Reporter: Arturo Bernal
>Priority: Minor
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #587: [MNG-7302] - Replace construction of FileInputStream and FileOutputStream objects with Files NIO APIs.
gnodet commented on code in PR #587:
URL: https://github.com/apache/maven/pull/587#discussion_r1227179496
##
maven-compat/src/test/java/org/apache/maven/artifact/AbstractArtifactComponentTestCase.java:
##
@@ -271,7 +271,7 @@ protected void createArtifact( Artifact artifact,
ArtifactRepository repository
{
artifactFile.getParentFile().mkdirs();
}
-try ( Writer writer = new OutputStreamWriter( new FileOutputStream(
artifactFile ), StandardCharsets.ISO_8859_1) )
+try ( Writer writer = new OutputStreamWriter( Files.newOutputStream(
artifactFile.toPath() ), StandardCharsets.ISO_8859_1) )
Review Comment:
This should use `Files.newBufferedWriter` instead imho
--
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] (MNG-7363) Demote Wagon as "only" transport supported
[ https://issues.apache.org/jira/browse/MNG-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7363. Assignee: Tamas Cservenak Resolution: Fixed > Demote Wagon as "only" transport supported > -- > > Key: MNG-7363 > URL: https://issues.apache.org/jira/browse/MNG-7363 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Currently Maven uses some Resolver configurations as "baked in" that are > wagon-only. Also, there are ITs that are testing Wagon configurations using > Plexus XML, and are written originally for Maven 2. In short, these ITs > should be disabled, as they assume that Maven uses Wagon (note: this was well > BEFORE maven-resolver existed) and Wagon only, and configuration happens via > Plexus XML not via officially supported Resolver properties. > Issues (and ITs): > * MNG-3652 - uses non-standard way to set up UA (see Resolver config) > * MNG-3485 - is really about Wagon only > * MNG-3599 - is about Wagon WebDAV extension > * MNG-3600 - is about Wagon settings only (fileMode, dirMode, group) > * MNG-4360 - is about Jackrabbit Wagon provider > * MNG-4877 - uses SSH Wagon doing deploy via SSH > * MNG-5175 - is about Wagon pooling > Essentiall ITs are all for Maven2, also Maven3 but IMHO Maven4 should drop > all these non-standard wagon-only tests (not have them run on Maven4). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet opened a new pull request, #1156: Simplify code
gnodet opened a new pull request, #1156: URL: https://github.com/apache/maven/pull/1156 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. - [ ] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both 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-7751) Ability to inject XmlNode into v4 plugins
[ https://issues.apache.org/jira/browse/MNG-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731758#comment-17731758 ] ASF GitHub Bot commented on MNG-7751: - gnodet merged PR #1071: URL: https://github.com/apache/maven/pull/1071 > Ability to inject XmlNode into v4 plugins > - > > Key: MNG-7751 > URL: https://issues.apache.org/jira/browse/MNG-7751 > Project: Maven > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7751) Ability to inject XmlNode into v4 plugins
[ https://issues.apache.org/jira/browse/MNG-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7751. Resolution: Fixed > Ability to inject XmlNode into v4 plugins > - > > Key: MNG-7751 > URL: https://issues.apache.org/jira/browse/MNG-7751 > Project: Maven > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (MNG-7496) DefaultArtifactDescriptorReader.loadPom() should query the MavenWorkspaceReader first
[ https://issues.apache.org/jira/browse/MNG-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reopened MNG-7496: -- > DefaultArtifactDescriptorReader.loadPom() should query the > MavenWorkspaceReader first > - > > Key: MNG-7496 > URL: https://issues.apache.org/jira/browse/MNG-7496 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.8.6 >Reporter: Christoph Läubrich >Priority: Major > > Now WorkspaceReaders work in extensions and while I develop a basic > implementation in Tycho I noticed that I get asked for a pom, but not for the > model first. > The reason is that DefaultArtifactDescriptorReader.loadPom() do not query the > workspace reader but always resolves the pom artifact and then reads the pom > file. But afterwards, it do query the maven reader and use the model there. > I don't know if there is an need to download the pom always (but not use > it...), at least in my case it requires me to write the model to disk (with > possibly incomplete content as I only get the pom artifact, but not the > actual artifact the model is searched for) to make maven happy or I'll get > nasty: > [WARNING] The POM for ... is missing, no dependency information available > My idea would be, to simply first as the WSR for the model and if it is > present do not perform any actions or, at least ask the WSR first before fail > and issue a warning... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7496) DefaultArtifactDescriptorReader.loadPom() should query the MavenWorkspaceReader first
[ https://issues.apache.org/jira/browse/MNG-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7496. Resolution: Duplicate > DefaultArtifactDescriptorReader.loadPom() should query the > MavenWorkspaceReader first > - > > Key: MNG-7496 > URL: https://issues.apache.org/jira/browse/MNG-7496 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.8.6 >Reporter: Christoph Läubrich >Priority: Major > > Now WorkspaceReaders work in extensions and while I develop a basic > implementation in Tycho I noticed that I get asked for a pom, but not for the > model first. > The reason is that DefaultArtifactDescriptorReader.loadPom() do not query the > workspace reader but always resolves the pom artifact and then reads the pom > file. But afterwards, it do query the maven reader and use the model there. > I don't know if there is an need to download the pom always (but not use > it...), at least in my case it requires me to write the model to disk (with > possibly incomplete content as I only get the pom artifact, but not the > actual artifact the model is searched for) to make maven happy or I'll get > nasty: > [WARNING] The POM for ... is missing, no dependency information available > My idea would be, to simply first as the WSR for the model and if it is > present do not perform any actions or, at least ask the WSR first before fail > and issue a warning... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCLEAN-108) Upgrade to junit 5
Guillaume Nodet created MCLEAN-108: -- Summary: Upgrade to junit 5 Key: MCLEAN-108 URL: https://issues.apache.org/jira/browse/MCLEAN-108 Project: Maven Clean Plugin Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCLEAN-107) Upgrade to plexus-utils 4.0.0 and plexus-xml 4.0.0
Guillaume Nodet created MCLEAN-107: -- Summary: Upgrade to plexus-utils 4.0.0 and plexus-xml 4.0.0 Key: MCLEAN-107 URL: https://issues.apache.org/jira/browse/MCLEAN-107 Project: Maven Clean Plugin Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCLEAN-107) Upgrade to plexus-utils 4.0.0 and plexus-xml 4.0.0
[ https://issues.apache.org/jira/browse/MCLEAN-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731747#comment-17731747 ] ASF GitHub Bot commented on MCLEAN-107: --- gnodet opened a new pull request, #26: URL: https://github.com/apache/maven-clean-plugin/pull/26 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/MCLEAN) 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 `[MCLEAN-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MCLEAN-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). > Upgrade to plexus-utils 4.0.0 and plexus-xml 4.0.0 > -- > > Key: MCLEAN-107 > URL: https://issues.apache.org/jira/browse/MCLEAN-107 > Project: Maven Clean Plugin > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-clean-plugin] gnodet opened a new pull request, #26: [MCLEAN-107] Upgrade to plexus-utils 4.0.0 and plexus-xml 4.0.0
gnodet opened a new pull request, #26: URL: https://github.com/apache/maven-clean-plugin/pull/26 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/MCLEAN) 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 `[MCLEAN-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MCLEAN-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] [Closed] (MPLUGIN-475) Upgrade to plexus-utils / plexus-xml 4.0.0
[ https://issues.apache.org/jira/browse/MPLUGIN-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MPLUGIN-475. --- Fix Version/s: 3.9.1 Resolution: Fixed Fixed with https://github.com/apache/maven-plugin-tools/commit/44a4babb0ac0c2092a108ee12d14497642f534a0 > Upgrade to plexus-utils / plexus-xml 4.0.0 > -- > > Key: MPLUGIN-475 > URL: https://issues.apache.org/jira/browse/MPLUGIN-475 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.9.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1269) Deprecate maven-shared-utils
Guillaume Nodet created MSHARED-1269: Summary: Deprecate maven-shared-utils Key: MSHARED-1269 URL: https://issues.apache.org/jira/browse/MSHARED-1269 Project: Maven Shared Components Issue Type: New Feature Reporter: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-370) Lock factory should dump lock states on failure
[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731732#comment-17731732
]
ASF GitHub Bot commented on MRESOLVER-370:
--
cstamas commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1227092805
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##
@@ -43,7 +43,7 @@ public abstract class NamedLockSupport implements NamedLock {
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
-this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
+this.state = factory.isDiagnosticEnabled() ? new ConcurrentHashMap<>()
: null;
Review Comment:
Am actually quite uneasy with this "logger level changes at runtime" As
named lock instances come and go, but this is possible as well:
```
DI container
|-|
NamedLockFactory (as is singleton)
|-|
Session1
|---|
Session2
| -|
Session3
| -|
NamedLock1
|---|
NamedLock2
|-|
```
As instances are cached (and ref counted), potentially they can span
multiple sessions even, without any connection to session. IF we would always
obey logger level, we could end up with "incomplete" diag data as well, as
logger debug may be disabled-enabled-disabled-enabled, but if lock instance
spans across all 4 changes, diag map would contain only part of data
> Lock factory should dump lock states on failure
> ---
>
> Key: MRESOLVER-370
> URL: https://issues.apache.org/jira/browse/MRESOLVER-370
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.11
>
>
> When adapter "gives up" (as it could not acquire required lock), the error
> currently states "how many retries were against which lock". This gives
> information only about failed lock, but lacks the "whole picture".
> Proposed change: in case of lock failure, factory should dump out all lock
> states (may be huge on big builds), as that would allow simpler
> identification of possible problems. All this could be sorted out at "high
> level" (so no need to fiddle with file locks, hazelcast or redisson), but for
> memory constraints it should NOT be enabled by default, this "diagnostic"
> should be turned off by default, but possible by users to turn on if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #299: [MRESOLVER-370] Lock factory diagnostic on failure
cstamas commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1227092805
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##
@@ -43,7 +43,7 @@ public abstract class NamedLockSupport implements NamedLock {
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
-this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
+this.state = factory.isDiagnosticEnabled() ? new ConcurrentHashMap<>()
: null;
Review Comment:
Am actually quite uneasy with this "logger level changes at runtime" As
named lock instances come and go, but this is possible as well:
```
DI container
|-|
NamedLockFactory (as is singleton)
|-|
Session1
|---|
Session2
| -|
Session3
| -|
NamedLock1
|---|
NamedLock2
|-|
```
As instances are cached (and ref counted), potentially they can span
multiple sessions even, without any connection to session. IF we would always
obey logger level, we could end up with "incomplete" diag data as well, as
logger debug may be disabled-enabled-disabled-enabled, but if lock instance
spans across all 4 changes, diag map would contain only part of data
--
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-7729) Deprecate Xpp3Dom.isNonEmpty and isEmpty
[ https://issues.apache.org/jira/browse/MNG-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731730#comment-17731730 ] ASF GitHub Bot commented on MNG-7729: - gnodet closed pull request #1050: [MNG-7729] remove unused code URL: https://github.com/apache/maven/pull/1050 > Deprecate Xpp3Dom.isNonEmpty and isEmpty > > > Key: MNG-7729 > URL: https://issues.apache.org/jira/browse/MNG-7729 > Project: Maven > Issue Type: Task >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > And yet again copy pasta of random string utility methods that are public and > should never have been here -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7729) Deprecate Xpp3Dom.isNonEmpty and isEmpty
[ https://issues.apache.org/jira/browse/MNG-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731729#comment-17731729 ] ASF GitHub Bot commented on MNG-7729: - gnodet commented on PR #1050: URL: https://github.com/apache/maven/pull/1050#issuecomment-1587872657 I'm closing this one, as the location is now irrelevant, the code has changed and those constants are needed for compatibility and are actually used > Deprecate Xpp3Dom.isNonEmpty and isEmpty > > > Key: MNG-7729 > URL: https://issues.apache.org/jira/browse/MNG-7729 > Project: Maven > Issue Type: Task >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > And yet again copy pasta of random string utility methods that are public and > should never have been here -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet closed pull request #1050: [MNG-7729] remove unused code
gnodet closed pull request #1050: [MNG-7729] remove unused code URL: https://github.com/apache/maven/pull/1050 -- 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-build-cache-extension] bmarwell commented on a diff in pull request #58: Add METRO hash implementation, change the default, fix the web site
bmarwell commented on code in PR #58:
URL:
https://github.com/apache/maven-build-cache-extension/pull/58#discussion_r1227069806
##
src/main/java/org/apache/maven/buildcache/hash/Zah.java:
##
@@ -20,43 +20,55 @@
import java.io.IOException;
import java.nio.ByteBuffer;
+import java.nio.channels.FileChannel;
import java.nio.file.Files;
import java.nio.file.Path;
import net.openhft.hashing.LongHashFunction;
+import static java.nio.channels.FileChannel.MapMode.READ_ONLY;
+import static java.nio.file.StandardOpenOption.READ;
+
/**
- * XX
+ * Zero-Allocation-Hash based factory
*/
-public class XX implements Hash.Factory {
+public class Zah implements Hash.Factory {
+
+private final String name;
+private final LongHashFunction hash;
+private final boolean useMemoryMappedBuffers;
-static final LongHashFunction INSTANCE = LongHashFunction.xx();
+public Zah(String name, LongHashFunction hash, boolean
useMemoryMappedBuffers) {
Review Comment:
-1 on the boolean parameter. What if you need to distinguish further? Better
use a String or Enum.
--
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-424) Upgrade Parent to 30
[ https://issues.apache.org/jira/browse/MPOM-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731723#comment-17731723 ] Slawomir Jaranowski commented on MPOM-424: -- Done in https://github.com/apache/maven-parent/commit/f8cd129354f95a8ada8e9508e503997e04bb01fd > Upgrade Parent to 30 > > > Key: MPOM-424 > URL: https://issues.apache.org/jira/browse/MPOM-424 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: maven >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: MAVEN-40 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPOM-424) Upgrade Parent to 30
[ https://issues.apache.org/jira/browse/MPOM-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-424. Resolution: Fixed > Upgrade Parent to 30 > > > Key: MPOM-424 > URL: https://issues.apache.org/jira/browse/MPOM-424 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: maven >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: MAVEN-40 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-370) Lock factory should dump lock states on failure
[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731714#comment-17731714
]
ASF GitHub Bot commented on MRESOLVER-370:
--
gnodet commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1227027541
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##
@@ -43,7 +43,7 @@ public abstract class NamedLockSupport implements NamedLock {
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
-this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
+this.state = factory.isDiagnosticEnabled() ? new ConcurrentHashMap<>()
: null;
Review Comment:
You're right, it won't lead to a NPE, I misread the code. However, it's
caching the value of `isDiagnosticEnabled()`, so if we assume that its value
can change at runtime, we should create the map, then check again with
`factory.isDiagnosticEnabled()` in the code instead of `state != null`.
> Lock factory should dump lock states on failure
> ---
>
> Key: MRESOLVER-370
> URL: https://issues.apache.org/jira/browse/MRESOLVER-370
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.11
>
>
> When adapter "gives up" (as it could not acquire required lock), the error
> currently states "how many retries were against which lock". This gives
> information only about failed lock, but lacks the "whole picture".
> Proposed change: in case of lock failure, factory should dump out all lock
> states (may be huge on big builds), as that would allow simpler
> identification of possible problems. All this could be sorted out at "high
> level" (so no need to fiddle with file locks, hazelcast or redisson), but for
> memory constraints it should NOT be enabled by default, this "diagnostic"
> should be turned off by default, but possible by users to turn on if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-369) Expose configuration for update check manager where to apply policy
[
https://issues.apache.org/jira/browse/MRESOLVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731705#comment-17731705
]
ASF GitHub Bot commented on MRESOLVER-369:
--
cstamas commented on PR #297:
URL: https://github.com/apache/maven-resolver/pull/297#issuecomment-1587741095
PR is on-hold: testing shows that now when Maven "remembers" that Artifact
cannot be downloaded, there is no way to get out of it (-U does not help, as
policy is not applied to artifact by default anymore, before it simply went
here as -U was "always", and implicitly cleared the error flags as well, so it
"fixed" things).
IMO, this stems from the fact that policy ALWAYS was simply misused on Maven
side (-U), and instead, "force update" on maven side may mean something else,
like:
* set update policy to ALWAYS
* set cache not found/transfer to false
* ... (what else?)
> Expose configuration for update check manager where to apply policy
> ---
>
> Key: MRESOLVER-369
> URL: https://issues.apache.org/jira/browse/MRESOLVER-369
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.11
>
>
> Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
> and metadata. This causes problems when we want to "discover new versions"
> (or similar use case, that relies on fresh metadata), but metadata is never
> updated due remote repository update policy of "never", so only -U make it
> work as expected. -U OTOH is like shooting with cannon onto bird, as it
> updates many many more as well, not only the one metadata we are interested
> in.
> Moreover, since Maven3 artifacts are immutable.
> So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
> accepts values "all" (like today) and "metadata" (does not applies policy to
> artifacts, if artifact present, no update needed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #297: [MRESOLVER-369] Introduce update check policy scope
cstamas commented on PR #297: URL: https://github.com/apache/maven-resolver/pull/297#issuecomment-1587741095 PR is on-hold: testing shows that now when Maven "remembers" that Artifact cannot be downloaded, there is no way to get out of it (-U does not help, as policy is not applied to artifact by default anymore, before it simply went here as -U was "always", and implicitly cleared the error flags as well, so it "fixed" things). IMO, this stems from the fact that policy ALWAYS was simply misused on Maven side (-U), and instead, "force update" on maven side may mean something else, like: * set update policy to ALWAYS * set cache not found/transfer to false * ... (what else?) -- 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-370) Lock factory should dump lock states on failure
[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731690#comment-17731690
]
ASF GitHub Bot commented on MRESOLVER-370:
--
cstamas commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226942522
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##
@@ -43,7 +43,7 @@ public abstract class NamedLockSupport implements NamedLock {
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
-this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
+this.state = factory.isDiagnosticEnabled() ? new ConcurrentHashMap<>()
: null;
Review Comment:
the method is used only here, all the rest checks are `state != null` (and
state is final), unsure how can this NPE
> Lock factory should dump lock states on failure
> ---
>
> Key: MRESOLVER-370
> URL: https://issues.apache.org/jira/browse/MRESOLVER-370
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.11
>
>
> When adapter "gives up" (as it could not acquire required lock), the error
> currently states "how many retries were against which lock". This gives
> information only about failed lock, but lacks the "whole picture".
> Proposed change: in case of lock failure, factory should dump out all lock
> states (may be huge on big builds), as that would allow simpler
> identification of possible problems. All this could be sorted out at "high
> level" (so no need to fiddle with file locks, hazelcast or redisson), but for
> memory constraints it should NOT be enabled by default, this "diagnostic"
> should be turned off by default, but possible by users to turn on if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-370) Lock factory should dump lock states on failure
[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731691#comment-17731691
]
ASF GitHub Bot commented on MRESOLVER-370:
--
cstamas commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226942522
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##
@@ -43,7 +43,7 @@ public abstract class NamedLockSupport implements NamedLock {
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
-this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
+this.state = factory.isDiagnosticEnabled() ? new ConcurrentHashMap<>()
: null;
Review Comment:
the method is used only here, in ctor, all the rest checks are `state !=
null` (and state is final), unsure how can this NPE
> Lock factory should dump lock states on failure
> ---
>
> Key: MRESOLVER-370
> URL: https://issues.apache.org/jira/browse/MRESOLVER-370
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.11
>
>
> When adapter "gives up" (as it could not acquire required lock), the error
> currently states "how many retries were against which lock". This gives
> information only about failed lock, but lacks the "whole picture".
> Proposed change: in case of lock failure, factory should dump out all lock
> states (may be huge on big builds), as that would allow simpler
> identification of possible problems. All this could be sorted out at "high
> level" (so no need to fiddle with file locks, hazelcast or redisson), but for
> memory constraints it should NOT be enabled by default, this "diagnostic"
> should be turned off by default, but possible by users to turn on if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-370) Lock factory should dump lock states on failure
[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731688#comment-17731688
]
ASF GitHub Bot commented on MRESOLVER-370:
--
gnodet commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226934933
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##
@@ -43,7 +43,7 @@ public abstract class NamedLockSupport implements NamedLock {
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
-this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
+this.state = factory.isDiagnosticEnabled() ? new ConcurrentHashMap<>()
: null;
Review Comment:
If the logger level changes at runtime, that may lead to an NPE, so I'd just
create the map in all cases.
> Lock factory should dump lock states on failure
> ---
>
> Key: MRESOLVER-370
> URL: https://issues.apache.org/jira/browse/MRESOLVER-370
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.11
>
>
> When adapter "gives up" (as it could not acquire required lock), the error
> currently states "how many retries were against which lock". This gives
> information only about failed lock, but lacks the "whole picture".
> Proposed change: in case of lock failure, factory should dump out all lock
> states (may be huge on big builds), as that would allow simpler
> identification of possible problems. All this could be sorted out at "high
> level" (so no need to fiddle with file locks, hazelcast or redisson), but for
> memory constraints it should NOT be enabled by default, this "diagnostic"
> should be turned off by default, but possible by users to turn on if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7562) Mechanism for preventing inheritance of sections such as .
[
https://issues.apache.org/jira/browse/MNG-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731670#comment-17731670
]
Guillaume Nodet commented on MNG-7562:
--
One solution would be to add an attribute on the model specifying a list of
fields that should not be inherited.
{code}
{code}
However, if you're writing a POM that will be consumed, maybe a better solution
would be [MNG-5102|https://issues.apache.org/jira/browse/MNG-5102].
> Mechanism for preventing inheritance of sections such as .
> ---
>
> Key: MNG-7562
> URL: https://issues.apache.org/jira/browse/MNG-7562
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.6
>Reporter: Garret Wilson
>Priority: Major
>
> There needs to a way in the Maven POM to prevent an element from being
> inherited altogether in child POMs.
> We are currently publishing a Maven POM that is useful to serve as the parent
> POM for various projects. Some of the projects that use the POM will be open
> source, but some will not be. To designate our parent POM as open source, we
> include this:
> {code:xml}
>
>
> Apache-2.0
> https://www.apache.org/licenses/LICENSE-2.0
> repo
>
>
> {code}
> This essentially says, "this project is open source".
> Unfortunately because of [POM
> inheritance|https://maven.apache.org/pom.html#Inheritance], any project that
> uses this parent POM will also effectively be saying "this project is also
> open source", because the effective POM of all descendant projects will also
> include this same license section.
> Developers could try to remember to include some {{}} section to
> override this license, but the whole point of the parent POM is that it
> should given developers less to do, not more. Besides, some private projects
> (even ours) might not wish to indicate a license at all!
> There needs to be a way for our public parent POM to indicate that it is open
> source without effectively making all child projects open source as well
> through POM inheritance. Preventing the {{}} section from being
> inherited is one example of a more general mechanism needed to say, "Do not
> inherit this element at all in child POMs".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-370) Lock factory should dump lock states on failure
[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731667#comment-17731667
]
ASF GitHub Bot commented on MRESOLVER-370:
--
gnodet commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226865171
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockFactorySupport.java:
##
@@ -34,6 +35,8 @@
public abstract class NamedLockFactorySupport implements NamedLockFactory {
protected final Logger logger = LoggerFactory.getLogger(getClass());
+final boolean diagnostic = logger.isDebugEnabled();
Review Comment:
That's a bad idea. Loggers level can be updated at runtime, and the call to
`isDebugEnabled()` should be quite enough to not warrant caching the value.
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockFactorySupport.java:
##
@@ -34,6 +35,8 @@
public abstract class NamedLockFactorySupport implements NamedLockFactory {
protected final Logger logger = LoggerFactory.getLogger(getClass());
+final boolean diagnostic = logger.isDebugEnabled();
Review Comment:
That's a bad idea. Loggers level can be updated at runtime, and the call to
`isDebugEnabled()` should be fast enough to not warrant caching the value.
> Lock factory should dump lock states on failure
> ---
>
> Key: MRESOLVER-370
> URL: https://issues.apache.org/jira/browse/MRESOLVER-370
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.11
>
>
> When adapter "gives up" (as it could not acquire required lock), the error
> currently states "how many retries were against which lock". This gives
> information only about failed lock, but lacks the "whole picture".
> Proposed change: in case of lock failure, factory should dump out all lock
> states (may be huge on big builds), as that would allow simpler
> identification of possible problems. All this could be sorted out at "high
> level" (so no need to fiddle with file locks, hazelcast or redisson), but for
> memory constraints it should NOT be enabled by default, this "diagnostic"
> should be turned off by default, but possible by users to turn on if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPOM-424) Upgrade Parent to 30
Slawomir Jaranowski created MPOM-424: Summary: Upgrade Parent to 30 Key: MPOM-424 URL: https://issues.apache.org/jira/browse/MPOM-424 Project: Maven POMs Issue Type: Dependency upgrade Components: maven Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: MAVEN-40 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] gnodet commented on a diff in pull request #299: [MRESOLVER-370] Lock factory diagnostic on failure
gnodet commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226865171
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockFactorySupport.java:
##
@@ -34,6 +35,8 @@
public abstract class NamedLockFactorySupport implements NamedLockFactory {
protected final Logger logger = LoggerFactory.getLogger(getClass());
+final boolean diagnostic = logger.isDebugEnabled();
Review Comment:
That's a bad idea. Loggers level can be updated at runtime, and the call to
`isDebugEnabled()` should be quite enough to not warrant caching the value.
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockFactorySupport.java:
##
@@ -34,6 +35,8 @@
public abstract class NamedLockFactorySupport implements NamedLockFactory {
protected final Logger logger = LoggerFactory.getLogger(getClass());
+final boolean diagnostic = logger.isDebugEnabled();
Review Comment:
That's a bad idea. Loggers level can be updated at runtime, and the call to
`isDebugEnabled()` should be fast enough to not warrant caching the value.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MRESOLVER-365) Upgrade dependencies
[ https://issues.apache.org/jira/browse/MRESOLVER-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-365: -- Component/s: Resolver > Upgrade dependencies > > > Key: MRESOLVER-365 > URL: https://issues.apache.org/jira/browse/MRESOLVER-365 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > Changes: > * (transport-http) httpClient 4.5.14 > * (transport-http) httpCore 4.4.16 > * (transport-http, test-only) Jetty 9.4.51 > * (transport-wagon) wagon 3.5.3 > * (transport-wagon) plexus-classworlds 2.7.0 > * (named-locks-hazelcast) hazelcast 5.3.0 > * (named-locks-redisson) see MRESOLVER-367 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-366) Upgrade build plugins
[ https://issues.apache.org/jira/browse/MRESOLVER-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-366: -- Component/s: Resolver > Upgrade build plugins > - > > Key: MRESOLVER-366 > URL: https://issues.apache.org/jira/browse/MRESOLVER-366 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > Updating only those added/already redefined in resolver POM or below, not > overriding all from parent, they will come with parent POM upgrade. > Changes: > * maven-install-plugin 3.1.1 > * maven-deploy-plugin 3.1.1 > * animal sniffer 1.23 > * japicmp 0.17.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-361) Unreliable TCP and retries on upload
[ https://issues.apache.org/jira/browse/MRESOLVER-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-361: -- Component/s: Resolver > Unreliable TCP and retries on upload > > > Key: MRESOLVER-361 > URL: https://issues.apache.org/jira/browse/MRESOLVER-361 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > Two issues reported: > * PUT on closed connection is not retried. Suggested fix: change retry > handler to one that treats PUT as idempotent. > * -Oddity with 1 vs 2+ checksum algorithm used, in first case checksum > upload failure fails whole build, in second it only warns.- This proved > wrong, user build failed as metadata (so "main" payload not checksum of the > main payload) failed due HTTP connection error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-367) upgrade redisson in named locks and simplify installation
[
https://issues.apache.org/jira/browse/MRESOLVER-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-367:
--
Component/s: Resolver
> upgrade redisson in named locks and simplify installation
> -
>
> Key: MRESOLVER-367
> URL: https://issues.apache.org/jira/browse/MRESOLVER-367
> Project: Maven Resolver
> Issue Type: Dependency upgrade
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.11
>
>
> Upgrade:
> * redisson 3.21.3
> Furthermore, replace "manual installation" (downloads dependency by
> dependency) with a "bundle" zip that contains all the dependency user needs
> to extract into {{{}lib/ext/redisson{}}}.
> Update doco accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-364) Revert MRESOLVER-132
[ https://issues.apache.org/jira/browse/MRESOLVER-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-364: -- Component/s: Resolver > Revert MRESOLVER-132 > > > Key: MRESOLVER-364 > URL: https://issues.apache.org/jira/browse/MRESOLVER-364 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > Revert MRESOLVER-132 commit > [https://github.com/apache/maven-resolver/commit/fcb6be59c5a5855573886b09c70dab80074a1d27] > Must be done manually, as since then class was made into component and this > filename is an interface now. > Reasoning: as we recently saw, they may be still plugins (knowingly or not > knowingly) using maven-compat, that update check manager read/writes same > files as resolve (but uses different keys). This lock was in place way long > before SyncContext, and intent was to sync resolver and maven-compat access, > that still happens, so undo this change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-353) Make aether.checksums.algorithms settable per remote repository
[ https://issues.apache.org/jira/browse/MRESOLVER-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-353: -- Component/s: Resolver > Make aether.checksums.algorithms settable per remote repository > --- > > Key: MRESOLVER-353 > URL: https://issues.apache.org/jira/browse/MRESOLVER-353 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-356) Remove Guava (is unused)
[ https://issues.apache.org/jira/browse/MRESOLVER-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-356: -- Component/s: Resolver > Remove Guava (is unused) > > > Key: MRESOLVER-356 > URL: https://issues.apache.org/jira/browse/MRESOLVER-356 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Elliotte Rusty Harold >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 1.9.11 > > > or later, depending on how long it takes to get to this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-370) Lock factory should dump lock states on failure
[ https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-370: -- Fix Version/s: 1.9.11 > Lock factory should dump lock states on failure > --- > > Key: MRESOLVER-370 > URL: https://issues.apache.org/jira/browse/MRESOLVER-370 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > When adapter "gives up" (as it could not acquire required lock), the error > currently states "how many retries were against which lock". This gives > information only about failed lock, but lacks the "whole picture". > Proposed change: in case of lock failure, factory should dump out all lock > states (may be huge on big builds), as that would allow simpler > identification of possible problems. All this could be sorted out at "high > level" (so no need to fiddle with file locks, hazelcast or redisson), but for > memory constraints it should NOT be enabled by default, this "diagnostic" > should be turned off by default, but possible by users to turn on if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-370) Lock factory should dump lock states on failure
[ https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-370: - Assignee: Tamas Cservenak > Lock factory should dump lock states on failure > --- > > Key: MRESOLVER-370 > URL: https://issues.apache.org/jira/browse/MRESOLVER-370 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > When adapter "gives up" (as it could not acquire required lock), the error > currently states "how many retries were against which lock". This gives > information only about failed lock, but lacks the "whole picture". > Proposed change: in case of lock failure, factory should dump out all lock > states (may be huge on big builds), as that would allow simpler > identification of possible problems. All this could be sorted out at "high > level" (so no need to fiddle with file locks, hazelcast or redisson), but for > memory constraints it should NOT be enabled by default, this "diagnostic" > should be turned off by default, but possible by users to turn on if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-370) Lock factory should dump lock states on failure
[ https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-370: -- Issue Type: New Feature (was: Improvement) > Lock factory should dump lock states on failure > --- > > Key: MRESOLVER-370 > URL: https://issues.apache.org/jira/browse/MRESOLVER-370 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > When adapter "gives up" (as it could not acquire required lock), the error > currently states "how many retries were against which lock". This gives > information only about failed lock, but lacks the "whole picture". > Proposed change: in case of lock failure, factory should dump out all lock > states (may be huge on big builds), as that would allow simpler > identification of possible problems. All this could be sorted out at "high > level" (so no need to fiddle with file locks, hazelcast or redisson), but for > memory constraints it should NOT be enabled by default, this "diagnostic" > should be turned off by default, but possible by users to turn on if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7573) modello-plugin-velocity m2e support
[
https://issues.apache.org/jira/browse/MNG-7573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-7573.
Resolution: Won't Fix
The code has moved to
https://github.com/codehaus-plexus/modello/tree/master/modello-plugins/modello-plugin-velocity
An issue must be created there.
> modello-plugin-velocity m2e support
>
>
> Key: MNG-7573
> URL: https://issues.apache.org/jira/browse/MNG-7573
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> The goal {{velocity}} is not supported by m2e, leading to build errors in
> Eclipse incremental build due to undetected generated sources below
> {{target/generated-sources}}. Also those sources should be automatically
> build during incremental auto build.
> This requires at least an Eclipse M2E extension similar to
> https://github.com/tesla/m2eclipse-modello. Optionally the lifecycle mapping
> can also be provided with the regular maven-plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7589) MavenXpp3Writer write empty property with self-closing tag?
[
https://issues.apache.org/jira/browse/MNG-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731647#comment-17731647
]
Guillaume Nodet commented on MNG-7589:
--
Do you have a simple reproducer project to investigate a bit ?
> MavenXpp3Writer write empty property with self-closing tag?
> ---
>
> Key: MNG-7589
> URL: https://issues.apache.org/jira/browse/MNG-7589
> Project: Maven
> Issue Type: Wish
> Components: Core
>Affects Versions: 3.8.6
> Environment: Maven 3.8.6
>Reporter: Jeff Thomas
>Priority: Trivial
>
> I am using a maven-plugin which manipulates the POM and writes a new POM
> model. (similar to 'maven-git-versioning-extension' or
> 'flatten-maven-plugin').
> When writing a POM using the MavenXpp3Writer a property without a value is
> written out as follows:
>
> {code:java}
>
>
>
>
>
> {code}
>
> Would it be possible to write this out with a self-closing tag? Or provide an
> option to the writer to do so?
>
> {code:java}
>
>
>
>
> {code}
> Its just eye-candy but the IDE (IntelliJ) displays warnings for empty tags
> and I don't want to disable the check globally. :)
>
> Why empty properties?
> For some plugins we use empty properties as placeholders which child projects
> or sub-modules can override. For example: maven-surefire-plugin `argLine`.
> This prevents other IDE errors for missing properties when editing the POM.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-6868) Ability to define properties that are lists
[
https://issues.apache.org/jira/browse/MNG-6868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-6868.
Resolution: Won't Fix
> Ability to define properties that are lists
> ---
>
> Key: MNG-6868
> URL: https://issues.apache.org/jira/browse/MNG-6868
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.6.3
>Reporter: Rafał Figas
>Priority: Major
>
> It would be nice if this would be possible in pom.xml:
> {noformat}
>
>
> tagA
> tagB
>
>
> {noformat}
> So it could be used like this:
> {noformat}
>
> ...
>
> ${my-property.list-of-sthg}
>
>
> {noformat}
> It would be helpful when using profiles. Otherwise one has to move whole
> plugin into profile even if the difference is only in one list parameter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7592) String deduplication in model building
[
https://issues.apache.org/jira/browse/MNG-7592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731628#comment-17731628
]
Guillaume Nodet commented on MNG-7592:
--
That sounds like a good improvement.
Since interned strings are GC'ed, a trivial thing would be to wrap the
{{XmlPullParser}} created in the {{ModelReader#read}} method to use intern
strings on {{XmlPullParser#getName()}} and {{XmlPullParser#getText()}}. I
would think all name elements have to be interned, and most element's text
(groupId, artifactId, version, scope, etc...)
This could give a good estimate if that's worth investigating or not.
> String deduplication in model building
> --
>
> Key: MNG-7592
> URL: https://issues.apache.org/jira/browse/MNG-7592
> Project: Maven
> Issue Type: Improvement
>Reporter: Christoph Läubrich
>Priority: Major
>
> I currently investigate improving memory consumption in m2eclipse (maven ide
> extension) and noticed that one problem is that maven model seem to not
> deduplicate strings, so for large projects (I used apache camel as an
> example), there are a lot of duplicate strings hanging around, e.g. I see
> 12.000 instances of "org.apache.maven.plugins" or around 10.000 of
> "org.apache.camel" (please note that probably not all related to maven!).
> If I look at the Graph of incoming references I see for example that these
> are from Model/Artifact groupId.
> I know that string deduplication in general is hard and even controversial,
> but maybe one could think about such thing at least for the "hotsposts", e,g,
> groupId, artifactId and version or even managementKeys seem good candidates
> to be considered for such thing as these are used all over the place.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7599) Include Concurrent Safe Local Repository implementation in standard maven
[
https://issues.apache.org/jira/browse/MNG-7599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-7599.
Resolution: Won't Fix
This will be provided by the maven resolver.
> Include Concurrent Safe Local Repository implementation in standard maven
> -
>
> Key: MNG-7599
> URL: https://issues.apache.org/jira/browse/MNG-7599
> Project: Maven
> Issue Type: Improvement
>Reporter: Christoph Läubrich
>Priority: Major
>
> See http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository
> {quote}
> The access to the local repository performed by a standard Maven installation
> is not designed to support multiple instances of Maven or even multiple
> threads from the same Maven invocation accessing it concurrently. Concurrent
> access can end up corrupting the consistency of the repository due to wrong
> metadata file content and similar problems.
> {quote}
> Multi-Threaded builds are quite common I think and also sharing the same
> local repository across builds (e.g. builds in the IDE, some long running
> ones in terminals, even multiple parallel terminals) has several advantages.
> I therefore like to suggest to in cooperate the code into standard maven so
> one don't need to use extensions for something that users would expect
> without special configuration.
> The code is Apache-2.0 license so should be compatible with maven...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7602) Move back model version from 5.0 to 4.2 and reactivate modello site generation
[ https://issues.apache.org/jira/browse/MNG-7602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MNG-7602: Assignee: Guillaume Nodet > Move back model version from 5.0 to 4.2 and reactivate modello site generation > -- > > Key: MNG-7602 > URL: https://issues.apache.org/jira/browse/MNG-7602 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7602) Move back model version from 5.0 to 4.2 and reactivate modello site generation
[ https://issues.apache.org/jira/browse/MNG-7602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7602. Fix Version/s: 4.0.0-alpha-3 Resolution: Fixed > Move back model version from 5.0 to 4.2 and reactivate modello site generation > -- > > Key: MNG-7602 > URL: https://issues.apache.org/jira/browse/MNG-7602 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-7631:
Assignee: Guillaume Nodet
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Assignee: Guillaume Nodet
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f {}}}, so the local repository
> root really is {{{}{}}}, not {{}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7632) Regression: combine.children breaks when combining executions
[ https://issues.apache.org/jira/browse/MNG-7632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MNG-7632: Assignee: Guillaume Nodet > Regression: combine.children breaks when combining executions > - > > Key: MNG-7632 > URL: https://issues.apache.org/jira/browse/MNG-7632 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 4.0.0-alpha-2 >Reporter: Lenny Primak >Assignee: Guillaume Nodet >Priority: Minor > > When upgrading from 3.x to 4.x, combine.children behaves differently. > When it is declared in the parent pom, the child pom do not correctly > combines elements: > See > [https://github.com/flowlogix/flowlogix/commit/301f428a229f4ab51e55a488bd71ec4aec87bce4] > for a reproducer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-370) Lock factory should dump lock states on failure
[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731617#comment-17731617
]
ASF GitHub Bot commented on MRESOLVER-370:
--
cstamas commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226661563
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##
@@ -32,18 +38,76 @@ public abstract class NamedLockSupport implements NamedLock
{
private final NamedLockFactorySupport factory;
+private final ConcurrentHashMap> state;
+
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
+this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
}
@Override
public String name() {
return name;
}
+@Override
+public boolean lockShared(long time, TimeUnit unit) throws
InterruptedException {
+if (state != null) {
+state.computeIfAbsent(Thread.currentThread(), k -> new
ArrayDeque<>())
+.push("S");
Review Comment:
Agreed, although named locks API does not limit (boxing depth), in reality
syncContext does "shallow" boxing.
> Lock factory should dump lock states on failure
> ---
>
> Key: MRESOLVER-370
> URL: https://issues.apache.org/jira/browse/MRESOLVER-370
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> When adapter "gives up" (as it could not acquire required lock), the error
> currently states "how many retries were against which lock". This gives
> information only about failed lock, but lacks the "whole picture".
> Proposed change: in case of lock failure, factory should dump out all lock
> states (may be huge on big builds), as that would allow simpler
> identification of possible problems. All this could be sorted out at "high
> level" (so no need to fiddle with file locks, hazelcast or redisson), but for
> memory constraints it should NOT be enabled by default, this "diagnostic"
> should be turned off by default, but possible by users to turn on if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #299: [MRESOLVER-370] Lock factory diagnostic on failure
cstamas commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226661563
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##
@@ -32,18 +38,76 @@ public abstract class NamedLockSupport implements NamedLock
{
private final NamedLockFactorySupport factory;
+private final ConcurrentHashMap> state;
+
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
+this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
}
@Override
public String name() {
return name;
}
+@Override
+public boolean lockShared(long time, TimeUnit unit) throws
InterruptedException {
+if (state != null) {
+state.computeIfAbsent(Thread.currentThread(), k -> new
ArrayDeque<>())
+.push("S");
Review Comment:
Agreed, although named locks API does not limit (boxing depth), in reality
syncContext does "shallow" boxing.
--
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-370) Lock factory should dump lock states on failure
[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731613#comment-17731613
]
ASF GitHub Bot commented on MRESOLVER-370:
--
gnodet commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226656453
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##
@@ -32,18 +38,76 @@ public abstract class NamedLockSupport implements NamedLock
{
private final NamedLockFactorySupport factory;
+private final ConcurrentHashMap> state;
+
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
+this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
}
@Override
public String name() {
return name;
}
+@Override
+public boolean lockShared(long time, TimeUnit unit) throws
InterruptedException {
+if (state != null) {
+state.computeIfAbsent(Thread.currentThread(), k -> new
ArrayDeque<>())
+.push("S");
Review Comment:
if we don't expect more than a few locks per thread at the same time, I
would use `shared` and `exclusive`, it will not require the reader to go back
to the source to understand what S/X means.
> Lock factory should dump lock states on failure
> ---
>
> Key: MRESOLVER-370
> URL: https://issues.apache.org/jira/browse/MRESOLVER-370
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> When adapter "gives up" (as it could not acquire required lock), the error
> currently states "how many retries were against which lock". This gives
> information only about failed lock, but lacks the "whole picture".
> Proposed change: in case of lock failure, factory should dump out all lock
> states (may be huge on big builds), as that would allow simpler
> identification of possible problems. All this could be sorted out at "high
> level" (so no need to fiddle with file locks, hazelcast or redisson), but for
> memory constraints it should NOT be enabled by default, this "diagnostic"
> should be turned off by default, but possible by users to turn on if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] gnodet commented on a diff in pull request #299: [MRESOLVER-370] Lock factory diagnostic on failure
gnodet commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226656453
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/NamedLockSupport.java:
##
@@ -32,18 +38,76 @@ public abstract class NamedLockSupport implements NamedLock
{
private final NamedLockFactorySupport factory;
+private final ConcurrentHashMap> state;
+
public NamedLockSupport(final String name, final NamedLockFactorySupport
factory) {
this.name = name;
this.factory = factory;
+this.state = factory.diagnostic ? new ConcurrentHashMap<>() : null;
}
@Override
public String name() {
return name;
}
+@Override
+public boolean lockShared(long time, TimeUnit unit) throws
InterruptedException {
+if (state != null) {
+state.computeIfAbsent(Thread.currentThread(), k -> new
ArrayDeque<>())
+.push("S");
Review Comment:
if we don't expect more than a few locks per thread at the same time, I
would use `shared` and `exclusive`, it will not require the reader to go back
to the source to understand what S/X means.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Assigned] (MNG-7745) NPE when .mvn doesn't exist
[
https://issues.apache.org/jira/browse/MNG-7745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-7745:
Assignee: Guillaume Nodet
> NPE when .mvn doesn't exist
> ---
>
> Key: MNG-7745
> URL: https://issues.apache.org/jira/browse/MNG-7745
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-4, 4.0.0-alpha-5
> Environment: Any
>Reporter: Lenny Primak
>Assignee: Guillaume Nodet
>Priority: Minor
>
> When maven is executed without a .mvn directory, an NPE appears every time.
> This doesn't seem to affect anything but does pollute the logs:
> {code:java}
> Failed to notify spy org.apache.maven.ReactorReader$ReactorReaderSpy: Cannot
> invoke "java.io.File.toPath()" because the return value of
> "org.apache.maven.project.MavenProject.getFile()" is null {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7768) Don't abuse RepositorySystemSession and other Resolver classes in Maven Core
[
https://issues.apache.org/jira/browse/MNG-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7768:
-
Fix Version/s: 4.x / Backlog
> Don't abuse RepositorySystemSession and other Resolver classes in Maven Core
>
>
> Key: MNG-7768
> URL: https://issues.apache.org/jira/browse/MNG-7768
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.1
>Reporter: Michael Osipov
>Priority: Major
> Fix For: 4.x / Backlog
>
>
> As noticed in [this PR|https://github.com/apache/maven/pull/1092]
> {{maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java}}
> abuses {{RepositorySystemSession}} and {{ConfigUtils}} for convenience
> reasons. Those classes are unrelated and should feed from {{MavenSession}}
> since they don't interact with the repo system at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7768) Don't abuse RepositorySystemSession and other Resolver classes in Maven Core
[
https://issues.apache.org/jira/browse/MNG-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731605#comment-17731605
]
Guillaume Nodet commented on MNG-7768:
--
Part of the problem is that the MavenSession is not available in a few
components. Some SPI such as {{MavenPluginManager}},
{{PluginDependenciesResolver}} are given a {{RepositorySystemSession}}.
I think they should be reworked completely, and they can then be given a v4 api
{{Session}}.
> Don't abuse RepositorySystemSession and other Resolver classes in Maven Core
>
>
> Key: MNG-7768
> URL: https://issues.apache.org/jira/browse/MNG-7768
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.1
>Reporter: Michael Osipov
>Priority: Major
>
> As noticed in [this PR|https://github.com/apache/maven/pull/1092]
> {{maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java}}
> abuses {{RepositorySystemSession}} and {{ConfigUtils}} for convenience
> reasons. Those classes are unrelated and should feed from {{MavenSession}}
> since they don't interact with the repo system at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-invoker-plugin] elharo merged pull request #196: add explicit dependency on commons-lang3 and update version
elharo merged PR #196: URL: https://github.com/apache/maven-invoker-plugin/pull/196 -- 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] (MDEPLOY-310) Provide a SPI for the v4 api
Guillaume Nodet created MDEPLOY-310: --- Summary: Provide a SPI for the v4 api Key: MDEPLOY-310 URL: https://issues.apache.org/jira/browse/MDEPLOY-310 Project: Maven Deploy Plugin Issue Type: New Feature Reporter: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Moved] (MNG-7810) Provide a SPI for the v4 api
[ https://issues.apache.org/jira/browse/MNG-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet moved MDEPLOY-310 to MNG-7810: -- Key: MNG-7810 (was: MDEPLOY-310) Project: Maven (was: Maven Deploy Plugin) > Provide a SPI for the v4 api > > > Key: MNG-7810 > URL: https://issues.apache.org/jira/browse/MNG-7810 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7810) Provide a SPI for the v4 api
[ https://issues.apache.org/jira/browse/MNG-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7810: - Fix Version/s: 4.x / Backlog > Provide a SPI for the v4 api > > > Key: MNG-7810 > URL: https://issues.apache.org/jira/browse/MNG-7810 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.x / Backlog > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-370) Lock factory should dump lock states on failure
[
https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731600#comment-17731600
]
ASF GitHub Bot commented on MRESOLVER-370:
--
gnodet commented on code in PR #299:
URL: https://github.com/apache/maven-resolver/pull/299#discussion_r1226637930
##
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/NamedLockFactory.java:
##
@@ -35,4 +37,18 @@ public interface NamedLockFactory {
* Performs a clean shut down of the factory.
*/
void shutdown();
+
+/**
+ * Utility method to provide more (factory specific) description when a
locking operation failed. Assumption is
+ * that provided list has at least one element (one failure) or more (in
case of retries), must not be {@code null}
+ * to get meaningful exceptions. The returned exception will be new
instance of {@link IllegalStateException} with
+ * passed in list added as suppressed exceptions. Still, the fact this
method has be invoked, means there is a
+ * "abort failure" ahead, so factory may either decorate (add info about
state) or even log some diagnostic
+ * about the state of the locks.
+ *
+ * @since TBD
+ * @return A new instance of {@link IllegalStateException} (decorated) and
may have other side effects as well
+ * (dumping state), never {@code null}.
+ */
+IllegalStateException failure(List attempts);
Review Comment:
If `NamedLockFactory` is a public SPI, maybe a `default` method would be
more appropriate here ?
> Lock factory should dump lock states on failure
> ---
>
> Key: MRESOLVER-370
> URL: https://issues.apache.org/jira/browse/MRESOLVER-370
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> When adapter "gives up" (as it could not acquire required lock), the error
> currently states "how many retries were against which lock". This gives
> information only about failed lock, but lacks the "whole picture".
> Proposed change: in case of lock failure, factory should dump out all lock
> states (may be huge on big builds), as that would allow simpler
> identification of possible problems. All this could be sorted out at "high
> level" (so no need to fiddle with file locks, hazelcast or redisson), but for
> memory constraints it should NOT be enabled by default, this "diagnostic"
> should be turned off by default, but possible by users to turn on if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-370) Lock factory should dump lock states on failure
[ https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731599#comment-17731599 ] ASF GitHub Bot commented on MRESOLVER-370: -- cstamas commented on PR #299: URL: https://github.com/apache/maven-resolver/pull/299#issuecomment-1587302862 Example outputs https://gist.github.com/cstamas/fe1bd5b73c3e02877d9647c00aa40831 > Lock factory should dump lock states on failure > --- > > Key: MRESOLVER-370 > URL: https://issues.apache.org/jira/browse/MRESOLVER-370 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > When adapter "gives up" (as it could not acquire required lock), the error > currently states "how many retries were against which lock". This gives > information only about failed lock, but lacks the "whole picture". > Proposed change: in case of lock failure, factory should dump out all lock > states (may be huge on big builds), as that would allow simpler > identification of possible problems. All this could be sorted out at "high > level" (so no need to fiddle with file locks, hazelcast or redisson), but for > memory constraints it should NOT be enabled by default, this "diagnostic" > should be turned off by default, but possible by users to turn on if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #299: [MRESOLVER-370] Lock factory diagnostic on failure
cstamas commented on PR #299: URL: https://github.com/apache/maven-resolver/pull/299#issuecomment-1587302862 Example outputs https://gist.github.com/cstamas/fe1bd5b73c3e02877d9647c00aa40831 -- 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-370) Lock factory should dump lock states on failure
[ https://issues.apache.org/jira/browse/MRESOLVER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731598#comment-17731598 ] ASF GitHub Bot commented on MRESOLVER-370: -- cstamas opened a new pull request, #299: URL: https://github.com/apache/maven-resolver/pull/299 The change "push" all `NamedLock` interface methods "level down" on implementations, to be able to augment instances at `NamedLockSupport` level. If used factory DEBUG level is enabled on logger, it turns on "diagnostic" mode (will consume more memory as well!): * factory makes all named lock instances to gather "diag stats" (memory!) * on adapter failure, factory will dump out diag state, * each active lock (non closed) will dump it's state out * output goes to lock factory DEBUG logger, but it may be huge By default, when "diagnostic" not turned on, no change, merely the construction of finally thrown ISEx is relocated from adapter to factory. --- https://issues.apache.org/jira/browse/MRESOLVER-370 > Lock factory should dump lock states on failure > --- > > Key: MRESOLVER-370 > URL: https://issues.apache.org/jira/browse/MRESOLVER-370 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > When adapter "gives up" (as it could not acquire required lock), the error > currently states "how many retries were against which lock". This gives > information only about failed lock, but lacks the "whole picture". > Proposed change: in case of lock failure, factory should dump out all lock > states (may be huge on big builds), as that would allow simpler > identification of possible problems. All this could be sorted out at "high > level" (so no need to fiddle with file locks, hazelcast or redisson), but for > memory constraints it should NOT be enabled by default, this "diagnostic" > should be turned off by default, but possible by users to turn on if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-370) Lock factory should dump lock states on failure
Tamas Cservenak created MRESOLVER-370: - Summary: Lock factory should dump lock states on failure Key: MRESOLVER-370 URL: https://issues.apache.org/jira/browse/MRESOLVER-370 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Tamas Cservenak When adapter "gives up" (as it could not acquire required lock), the error currently states "how many retries were against which lock". This gives information only about failed lock, but lacks the "whole picture". Proposed change: in case of lock failure, factory should dump out all lock states (may be huge on big builds), as that would allow simpler identification of possible problems. All this could be sorted out at "high level" (so no need to fiddle with file locks, hazelcast or redisson), but for memory constraints it should NOT be enabled by default, this "diagnostic" should be turned off by default, but possible by users to turn on if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731581#comment-17731581
]
ASF GitHub Bot commented on MNG-7802:
-
gnodet commented on PR #1144:
URL: https://github.com/apache/maven/pull/1144#issuecomment-1587196633
Will update the PR when https://github.com/apache/maven-resolver/pull/297 is
released.
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7809) Make maven-compat optional
Guillaume Nodet created MNG-7809: Summary: Make maven-compat optional Key: MNG-7809 URL: https://issues.apache.org/jira/browse/MNG-7809 Project: Maven Issue Type: Improvement Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 4.0.0-alpha-6 Maven-compat is currently a runtime requirement as it contains implementation of core services (RepositorySystem). Until all plugins are migrated out of those deprecated APIs and before maven-compat can be removed, we need to make it really optional and it should only contain deprecated stuff. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-6561) New RepositorySystem implementation as replacement of deprecated from maven-compat
[
https://issues.apache.org/jira/browse/MNG-6561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-6561.
Fix Version/s: (was: 4.0.x-candidate)
Resolution: Won't Fix
> New RepositorySystem implementation as replacement of deprecated from
> maven-compat
> --
>
> Key: MNG-6561
> URL: https://issues.apache.org/jira/browse/MNG-6561
> Project: Maven
> Issue Type: Improvement
>Reporter: Sylwester Lachiewicz
>Priority: Major
> Labels: must-be-in-4.0.0-alpha-2
>
> Create a component that will replace
> org.apache.maven.repository.RepositorySystem implementation from maven-compat
> module to keep backward compatibility with Maven 2.x plugins.
> While testing MNG-5995 and with deleted maven-compat.jar - a compilation of
> basic project failed with error:
>
> {code:java}
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ my-app ---
> [WARNING] Error injecting: org.apache.maven.plugin.compiler.CompilerMojo
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was
> bound.
> while locating org.apache.maven.plugin.compiler.CompilerMojo
> 1 error
> at com.google.inject.internal.InternalProvisionException.toProvisionException
> (InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1053)
> at com.google.inject.internal.InjectorImpl.getInstance
> (InjectorImpl.java:1086)
> at org.eclipse.sisu.space.AbstractDeferredClass.get
> (AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision
> (ProviderInternalFactory.java:85)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision
> (InternalFactoryToInitializableAdapter.java:57)
> at com.google.inject.internal.ProviderInternalFactory$1.call
> (ProviderInternalFactory.java:66)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:112)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:127)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision
> (ProvisionListenerStackCallback.java:66)
> at com.google.inject.internal.ProviderInternalFactory.circularGet
> (ProviderInternalFactory.java:61)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get
> (InternalFactoryToInitializableAdapter.java:47)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1050)
> at org.eclipse.sisu.inject.Guice4$1.get (Guice4.java:162)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue (LazyBeanEntry.java:81)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue (LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:263)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:255)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
> (DefaultMavenPluginManager.java:520)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:124)
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile
> (default-compile) on project my-app: Execution default-compile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed: Unable
> to load the mojo 'compile' (or one of its required components) from the
> plugin 'org.apache.maven.plugins:maven-compiler-plugin:3.8.0':
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> [ERROR]
> [ERROR] 1) No implementation for c was bound.
> [ERROR] while locating org.apache.maven.plugin.compiler.CompilerMojo
> [ERROR] at
> ClassRealm[plugin>org.apache.maven.plugins:maven-compiler-plugin:3.8.0,
> parent: jdk.internal.loader.ClassLoaders$AppClassLoader@6e5e91e4] (via
> modules: org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> [ERROR] while locating org.apache.maven.plugin.Mojo annotated with
> @com.google.inject.name.Named(value="org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile")
> [ERROR]
> [ERROR] 1 error
> [ERROR] role: org.apache.maven.plugin.Mojo
> [ERROR] roleHint:
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile{code}
> Sometimes we can change usages of
> _org.apache.maven.repository.RepositorySystem_ to
> _org.apache.maven.bridge.MavenRepositorySystem_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-5600:
Assignee: Guillaume Nodet
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.x-candidate
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MBUILDCACHE-61:
Summary: XXMM hash algorithm does not work on Java 17 (was: XX hash
algorithm does not work on Java 17)
> XXMM hash algorithm does not work on Java 17
>
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Priority: Major
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/webappsrv/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/de.fi.my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
> constituent[21]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
> constituent[22]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
> constituent[23]:
>
[jira] [Updated] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MBUILDCACHE-61:
Description:
h2. Actual behaviour
When trying to use XXMM, I get this error:
{code:java}
$ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
-Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
from $HOME/Projects/git/my-app/.mvn/maven-build-cache-config.xml
[INFO] Using XXMM hash algorithm for cache
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[...]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.386 s
[INFO] Finished at: 2023-06-12T11:58:13+02:00
[INFO]
[INFO] Saving cache report on build completion
[INFO] Saved to remote cache
dav:http://my-server:8049/build-cache/my-app//v1/my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
---
constituent[0]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
constituent[1]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
constituent[2]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
constituent[3]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
constituent[4]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
constituent[5]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
constituent[6]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
constituent[7]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
constituent[8]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
constituent[9]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
constituent[10]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
constituent[11]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
constituent[12]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
constituent[13]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
constituent[14]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
constituent[15]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
constituent[16]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
constituent[17]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
constituent[18]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
constituent[19]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
constituent[20]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
constituent[21]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
constituent[22]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
constituent[23]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-core-3.9.2.jar
constituent[24]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/failureaccess-1.0.1.jar
constituent[25]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-builder-support-3.9.2.jar
constituent[26]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/jcl-over-slf4j-1.7.36.jar
constituent[27]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-util-1.9.10.jar
constituent[28]:
[jira] (MDEPLOY-306) [REGRESSION] Could not acquire write lock
[ https://issues.apache.org/jira/browse/MDEPLOY-306 ]
bendemctl deleted comment on MDEPLOY-306:
---
was (Author: JIRAUSER300653):
I have the same error, but it doesn't happen in the deploy plugin, it happens
in the generic dependency resolution since we upgraded to maven 3.9.2.
Stacktrace :
{quote}#11 12.30 [INFO]
#11 12.30 [INFO] BUILD FAILURE
#11 12.30 [INFO]
#11 12.30 [INFO] Total time: 9.812 s
#11 12.30 [INFO] Finished at: 2023-06-12T11:09:09Z
#11 12.30 [INFO]
#11 12.30 [WARNING]
#11 12.30 [WARNING] Plugin validation issues were detected in 3 plugin(s)
#11 12.30 [WARNING]
#11 12.30 [WARNING] * org.openapitools:openapi-generator-maven-plugin:6.2.1
#11 12.30 [WARNING] * org.apache.maven.plugins:maven-compiler-plugin:3.10.1
#11 12.30 [WARNING] * org.apache.maven.plugins:maven-resources-plugin:3.3.0
#11 12.31 [WARNING]
#11 12.31 [WARNING] For more or less details, use 'maven.plugin.validation'
property with one of the values (case insensitive): [BRIEF, DEFAULT, VERBOSE]
#11 12.31 [WARNING]
#11 12.31 [ERROR] Could not acquire lock(s)
#11 12.31 java.lang.IllegalStateException: Could not acquire lock(s)
#11 12.31 at
org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
(NamedLockFactoryAdapter.java:219)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
(DefaultMetadataResolver.java:193)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
(DefaultMetadataResolver.java:179)
#11 12.31 at
org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion
(DefaultVersionResolver.java:196)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:331)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:260)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
(DefaultArtifactResolver.java:242)
#11 12.31 at
org.apache.maven.repository.internal.DefaultModelResolver.resolveModel
(DefaultModelResolver.java:158)
#11 12.31 at
org.apache.maven.repository.internal.DefaultModelResolver.resolveModel
(DefaultModelResolver.java:204)
#11 12.31 at
org.apache.maven.model.building.DefaultModelBuilder.readParentExternally
(DefaultModelBuilder.java:1009)
#11 12.31 at org.apache.maven.model.building.DefaultModelBuilder.readParent
(DefaultModelBuilder.java:801)
#11 12.31 at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:327)
#11 12.31 at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:243)
#11 12.31 at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom
(DefaultArtifactDescriptorReader.java:281)
#11 12.31 at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
(DefaultArtifactDescriptorReader.java:172)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor
(DfDependencyCollector.java:382)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult
(DfDependencyCollector.java:368)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency
(DfDependencyCollector.java:218)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency
(DfDependencyCollector.java:156)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process
(DfDependencyCollector.java:138)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies
(DfDependencyCollector.java:108)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies
(DependencyCollectorDelegate.java:222)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:87)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:305)
#11 12.31 at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
(DefaultProjectDependenciesResolver.java:151)
#11 12.31 at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
(LifecycleDependencyResolver.java:224)
#11 12.31 at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
(LifecycleDependencyResolver.java:136)
#11 12.31 at
[jira] [Commented] (MDEPLOY-306) [REGRESSION] Could not acquire write lock
[
https://issues.apache.org/jira/browse/MDEPLOY-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731568#comment-17731568
]
bendemctl commented on MDEPLOY-306:
---
I have the same error, but it doesn't happen in the deploy plugin, it happens
in the generic dependency resolution since we upgraded to maven 3.9.2.
Stacktrace :
{quote}#11 12.30 [INFO]
#11 12.30 [INFO] BUILD FAILURE
#11 12.30 [INFO]
#11 12.30 [INFO] Total time: 9.812 s
#11 12.30 [INFO] Finished at: 2023-06-12T11:09:09Z
#11 12.30 [INFO]
#11 12.30 [WARNING]
#11 12.30 [WARNING] Plugin validation issues were detected in 3 plugin(s)
#11 12.30 [WARNING]
#11 12.30 [WARNING] * org.openapitools:openapi-generator-maven-plugin:6.2.1
#11 12.30 [WARNING] * org.apache.maven.plugins:maven-compiler-plugin:3.10.1
#11 12.30 [WARNING] * org.apache.maven.plugins:maven-resources-plugin:3.3.0
#11 12.31 [WARNING]
#11 12.31 [WARNING] For more or less details, use 'maven.plugin.validation'
property with one of the values (case insensitive): [BRIEF, DEFAULT, VERBOSE]
#11 12.31 [WARNING]
#11 12.31 [ERROR] Could not acquire lock(s)
#11 12.31 java.lang.IllegalStateException: Could not acquire lock(s)
#11 12.31 at
org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
(NamedLockFactoryAdapter.java:219)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
(DefaultMetadataResolver.java:193)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
(DefaultMetadataResolver.java:179)
#11 12.31 at
org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion
(DefaultVersionResolver.java:196)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:331)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:260)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
(DefaultArtifactResolver.java:242)
#11 12.31 at
org.apache.maven.repository.internal.DefaultModelResolver.resolveModel
(DefaultModelResolver.java:158)
#11 12.31 at
org.apache.maven.repository.internal.DefaultModelResolver.resolveModel
(DefaultModelResolver.java:204)
#11 12.31 at
org.apache.maven.model.building.DefaultModelBuilder.readParentExternally
(DefaultModelBuilder.java:1009)
#11 12.31 at org.apache.maven.model.building.DefaultModelBuilder.readParent
(DefaultModelBuilder.java:801)
#11 12.31 at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:327)
#11 12.31 at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:243)
#11 12.31 at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom
(DefaultArtifactDescriptorReader.java:281)
#11 12.31 at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
(DefaultArtifactDescriptorReader.java:172)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor
(DfDependencyCollector.java:382)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult
(DfDependencyCollector.java:368)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency
(DfDependencyCollector.java:218)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency
(DfDependencyCollector.java:156)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process
(DfDependencyCollector.java:138)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies
(DfDependencyCollector.java:108)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies
(DependencyCollectorDelegate.java:222)
#11 12.31 at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:87)
#11 12.31 at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:305)
#11 12.31 at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
(DefaultProjectDependenciesResolver.java:151)
#11 12.31 at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
(LifecycleDependencyResolver.java:224)
#11 12.31 at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
[jira] [Commented] (MINVOKER-348) Build job report is truncated
[
https://issues.apache.org/jira/browse/MINVOKER-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731567#comment-17731567
]
Alvaro Sanchez-Mariscal commented on MINVOKER-348:
--
I debugged it and saw an {{IllegalStateException: character 27 is not allowed
in output}} being thrown, in case it helps.
> Build job report is truncated
> -
>
> Key: MINVOKER-348
> URL: https://issues.apache.org/jira/browse/MINVOKER-348
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 3.5.1
>Reporter: Alvaro Sanchez-Mariscal
>Priority: Major
> Attachments: BUILD-test-resources.xml, build.log
>
>
> The build-job.xml generated for a project is truncated:
> {code:xml}
>
> result="failure-post-hook" time="42.662"
> buildlog="/Users/alvaro/Dev/micronaut-projects/micronaut-maven-plugin/target/it/test-resources/build.log">
> Assertion failed:
> assert log.text.contains("BUILD SUCCESS")
>| ||
>| |false
>| '[INFO] Error stacktraces are turned on.\n[INFO] Scanning for
> projects...\n[WARNING] This build will only read from the build cache, since
> the clean lifecycle is not part of the build invocation.\n[INFO] \n[INFO]
> -
> {code}
> Examining the build output, it gets truncated after a {{<}} appears, which is
> replaced in the XML with {{}};, but then nothing else. Snippet following
> {noformat}
> [INFO] Error stacktraces are turned on.\n[INFO] Scanning for
> projects...\n[WARNING] This build will only read from the build cache, since
> the clean lifecycle is not part of the build invocation.\n[INFO] \n[INFO]
> -< io.micronaut.build.examples:test-resources
> >-\n[INFO]
> {noformat}
> Then, the verify mojo crashes when reading such file:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-invoker-plugin:3.5.1:verify (integration-test)
> on project micronaut-maven-integration-tests: Failed to read report file:
> /Users/alvaro/Dev/micronaut-projects/micronaut-maven-plugin/micronaut-maven-integration-tests/target/invoker-reports/BUILD-test-resources.xml:
> no more data available - expected end tags to
> close start tag from line 3 and start tag from
> line 2, parser stopped on START_TAG seen ...t part of the build
> invocation.\n[INFO] \n[INFO] -... @8:242 -> [Help 1]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINVOKER-348) Build job report is truncated
[
https://issues.apache.org/jira/browse/MINVOKER-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alvaro Sanchez-Mariscal updated MINVOKER-348:
-
Description:
The build-job.xml generated for a project is truncated:
{code:xml}
Assertion failed:
assert log.text.contains("BUILD SUCCESS")
| ||
| |false
| '[INFO] Error stacktraces are turned on.\n[INFO] Scanning for
projects...\n[WARNING] This build will only read from the build cache, since
the clean lifecycle is not part of the build invocation.\n[INFO] \n[INFO]
-
{code}
Examining the build output, it gets truncated after a {{<}} appears, which is
replaced in the XML with {{}};, but then nothing else. Snippet following
{noformat}
[INFO] Error stacktraces are turned on.\n[INFO] Scanning for
projects...\n[WARNING] This build will only read from the build cache, since
the clean lifecycle is not part of the build invocation.\n[INFO] \n[INFO]
-< io.micronaut.build.examples:test-resources >-\n[INFO]
{noformat}
Then, the verify mojo crashes when reading such file:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-invoker-plugin:3.5.1:verify (integration-test)
on project micronaut-maven-integration-tests: Failed to read report file:
/Users/alvaro/Dev/micronaut-projects/micronaut-maven-plugin/micronaut-maven-integration-tests/target/invoker-reports/BUILD-test-resources.xml:
no more data available - expected end tags to
close start tag from line 3 and start tag from
line 2, parser stopped on START_TAG seen ...t part of the build
invocation.\n[INFO] \n[INFO] -... @8:242 -> [Help 1]
{nofirmat}
was:
The build-job.xml generated for a project is truncated:
{code:xml}
Assertion failed:
assert log.text.contains("BUILD SUCCESS")
| ||
| |false
| '[INFO] Error stacktraces are turned on.\n[INFO] Scanning for
projects...\n[WARNING] This build will only read from the build cache, since
the clean lifecycle is not part of the build invocation.\n[INFO] \n[INFO]
-
{code}
Examining the build output, it gets truncated after a {{<}} appears, which is
replaced in the XML with {{& lt}}, but then nothing else. Snippet following
{noformat}
[INFO] Error stacktraces are turned on.\n[INFO] Scanning for
projects...\n[WARNING] This build will only read from the build cache, since
the clean lifecycle is not part of the build invocation.\n[INFO] \n[INFO]
-< io.micronaut.build.examples:test-resources >-\n[INFO]
{noformat}
Then, the verify mojo crashes when reading such file:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-invoker-plugin:3.5.1:verify (integration-test)
on project micronaut-maven-integration-tests: Failed to read report file:
/Users/alvaro/Dev/micronaut-projects/micronaut-maven-plugin/micronaut-maven-integration-tests/target/invoker-reports/BUILD-test-resources.xml:
no more data available - expected end tags to
close start tag from line 3 and start tag from
line 2, parser stopped on START_TAG seen ...t part of the build
invocation.\n[INFO] \n[INFO] -... @8:242 -> [Help 1]
{nofirmat}
> Build job report is truncated
> -
>
> Key: MINVOKER-348
> URL: https://issues.apache.org/jira/browse/MINVOKER-348
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 3.5.1
>Reporter: Alvaro Sanchez-Mariscal
>Priority: Major
> Attachments: BUILD-test-resources.xml, build.log
>
>
> The build-job.xml generated for a project is truncated:
> {code:xml}
>
> result="failure-post-hook" time="42.662"
> buildlog="/Users/alvaro/Dev/micronaut-projects/micronaut-maven-plugin/target/it/test-resources/build.log">
> Assertion failed:
> assert log.text.contains("BUILD SUCCESS")
>| ||
>| |false
>| '[INFO] Error stacktraces are turned on.\n[INFO] Scanning for
> projects...\n[WARNING] This build will only read from the build cache, since
> the clean lifecycle is not part of the build invocation.\n[INFO] \n[INFO]
> -
> {code}
> Examining the build output, it gets truncated after a {{<}} appears, which is
> replaced in the XML with {{}};, but then nothing else. Snippet following
> {noformat}
> [INFO] Error stacktraces are turned on.\n[INFO] Scanning for
> projects...\n[WARNING] This build will only read from the build cache, since
> the clean lifecycle is not part of the build invocation.\n[INFO] \n[INFO]
> -< io.micronaut.build.examples:test-resources
> >-\n[INFO]
> {noformat}
> Then, the verify mojo crashes when reading such file:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-invoker-plugin:3.5.1:verify (integration-test)
