[jira] [Comment Edited] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[
https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726719#comment-17726719
]
Marat Abrarov edited comment on MASSEMBLY-791 at 5/26/23 10:36 PM:
---
Hi [~elharo],
With 3.6.0 version of Maven Assembly Plugin {{fileMode}} and {{directoryMode}}
options look to be ignored or transformed (umask applied?). This is the reason
my team delays migration from 3.5.0 to 3.6.0 - we need to generate archives
with specific permissions, like 0777 for specific directory entry in the
generated TAR, but we get 0755 with 3.6.0.
Refer to
[init-image/src/assembly/rootfs.xml|https://github.com/mabrarov/docker-compose-init-container/blob/master/init-image/src/assembly/rootfs.xml]
in
[mabrarov/docker-compose-init-container|https://github.com/mabrarov/docker-compose-init-container]
for example:
{noformat}
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.5.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxrwxrwx root/root 0 1980-01-01 03:00 config/
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.6.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxr-xr-x root/root 0 1980-01-01 03:00 config/
{noformat}
Example of possible solution (of workaround):
[https://github.com/mabrarov/maven-assembly-plugin/compare/master...mabrarov:maven-assembly-plugin:feature/override_umask].
was (Author: abrarovm):
Hi [~elharo],
With 3.6.0 version of Maven Assembly Plugin {{fileMode}} and {{directoryMode}}
options look to be ignored or transformed (umask applied?). This is the reason
my team delays migration from 3.5.0 to 3.6.0 - we need to generate archives
with specific permissions, like 0777 for specific directory entry in the
generated TAR, but we get 0755 with 3.6.0.
Refer to
[init-image/src/assembly/rootfs.xml|https://github.com/mabrarov/docker-compose-init-container/blob/master/init-image/src/assembly/rootfs.xml]
in
[mabrarov/docker-compose-init-container|https://github.com/mabrarov/docker-compose-init-container]
for example:
{noformat}
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.5.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxrwxrwx root/root 0 1980-01-01 03:00 config/
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.6.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxr-xr-x root/root 0 1980-01-01 03:00 config/
{noformat}
> fileMode not set in dependencySet creating format tar.gz
>
>
> Key: MASSEMBLY-791
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-791
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: permissions
>Affects Versions: 2.6
> Environment: Linux and Windows
>Reporter: Rick Poleshuck
>Priority: Major
>
> The fileMode is ignored within a dependencySet while creating a tar.gz
> archive. This works just fine in 2.4.
>
>
>
> com.company:dependency-artifact
>
> true
>
>
> *.py
>
>
>
> 0750
> 0750
>
>
>
[GitHub] [maven-project-info-reports-plugin] elharo merged pull request #54: move dependencies to test scope
elharo merged PR #54: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/54 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[
https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726719#comment-17726719
]
Marat Abrarov edited comment on MASSEMBLY-791 at 5/26/23 9:40 PM:
--
Hi [~elharo],
With 3.6.0 version of Maven Assembly Plugin {{fileMode}} and {{directoryMode}}
options look to be ignored or transformed (umask applied?). This is the reason
my team delays migration from 3.5.0 to 3.6.0 - we need to generate archives
with specific permissions, like 0777 for specific directory entry in the
generated TAR, but we get 0755 with 3.6.0.
Refer to
[init-image/src/assembly/rootfs.xml|https://github.com/mabrarov/docker-compose-init-container/blob/master/init-image/src/assembly/rootfs.xml]
in
[mabrarov/docker-compose-init-container|https://github.com/mabrarov/docker-compose-init-container]
for example:
{noformat}
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.5.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxrwxrwx root/root 0 1980-01-01 03:00 config/
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.6.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxr-xr-x root/root 0 1980-01-01 03:00 config/
{noformat}
was (Author: abrarovm):
Hi [~elharo],
With 3.6.0 version of Maven Assembly Plugin {{fileMode}} and {{directoryMode}}
options look to be ignored or transformed (umask applied?). This is the reason
my team delays migration from 3.5.0 to 3.6.0 - we need to generate archives
with specific permissions, like 0777 for specific directory entry in the
generated TAR, but we get 0755 with 3.6.0.
> fileMode not set in dependencySet creating format tar.gz
>
>
> Key: MASSEMBLY-791
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-791
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: permissions
>Affects Versions: 2.6
> Environment: Linux and Windows
>Reporter: Rick Poleshuck
>Priority: Major
>
> The fileMode is ignored within a dependencySet while creating a tar.gz
> archive. This works just fine in 2.4.
>
>
>
> com.company:dependency-artifact
>
> true
>
>
> *.py
>
>
>
> 0750
> 0750
>
>
>
[jira] [Updated] (MNG-7797) Return BRIEF mode, simply map it onto SUMMARY
[ https://issues.apache.org/jira/browse/MNG-7797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7797: - Summary: Return BRIEF mode, simply map it onto SUMMARY (was: Return BRIEF mode, simple map it onto SUMMARY) > Return BRIEF mode, simply map it onto SUMMARY > - > > Key: MNG-7797 > URL: https://issues.apache.org/jira/browse/MNG-7797 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > The plugin validation report level "brief" was removed with MNG-7791 > Return it, as now it may break existing user configurations setting it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7797) Return BRIEF mode, simple map it onto SUMMARY
Tamas Cservenak created MNG-7797: Summary: Return BRIEF mode, simple map it onto SUMMARY Key: MNG-7797 URL: https://issues.apache.org/jira/browse/MNG-7797 Project: Maven Issue Type: Task Components: Plugins and Lifecycle Reporter: Tamas Cservenak Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 The plugin validation report level "brief" was removed with MNG-7791 Return it, as now it may break existing user configurations setting it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-project-info-reports-plugin] elharo opened a new pull request, #54: move dependencies to test scope
elharo opened a new pull request, #54: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/54 (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] [Created] (MPIR-439) Update commons-io to 3.12.0
Elliotte Rusty Harold created MPIR-439: -- Summary: Update commons-io to 3.12.0 Key: MPIR-439 URL: https://issues.apache.org/jira/browse/MPIR-439 Project: Maven Project Info Reports Plugin Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold Assignee: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPIR-440) Update maven-shared-utils to 3.4.2
Elliotte Rusty Harold created MPIR-440: -- Summary: Update maven-shared-utils to 3.4.2 Key: MPIR-440 URL: https://issues.apache.org/jira/browse/MPIR-440 Project: Maven Project Info Reports Plugin Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold Assignee: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[
https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726719#comment-17726719
]
Marat Abrarov commented on MASSEMBLY-791:
-
Hi [~elharo],
With 3.6.0 version of Maven Assembly Plugin {{fileMode}} and {{directoryMode}}
options look to be ignored or transformed (umask applied?). This is the reason
my team delays migration from 3.5.0 to 3.6.0 - we need to generate archives
with specific permissions, like 0777 for specific directory entry in the
generated TAR, but we get 0755 with 3.6.0.
> fileMode not set in dependencySet creating format tar.gz
>
>
> Key: MASSEMBLY-791
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-791
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: permissions
>Affects Versions: 2.6
> Environment: Linux and Windows
>Reporter: Rick Poleshuck
>Priority: Major
>
> The fileMode is ignored within a dependencySet while creating a tar.gz
> archive. This works just fine in 2.4.
>
>
>
> com.company:dependency-artifact
>
> true
>
>
> *.py
>
>
>
> 0750
> 0750
>
>
>
[GitHub] [maven] gnodet commented on pull request #1129: Automatic discovery of JDK Toolchains
gnodet commented on PR #1129: URL: https://github.com/apache/maven/pull/1129#issuecomment-1564819271 The PR https://github.com/apache/maven-toolchains-plugin/pull/14 provides a new mojo that displays the list of discovered toolchains. ``` ➜ maven git:(discover-toolchains) ✗ ~/work/git/maven/apache-maven/target/apache-maven-4.0.0-alpha-6-SNAPSHOT/bin/mvn org.apache.maven.plugins:maven-toolchains-plugin:4.0.0-SNAPSHOT:display-discovered-toolchains -N [INFO] Scanning for projects... [INFO] [INFO] < org.apache.maven:maven > [INFO] Building Apache Maven 4.0.0-alpha-6-SNAPSHOT [INFO] from pom.xml [INFO] -[ pom ]-- [INFO] [INFO] --- toolchains:4.0.0-SNAPSHOT:display-discovered-toolchains (default-cli) @ maven --- http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"; xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> jdk 1.8.0_372 OpenJDK Runtime Environment 1.8.0_372-b07 Azul Systems, Inc. /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre jdk 1.8.0_362 OpenJDK Runtime Environment 1.8.0_362-b09 BellSoft /Users/gnodet/.sdkman/candidates/java/8.0.362-librca/jre jdk 17.0.6 OpenJDK Runtime Environment 17.0.6+10 Eclipse Adoptium Temurin-17.0.6+10 /Users/gnodet/.sdkman/candidates/java/17.0.6-tem jdk 20 OpenJDK Runtime Environment 20+36 Eclipse Adoptium Temurin-20+36 /Users/gnodet/.sdkman/candidates/java/20-tem jdk 11.0.17 OpenJDK Runtime Environment 11.0.17+8-jvmci-22.3-b08 GraalVM Community GraalVM CE 22.3.0 /Users/gnodet/.sdkman/candidates/java/22.3.r11-grl jdk 11.0.18 OpenJDK Runtime Environment 11.0.18+10-jvmci-22.3-b13 GraalVM Community GraalVM CE 22.3.1 /Library/Java/JavaVirtualMachines/graalvm-ce-java11-22.3.1/Contents/Home jdk 17.0.5 OpenJDK Runtime Environment 17.0.5+8-jvmci-22.3-b08 GraalVM Community GraalVM CE 22.3.0 /Users/gnodet/.sdkman/candidates/java/22.3.r17-grl jdk 17.0.5 OpenJDK Runtime Environment 17.0.5+8-jvmci-22.3-b08 GraalVM Community GraalVM CE 22.3.0 /Users/gnodet/.sdkman/candidates/java/22.3.r17-grl jdk 17.0.6 OpenJDK Runtime Environment 17.0.6+10-jvmci-22.3-b13 GraalVM Community GraalVM CE 22.3.1 /Library/Java/JavaVirtualMachines/graalvm-ce-java17-22.3.1/Contents/Home jdk 17.0.6 OpenJDK Runtime Environment 17.0.6+10-jvmci-22.3-b13 GraalVM Community GraalVM CE 22.3.1 /Users/gnodet/.sdkman/candidates/java/22.3.1.r17-grl jdk 20-ea OpenJDK Runtime Environment 20-ea+24-1795 Oracle Corporation /Library/Java/JavaVirtualMachines/jdk-20.jdk/Contents/Home jdk 21-ea OpenJDK Runtime Environment 21-ea+22-1890 Oracle Corporation /Users/gnodet/.sdkman/candidates/java/21.ea.22-open [INFO] Copying org.apache.maven:maven:pom:4.0.0-alpha-6-SNAPSHOT to project local repository [INFO] Copying org.apache.maven:maven:pom:consumer:4.0.0-alpha-6-SNAPSHOT to project local repository [INFO] -- [INFO] BUILD SUCCESS [INFO] -- [INFO] Total time: 1.051 s [INFO] Finished at: 2023-05-26T21:07:20+02:00 [INFO] -- ➜ maven git:(discover-toolchains) ✗ ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and u
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726696#comment-17726696 ] Garret Wilson commented on MRESOLVER-363: - Természetesen! Egy sört kérek. 😂 (I sent you an email.) I'm heading to the gym before you convince me to have a beer already. Enjoy yours. > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726694#comment-17726694
]
Tamas Cservenak commented on MRESOLVER-363:
---
Re party: -I hand out- every guest can have a drink every 30 minutes. Whoever
gets a drink, gets a sticker to his forehead with TS when he got it...
* not present, I call you "get your a** here ASAP!"
* present, w/ sticker on your forehead, I turn you toward my wifey, she checks
the sticker, nods or nays ("give him a beer" or "no beer for him")
* present, w/o sticker on your forehead (it fell off as you dance a lot), I
grab an empty sticker, jot down Jan 1 1970 on it, stick it to your forehead and
turn you toward my...
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726692#comment-17726692 ] Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 5:25 PM: Ultimate point: we do have a policy, that is always consulted in both cases: * if we "have" a valid lastUpdate value, and * if we "don't have" (hence we use Jan 1, 1970 + 1ms) as value We do keep this value to consult the policy. And bad news for you: as it is past 19h here, I just popped a beer :) EDIT: looking forward for drinks, and have a nice weekend as well! (but push thru your Fri first) was (Author: cstamas): Ultimate point: we do have a policy, that is always consulted in both cases: * if we "have" a valid lastUpdate value, and * if we "don't have" (hence we use Jan 1, 1970 + 1ms) as value We do keep this value to consult the policy. And bad news for you: as it is past 19h here, I just popped a beer :) > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726692#comment-17726692 ] Tamas Cservenak commented on MRESOLVER-363: --- Ultimate point: we do have a policy, that is always consulted in both cases: * if we "have" a valid lastUpdate value, and * if we "don't have" (hence we use Jan 1, 1970 + 1ms) as value We do keep this value to consult the policy. And bad news for you: as it is past 19h here, I just popped a beer :) > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726690#comment-17726690
]
Garret Wilson commented on MRESOLVER-363:
-
{quote}If present, it means we have it (and checksums are hopefully according
to checksum policy validated), so we can continue the work.{quote}
… unless we are keeping some separate "last-updated" flag, and something about
the "last-updated" flag is fishy (or missing), which says, "uh, oh, we better
check on this"!
{quote}IF you are present, i will ask my wife "Did Garret got his drink in last
30 minutes?"{quote}
I think this is a good analogy, actually.
*If your wife doesn't know if Garret has had a drink in the last 30 minutes*,
do you assume that I've had my drink in the last 30 minutes (and you assume
that for the rest of the party, even if the party goes on all night), or do you
think "it's probably better to assume that Garret has not had a drink in the
last 30 minutes, and ask your wife to keep an eye out in the future"? I would
argue the latter is a better approach, and that was core of my question.
Anyway, I've just had breakfast, but that drink you mentioned is already
starting to sound good. 😅 haha I'll drop you a separate email about that. Have
a good weekend!
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726689#comment-17726689 ] Tamas Cservenak commented on MRESOLVER-363: --- Sorry, I misunderstood your question, ans answered it by editing my prev comment. Sorry again (and yes, it is Fri evening around here) > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726685#comment-17726685 ] Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 5:07 PM: Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1 millisecond (0 and 1 long values respectively) :) But none of those will update, if policy is "never", would not update even if TS would be 0BC, as long as policy in effect is "never". === EDIT: oh, sorry, I think I get it: so you ask why differentiate "not present" and "present, but no idea when arrived"? Well, If not present, we need to do something about it (grab it). If present, it means we have it (and checksums are hopefully according to checksum policy validated), so we can continue the work after we applied the "update policy". And we are back in philosophical topic: i have a party, am dealing out drinks every 30 minutes. You are invitee. IF you did not appear yet, I grab a phone, and call you. IF you are present, i will ask my wife "Did Garret got his drink in last 30 minutes?" was (Author: cstamas): Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1 millisecond (0 and 1 long values respectively) :) But none of those will update, if policy is "never", would not update even if TS would be 0BC, as long as policy in effect is "never". === EDIT: oh, sorry, I think I get it: so you ask why differentiate "not present" and "present, but no idea when arrived"? Well, If not present, we need to do something about it (grab it). If present, it means we have it (and checksums are hopefully according to checksum policy validated), so we can continue the work. And we are back in philosophical topic: i have a party, am dealing out drinks every 30 minutes. You are invitee. IF you did not appear yet, I grab a phone, and call you. IF you are present, i will ask my wife "Did Garret got his drink in last 30 minutes?" > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726685#comment-17726685 ] Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 5:07 PM: Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1 millisecond (0 and 1 long values respectively) :) But none of those will update, if policy is "never", would not update even if TS would be 0BC, as long as policy in effect is "never". === EDIT: oh, sorry, I think I get it: so you ask why differentiate "not present" and "present, but no idea when arrived"? Well, If not present, we need to do something about it (grab it). If present, it means we have it (and checksums are hopefully according to checksum policy validated), so we can continue the work. And we are back in philosophical topic: i have a party, am dealing out drinks every 30 minutes. You are invitee. IF you did not appear yet, I grab a phone, and call you. IF you are present, i will ask my wife "Did Garret got his drink in last 30 minutes?" was (Author: cstamas): Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1 millisecond (0 and 1 long values respectively) :) But none of those will update, if policy is "never", would not update even if TS would be 0BC, as long as policy in effect is "never". > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726687#comment-17726687
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 5:06 PM:
--
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
carving out certain valid values and giving them special semantics for return
codes).
Pretend my question said I'm asking what bad would happen if you return "*two
milliseconds past* January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
was (Author: garretwilson):
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
making carving out certain valid values and given them special semantics
"values with special meaning" for return codes).
Pretend my question said I'm asking what bad would happen if you return "*two
milliseconds past* January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726687#comment-17726687
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 5:07 PM:
--
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
carving out certain valid values and giving them special semantics for return
codes).
Pretend my question said I'm asking what bad would happen if you return "*two
milliseconds past* January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was first released, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
was (Author: garretwilson):
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
carving out certain valid values and giving them special semantics for return
codes).
Pretend my question said I'm asking what bad would happen if you return "*two
milliseconds past* January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726687#comment-17726687
]
Garret Wilson commented on MRESOLVER-363:
-
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
making carving out certain valid values and given them special semantics
"values with special meaning" for return codes).
Pretend my question said I'm asking what bad would happen if you return "**two
milliseconds past** January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726687#comment-17726687
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 5:05 PM:
--
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
making carving out certain valid values and given them special semantics
"values with special meaning" for return codes).
Pretend my question said I'm asking what bad would happen if you return "*two
milliseconds past* January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
was (Author: garretwilson):
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
making carving out certain valid values and given them special semantics
"values with special meaning" for return codes).
Pretend my question said I'm asking what bad would happen if you return "**two
milliseconds past** January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726685#comment-17726685 ] Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 5:01 PM: Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1 millisecond (0 and 1 long values respectively) :) But none of those will update, if policy is "never", would not update even if TS would be 0BC, as long as policy in effect is "never". was (Author: cstamas): Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1 millisecond (0 and 1 long values respectively) :) But none of those will update, if policy is "never", would not update even if TS would be 0BC, as policy is "never". > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726685#comment-17726685 ] Tamas Cservenak commented on MRESOLVER-363: --- Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1 millisecond (0 and 1 long values respectively) :) But none of those will update, if policy is "never", would not update even if TS would be 0BC, as policy is "never". > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726684#comment-17726684
]
Garret Wilson commented on MRESOLVER-363:
-
Look maybe I'm still not explaining my question well. I don't want to keep
insisting and make people irritated. I'll just live with {{-U}} for the moment,
and then you say that Versions Maven Plugin will have some changes that will
make {{-U}} not necessary. Great. Thanks for working on this.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726683#comment-17726683
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:55 PM:
--
{quote}2. that's exactly what happens (with a twist: file is not present -> go
grab it; file is present but no lastUpdated -> let policy decide)
{quote}
But you didn't answer my question. That's _not_ what happens today, because it
has the "twist" you mentioned.
You say you have this:
{quote}file is present but no lastUpdated -> let policy decide
{quote}
I am asking you very specifically: *What harm would come if we change it to the
following?*
_file is present but no lastUpdated -> default to a lastUpdated of January 1,
1970_
{quote}Also observe this UT, that would fail if in case TS_NEVER would be
returned instead of TS_UNKNOWN
{quote}
But I'm not proposing you return {{TS_NEVER}} instead of {{{}TS_UNKNOWN{}}}.
I'm asking what bad would happen if you return "January 1, 1970" instead of
{{{}TS_UNKNOWN{}}}?
was (Author: garretwilson):
{quote}2. that's exactly what happens (with a twist: file is not present -> go
grab it; file is present but no lastUpdated -> let policy decide){quote}
But you didn't answer my question. That's _not_ what happens today, because it
has the "twist" you mentioned.
You say you have this:
{quote}file is present but no lastUpdated -> let policy decide{quote}
I am asking you very specifically: **What harm would come if we change it to
the following?**
_file is present but no lastUpdated -> default to a lastUpdated of January 1,
1970_
{quote}Also observe this UT, that would fail if in case TS_NEVER would be
returned instead of TS_UNKNOWN{quote}
But I'm not proposing you return {{TS_NEVER}} instead of {{TS_UNKNOWN}}. I'm
asking what bad would happen if you return "January 1, 1970" instead of
{{TS_UNKNOWN}}?
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726683#comment-17726683
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:55 PM:
--
{quote}2. that's exactly what happens (with a twist: file is not present -> go
grab it; file is present but no lastUpdated -> let policy decide){quote}
But you didn't answer my question. That's _not_ what happens today, because it
has the "twist" you mentioned.
You say you have this:
{quote}file is present but no lastUpdated -> let policy decide{quote}
I am asking you very specifically: **What harm would come if we change it to
the following?**
_file is present but no lastUpdated -> default to a lastUpdated of January 1,
1970_
{quote}Also observe this UT, that would fail if in case TS_NEVER would be
returned instead of TS_UNKNOWN{quote}
But I'm not proposing you return {{TS_NEVER}} instead of {{TS_UNKNOWN}}. I'm
asking what bad would happen if you return "January 1, 1970" instead of
{{TS_UNKNOWN}}?
was (Author: garretwilson):
{quote}2. that's exactly what happens (with a twist: file is not present -> go
grab it; file is present but no lastUpdated -> let policy decide)\{quote}
But you didn't answer my question. That's _not_ what happens today, because it
has the "twist" you mentioned.
You say you have this:
{quote}file is present but no lastUpdated -> let policy decide{quote}
I am asking you very specifically: **What harm would come if we change it to
the following?**
_file is present but no lastUpdated -> default to a lastUpdated of January 1,
1970_
{quote}Also observe this UT, that would fail if in case TS_NEVER would be
returned instead of TS_UNKNOWN{quote}
But I'm not proposing you return {{TS_NEVER}} instead of {{TS_UNKNOWN}}. I'm
asking what bad would happen if you return "January 1, 1970" instead of
{{TS_UNKNOWN}}?
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726683#comment-17726683
]
Garret Wilson commented on MRESOLVER-363:
-
{quote}2. that's exactly what happens (with a twist: file is not present -> go
grab it; file is present but no lastUpdated -> let policy decide)\{quote}
But you didn't answer my question. That's _not_ what happens today, because it
has the "twist" you mentioned.
You say you have this:
{quote}file is present but no lastUpdated -> let policy decide{quote}
I am asking you very specifically: **What harm would come if we change it to
the following?**
_file is present but no lastUpdated -> default to a lastUpdated of January 1,
1970_
{quote}Also observe this UT, that would fail if in case TS_NEVER would be
returned instead of TS_UNKNOWN{quote}
But I'm not proposing you return {{TS_NEVER}} instead of {{TS_UNKNOWN}}. I'm
asking what bad would happen if you return "January 1, 1970" instead of
{{TS_UNKNOWN}}?
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726680#comment-17726680 ] Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 4:49 PM: 1. yes 2. that's exactly what happens (with a twist: file is not present -> go grab it; file is present but no lastUpdated -> let policy decide) (note: "file" here denotes artifact or metadata XML, while resolver-status.properties is like meta-metadata here, so existence is NOT about properties file but about payload downloaded from remote, the artifact or metadata XML) See this change from today https://github.com/apache/maven-resolver/commit/466f419fc80734252591a34f29a2fc500de8bff2 and related class. Also observe this UT, that would fail if in case TS_NEVER would be returned instead of TS_UNKNOWN https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManagerTest.java#L427 was (Author: cstamas): 1. yes 2. that's exactly what happens (with a twist: file is not present -> go grab it; file is present but no lastUpdated -> let policy decide) (note: "file" here denotes artifact or metadata XML, while resolver-status.properties is like meta-metadata here, so existence is NOT about properties file but about payload, the artifact or metadata XML) See this change from today https://github.com/apache/maven-resolver/commit/466f419fc80734252591a34f29a2fc500de8bff2 and related class. Also observe this UT, that would fail if in case TS_NEVER would be returned instead of TS_UNKNOWN https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManagerTest.java#L427 > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726680#comment-17726680 ] Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 4:48 PM: 1. yes 2. that's exactly what happens (with a twist: file is not present -> go grab it; file is present but no lastUpdated -> let policy decide) (note: "file" here denotes artifact or metadata XML, while resolver-status.properties is like meta-metadata here, so existence is NOT about properties file but about payload, the artifact or metadata XML) See this change from today https://github.com/apache/maven-resolver/commit/466f419fc80734252591a34f29a2fc500de8bff2 and related class. Also observe this UT, that would fail if in case TS_NEVER would be returned instead of TS_UNKNOWN https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManagerTest.java#L427 was (Author: cstamas): 1. yes 2. that's exactly what happens (with a twist: file is not present -> go grab it; file is present but no lastUpdated -> let policy decide) See this change from today https://github.com/apache/maven-resolver/commit/466f419fc80734252591a34f29a2fc500de8bff2 and related class. Also observe this UT, that would fail if in case TS_NEVER would be returned instead of TS_UNKNOWN https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManagerTest.java#L427 > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726680#comment-17726680 ] Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 4:46 PM: 1. yes 2. that's exactly what happens (with a twist: file is not present -> go grab it; file is present but no lastUpdated -> let policy decide) See this change from today https://github.com/apache/maven-resolver/commit/466f419fc80734252591a34f29a2fc500de8bff2 and related class. Also observe this UT, that would fail if in case TS_NEVER would be returned instead of TS_UNKNOWN https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManagerTest.java#L427 was (Author: cstamas): 1. yes 2. that's exactly what happens (with a twist: file is not present -> go grab it; file is present but no lastUpdated -> let policy decide) See this change from today https://github.com/apache/maven-resolver/commit/466f419fc80734252591a34f29a2fc500de8bff2 and related class. Also observe this UT, that would fail if in case of 2 TS_NEVER would be returned instead of TS_UNKNOWN https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManagerTest.java#L427 > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726680#comment-17726680 ] Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 4:45 PM: 1. yes 2. that's exactly what happens (with a twist: file is not present -> go grab it; file is present but no lastUpdated -> let policy decide) See this change from today https://github.com/apache/maven-resolver/commit/466f419fc80734252591a34f29a2fc500de8bff2 and related class. Also observe this UT, that would fail if in case of 2 TS_NEVER would be returned instead of TS_UNKNOWN https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManagerTest.java#L427 was (Author: cstamas): 1. yes 2. that's exactly what happens (with a twist: file is not present -> go grab it, file is present but no lastUpdated -> let policy decide) See this change from today https://github.com/apache/maven-resolver/commit/466f419fc80734252591a34f29a2fc500de8bff2 and related class. Also observe this UT, that would fail if in case of 2 TS_NEVER would be returned instead of TS_UNKNOWN https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManagerTest.java#L427 > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726680#comment-17726680 ] Tamas Cservenak commented on MRESOLVER-363: --- 1. yes 2. that's exactly what happens (with a twist: file is not present -> go grab it, file is present but no lastUpdated -> let policy decide) See this change from today https://github.com/apache/maven-resolver/commit/466f419fc80734252591a34f29a2fc500de8bff2 and related class. Also observe this UT, that would fail if in case of 2 TS_NEVER would be returned instead of TS_UNKNOWN https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManagerTest.java#L427 > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7792) Use a single standalone version of asm
[ https://issues.apache.org/jira/browse/MNG-7792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726677#comment-17726677 ] ASF GitHub Bot commented on MNG-7792: - cstamas commented on PR #1126: URL: https://github.com/apache/maven/pull/1126#issuecomment-1564650168 Hm, locally ITs pass on me, unsure why they failed here. > Use a single standalone version of asm > -- > > Key: MNG-7792 > URL: https://issues.apache.org/jira/browse/MNG-7792 > Project: Maven > Issue Type: Improvement >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.x-candidate > > > Guice and sisu.inject both embeds asm. It would be better to use an external > version so that it can be update independently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] cstamas commented on pull request #1126: [MNG-7792] Use a standalone asm version
cstamas commented on PR #1126: URL: https://github.com/apache/maven/pull/1126#issuecomment-1564650168 Hm, locally ITs pass on me, unsure why they failed here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:31 PM:
--
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "update policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider a
"last-updated" timestamp value in {{{}resolver-status.properties{}}}? (I'm not
asking you what that situation is, because it gets into a long discussion about
things that I'm still not understanding.) I'm trying to simplify this: {*}is
there ever a situation, yes or no{*}, in which it is valid for Maven to look
for and use a "last-updated" value in {{{}resolver-status.properties{}}}? (I
added bold only to be clear about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated value in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" value in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
was (Author: garretwilson):
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider a
"last-updated" timestamp value in {{{}resolver-status.properties{}}}? (I'm not
asking you what that situation is, because it gets into a long discussion about
things that I'm still not understanding.) I'm trying to simplify this: {*}is
there ever a situation, yes or no{*}, in which it is valid for Maven to look
for and use a "last-updated" value in {{{}resolver-status.properties{}}}? (I
added bold only to be clear about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated value in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" value in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:29 PM:
--
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider a
"last-updated" timestamp value in {{{}resolver-status.properties{}}}? (I'm not
asking you what that situation is, because it gets into a long discussion about
things that I'm still not understanding.) I'm trying to simplify this: {*}is
there ever a situation, yes or no{*}, in which it is valid for Maven to look
for and use a "last-updated" value in {{{}resolver-status.properties{}}}? (I
added bold only to be clear about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" value in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
was (Author: garretwilson):
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider
{{{}resolver-status.properties{}}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: {*}is there ever a situation, yes
or no{*}, in which it is valid for Maven to look for and use a "last-updated"
flag in {{{}resolver-status.properties{}}}? (I added bold only to be clear
about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:29 PM:
--
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider a
"last-updated" timestamp value in {{{}resolver-status.properties{}}}? (I'm not
asking you what that situation is, because it gets into a long discussion about
things that I'm still not understanding.) I'm trying to simplify this: {*}is
there ever a situation, yes or no{*}, in which it is valid for Maven to look
for and use a "last-updated" value in {{{}resolver-status.properties{}}}? (I
added bold only to be clear about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated value in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" value in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
was (Author: garretwilson):
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider a
"last-updated" timestamp value in {{{}resolver-status.properties{}}}? (I'm not
asking you what that situation is, because it gets into a long discussion about
things that I'm still not understanding.) I'm trying to simplify this: {*}is
there ever a situation, yes or no{*}, in which it is valid for Maven to look
for and use a "last-updated" value in {{{}resolver-status.properties{}}}? (I
added bold only to be clear about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" value in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7791) Split validation issues into "user actionable" and "plugin dev actionable"
[ https://issues.apache.org/jira/browse/MNG-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-7791. Resolution: Fixed master https://github.com/apache/maven/commit/46807790f6da3b872b4b6a0c51890610fcba2fe7 maven-3.9.x https://github.com/apache/maven/commit/39dd668adfa90b14a40ba58ec63f757c92e002e4 > Split validation issues into "user actionable" and "plugin dev actionable" > -- > > Key: MNG-7791 > URL: https://issues.apache.org/jira/browse/MNG-7791 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > And handle them differently (report). > As for first, user can fix them, while for the second it is maybe not fixable > (by user getting warnings). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:22 PM:
--
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider
{{{}resolver-status.properties{}}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: {*}is there ever a situation, yes
or no{*}, in which it is valid for Maven to look for and use a "last-updated"
flag in {{{}resolver-status.properties{}}}? (I added bold only to be clear
about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
was (Author: garretwilson):
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider
{{{}resolver-status.properties{}}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: {*}is there ever a situation, yes
or no{*}, in which it is valid for Maven to look for and use a "last-updated"
flag in {{{}resolver-status.properties{}}}? (I added bold only to be clear
about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1900? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7791) Split validation issues into "user actionable" and "plugin dev actionable"
[ https://issues.apache.org/jira/browse/MNG-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726675#comment-17726675 ] ASF GitHub Bot commented on MNG-7791: - cstamas merged PR #1122: URL: https://github.com/apache/maven/pull/1122 > Split validation issues into "user actionable" and "plugin dev actionable" > -- > > Key: MNG-7791 > URL: https://issues.apache.org/jira/browse/MNG-7791 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > And handle them differently (report). > As for first, user can fix them, while for the second it is maybe not fixable > (by user getting warnings). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] cstamas merged pull request #1122: [MNG-7791] Split validation issues by "locality" aspect
cstamas merged PR #1122: URL: https://github.com/apache/maven/pull/1122 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:18 PM:
--
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider
{{{}resolver-status.properties{}}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: {*}is there ever a situation, yes
or no{*}, in which it is valid for Maven to look for and use a "last-updated"
flag in {{{}resolver-status.properties{}}}? (I added bold only to be clear
about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1900? *What harm would come from this?*
was (Author: garretwilson):
I understood and agree with most everything you said in the previous question,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon _current Maven functionality_:
1. Is there ever a situation in which it is valid for Maven to consider
{{resolver-status.properties}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: *is there ever a situation, yes or
no*, in which it is valid for Maven to look for and use a "last-updated" flag
in {{resolver-status.properties}}? (I added bold only to be clear about what
question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{resolver-status.properties}}", my
second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{resolver-status.properties}}, to default to some "last-updated" date in the
past such as January 1, 1900? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson commented on MRESOLVER-363:
-
I understood and agree with most everything you said in the previous question,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon _current Maven functionality_:
1. Is there ever a situation in which it is valid for Maven to consider
{{resolver-status.properties}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: *is there ever a situation, yes or
no*, in which it is valid for Maven to look for and use a "last-updated" flag
in {{resolver-status.properties}}? (I added bold only to be clear about what
question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{resolver-status.properties}}", my
second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{resolver-status.properties}}, to default to some "last-updated" date in the
past such as January 1, 1900? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726668#comment-17726668
]
Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 4:11 PM:
Again, the problem you are facing is Maven default policy. You can change it
using your own {{~/.m2/settings.xml}} or using {{-U}} per invocation for start.
Second, versions upcoming release will contain a change that IN CASE of
"display xxx updates" and similar goals it overrides the (most probably
default) policy to "daily".
Second, in maveniverse, release artifacts are immutable (byte wise, so you once
download org:lib:1.0, it will NEVER change, nor in your local repo nor
remotely). Then, release repositories "only go forward", meaning, org:lib:1.0
once deployed, is there to stay forever, not change, only new versions (but
then we already talk about "other" artifact, it is not "same" as org:lib:1.0)
may be deployed tomorrow or after, like org:lib:1.1 or org:lib:2.0 etc. These
are long time ago established Maven fundamentals.
Second, Maven looks "your" aspect (the POM), not "remote repo" aspect. During a
build, Maven will not go "hey, look, there is a new version of this and this
over there!", it instead takes your POM and builds it. And in POM there are no
uncertainties, you tell exact GAV for plugins, dependencies, etc. So it is
you, that are telling maven what artifact to pick up. Maven does not tinker
about anything. And hence, maven is able to go directly for referenced artifact.
versions plugin is not build plugin, it is a handy "helper" plugin that helps
you keep your build and dependencies up to date. And it uses aspect of resolver
that Maven does NOT use. Still, resolver, that is configured by Maven, tries
it's best to deliver the expected. And due defaults, people used to invoke
{{mvn -U versions:display...}}. But again, all this is about to change in
latest versions plugin release (will make {{-U}} not needed).
Local repository is a badly named cache. It is a cache. It holds two kinds of
things: locally built and installed (to be able to share them "across
sessions", or in plain words, across invocation between different projects),
and remotely fetched ones. Local repository does not have "update policy", it
is remote repository (from which files are downloaded and cached to local
repository) having that attribute.
The properties file is there as metadata IS updated, when asked for, based on
update policy.
was (Author: cstamas):
Again, the problem you are facing is Maven default policy. You can change it
using your own {{~/.m2/settings.xml}} for start. Second, versions upcoming
release will contain a change that IN CASE of "display xxx updates" and similar
goals it overrides the (most probably default) policy to "daily".
Second, in maveniverse, release artifacts are immutable (byte wise, so you once
download org:lib:1.0, it will NEVER change, nor in your local repo nor
remotely). Then, release repositories "only go forward", meaning, org:lib:1.0
once deployed, is there to stay forever, not change, only new versions (but
then we already talk about "other" artifact, it is not "same" as org:lib:1.0)
may be deployed tomorrow or after, like org:lib:1.1 or org:lib:2.0 etc. These
are long time ago established Maven fundamentals.
Second, Maven looks "your" aspect (the POM), not "remote repo" aspect. During a
build, Maven will not go "hey, look, there is a new version of this and this
over there!", it instead takes your POM and builds it. And in POM there are no
uncertainties, you tell exact GAV for plugins, dependencies, etc. So it is
you, that are telling maven what artifact to pick up. Maven does not tinker
about anything. And hence, maven is able to go directly for referenced artifact.
versions plugin is not build plugin, it is a handy "helper" plugin that helps
you keep your build and dependencies up to date. And it uses aspect of resolver
that Maven does NOT use. Still, resolver, that is configured by Maven, tries
it's best to deliver the expected. And due defaults, people used to invoke
{{mvn -U versions:display...}}. But again, all this is about to change in
latest versions plugin release (will make {{-U}} not needed).
Local repository is a badly named cache. It is a cache. It holds two kinds of
things: locally built and installed (to be able to share them "across
sessions", or in plain words, across invocation between different projects),
and remotely fetched ones. Local repository does not have "update policy", it
is remote repository (from which files are downloaded and cached to local
repository) having that attribute.
The properties file is there as metadata IS updated, when asked for, based on
update policy.
> Maven metadata is not updated in some cases
> ---
>
>
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726668#comment-17726668
]
Tamas Cservenak commented on MRESOLVER-363:
---
Again, the problem you are facing is Maven default policy. You can change it
using your own {{~/.m2/settings.xml}} for start. Second, versions upcoming
release will contain a change that IN CASE of "display xxx updates" and similar
goals it overrides the (most probably default) policy to "daily".
Second, in maveniverse, release artifacts are immutable (byte wise, so you once
download org:lib:1.0, it will NEVER change, nor in your local repo nor
remotely). Then, release repositories "only go forward", meaning, org:lib:1.0
once deployed, is there to stay forever, not change, only new versions (but
then we already talk about "other" artifact, it is not "same" as org:lib:1.0)
may be deployed tomorrow or after, like org:lib:1.1 or org:lib:2.0 etc. These
are long time ago established Maven fundamentals.
Second, Maven looks "your" aspect (the POM), not "remote repo" aspect. During a
build, Maven will not go "hey, look, there is a new version of this and this
over there!", it instead takes your POM and builds it. And in POM there are no
uncertainties, you tell exact GAV for plugins, dependencies, etc. So it is
you, that are telling maven what artifact to pick up. Maven does not tinker
about anything. And hence, maven is able to go directly for referenced artifact.
versions plugin is not build plugin, it is a handy "helper" plugin that helps
you keep your build and dependencies up to date. And it uses aspect of resolver
that Maven does NOT use. Still, resolver, that is configured by Maven, tries
it's best to deliver the expected. And due defaults, people used to invoke
{{mvn -U versions:display...}}. But again, all this is about to change in
latest versions plugin release (will make {{-U}} not needed).
Local repository is a badly named cache. It is a cache. It holds two kinds of
things: locally built and installed (to be able to share them "across
sessions", or in plain words, across invocation between different projects),
and remotely fetched ones. Local repository does not have "update policy", it
is remote repository (from which files are downloaded and cached to local
repository) having that attribute.
The properties file is there as metadata IS updated, when asked for, based on
update policy.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726665#comment-17726665
]
Garret Wilson commented on MRESOLVER-363:
-
{quote}How is this difficult to resolve? If we update Maven's behavior so that
if resolver-status.properties is missing (or does not have the correct
"last-updated" flag), then instead of doing nothing, Maven proceeds as if the
"last-updated" value is January 1, 1970. Everything works as before if
"last-updated" is present. If not, then the Versions Maven Plugin related bug
is fixed and going forward there will be a "last-updated" flag. It's probably a
single line of code (not counting brackets). What is the downside?{quote}
In fact, if you agree to at least _consider_ this approach, assign it to me and
I'll be happy to look into it and file a pull request if it works out. Checking
for files and defaulting values and such is something I do day-in and day-out,
so it's right up my alley. I can't imagine this could be too difficult. Just
find out where it's looking for the {{resolver-status.properties}} file, and
add an {{else}} to the "property not found" part. But only if you would
consider it; I don't want to do it if it's out of the question to be accepted.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726664#comment-17726664
]
Garret Wilson commented on MRESOLVER-363:
-
{quote}Maven - out of the box (when user does not customize anything), the
default update policy for **RELEASE** repositories is **never**. It is exactly
due immutability (of releases), nothing is updated unless you say so.{quote}
This still doesn't make sense to me. Indicating that something that is a
"release" repository means _the artifacts within it will never change_, i.e.
they will all be non-SNAPSHOT versions. To me it does not mean that _the
repository itself will never change_. And it definitely doesn't mean _no one
will ever add things to the repository_. In fact the idea of a "repository that
can never be updated" makes no sense to me; the whole point of a repository is
that you add more versions to it as more versions are available. I can see that
in e.g. a security context you might want to make a repository as read-only,
but _you might want to do that with a non-release, snapshot repository as
well_. So it seems to me they are orthogonal concepts.
And even if I accept the idea that a "release" repository means it is
immutable, are we designating the machine's local repository in
{{~/.m2/repository}} as a "release", immutable repository? But doesn't Maven
keep {{-SNAPSHOT}} artifacts in it as well? So we are using a "release"
repository to store snapshots? None of this make sense to me.
{quote}maven never "sync to server", Maven does what you tell it to do via POM
(you enlist all the versions).{quote}
So why does Maven even have a {{resolver-status.properties}} if it never "syncs
to the server"? Why would a "last-updated" matter?
{quote}You are mixing in things with one specific plugin and it's goal: the
versions plugin.{quote}
But Versions Maven Plugin is working now if {{resolver-status.properties}} has
its "last updated" flag correctly! It only fails if this is missing. (And I've
explained above why this approach guarantees incorrect behavior.)
How is this difficult to resolve? If we update Maven's behavior so that if
{{resolver-status.properties}} is missing (or does not have the correct
"last-updated" flag), then instead of doing nothing, Maven proceeds as if the
"last-updated" value is January 1, 1970. Everything works as before if
"last-updated" is present. If not, then the Versions Maven Plugin related bug
is fixed and going forward there will be a "last-updated" flag. It's probably a
single line of code (not counting brackets). What is the downside?
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726654#comment-17726654
]
Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 3:12 PM:
So, we have several things in play:
Maven - out of the box (when user does not customize anything), the default
update policy for *RELEASE* repositories is *never*. It is exactly due
immutability (of releases), nothing is updated unless you say so.
Have to note two things: we are talking about release repositories and their
use in POMs: you usually "address" a release artifact by G:A:V where V is some
version. The support from Maven2 times where "LATEST" or "RELEASE" was
supported is gone. Hence, Maven when collects project dependencies (actually
this is true for plugins and plugin dependencies) it goes *directly* for
artifact, it does not even download metadata to "discover existing versions".
You are mixing in things with one specific plugin and it's goal: the versions
plugin. Versions plugin allows you to automate (well, get a report of) plugin
updates. But to produce this report, plugins asks resolver to list versions.
And for that, the metadata is used. Use case used by versions plugins is
"discover versions", and that use case does require metadata (that as you saw,
enlists "existing versions"). I have to repeat, "everyday" Maven does NOT use
this metadata at all... easy to check: perform a simple build with empty local
repository, and look into local repository: how many GA level maven metadata
will you find there? (and repeat and emphasize, we talk about release remote
repositories, for snapshots things are a bit different)
Still, plugin runs within maven, that configures resolver (based on user
configuration or defaults).
Hence, we can argue is maven out of the box default configuration sane (it is
cautious at least, for exact reasons you brought up) or not, but one thing
sure: the code works as expected :)
So to recap:
* maven-metadata.xml is not an artifact (so also not "Versioned artifact"), it
is metadata (completely different beast), that is UNUSED by Maven core in
"everyday" operation.
* maven never "sync to server", Maven does what you tell it to do via POM (you
enlist all the versions).
* versions plugin DOES want GA level metadata, but due Maven def config, may
miss to update it. Hence, configure maven as you wish, or use (brutal but
effective) {{-U}}, or wait for latest release of versions plugin that will
override Policy to "daily" in case of update checks.
was (Author: cstamas):
So, we have several things in play:
Maven - out of the box (when user does not customize anything), the default
update policy for *RELEASE* repositories is *never*. It is exactly due
immutability (of releases), nothing is updated unless you say so.
Have to note two things: we are talking about release repositories and their
use in POMs: you usually "address" a release artifact by G:A:V where V is some
version. The support from Maven2 times where "LATEST" or "RELEASE" was
supported is gone. Hence, Maven when collects project dependencies (actually
this is true for plugins and plugin dependencies) it goes *directly* for
artifact, it does not even download metadata to "discover existing versions".
You are mixing in things with one specific plugin and it's goal: the versions
plugin. Versions plugin allows you to automate (well, get a report of) plugin
updates. But to produce this report, plugins asks resolver to list versions.
And for that, the metadata is used. Use case used by versions plugins is
"discover versions", and that use case does require metadata (that as you saw,
enlists "existing versions"). I have to repeat, "everyday" Maven does NOT use
this metadata at all... easy to check: perform a simple build with empty local
repository, and look into local repository: how many GA level maven metadata
will you find there? (and repeat and emphasize, we talk about release remote
repositories, for snapshots things are a bit different)
Still, plugin runs within maven, that configures resolver (based on user
configuration or defaults).
Hence, we can argue is maven out of the box default configuration sane (it is
cautious at least, for exact reasons you brought up) or not, but one thing
sure: the code works as expected :)
So to recap:
* maven-metadata.xml is not an artifact (so also not "Versioned artifact"), it
is metadata (completely different beast), that is UNUSED by Maven core in
"everyday" operation.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726654#comment-17726654 ] Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 3:10 PM: So, we have several things in play: Maven - out of the box (when user does not customize anything), the default update policy for *RELEASE* repositories is *never*. It is exactly due immutability (of releases), nothing is updated unless you say so. Have to note two things: we are talking about release repositories and their use in POMs: you usually "address" a release artifact by G:A:V where V is some version. The support from Maven2 times where "LATEST" or "RELEASE" was supported is gone. Hence, Maven when collects project dependencies (actually this is true for plugins and plugin dependencies) it goes *directly* for artifact, it does not even download metadata to "discover existing versions". You are mixing in things with one specific plugin and it's goal: the versions plugin. Versions plugin allows you to automate (well, get a report of) plugin updates. But to produce this report, plugins asks resolver to list versions. And for that, the metadata is used. Use case used by versions plugins is "discover versions", and that use case does require metadata (that as you saw, enlists "existing versions"). I have to repeat, "everyday" Maven does NOT use this metadata at all... easy to check: perform a simple build with empty local repository, and look into local repository: how many GA level maven metadata will you find there? (and repeat and emphasize, we talk about release remote repositories, for snapshots things are a bit different) Still, plugin runs within maven, that configures resolver (based on user configuration or defaults). Hence, we can argue is maven out of the box default configuration sane (it is cautious at least, for exact reasons you brought up) or not, but one thing sure: the code works as expected :) So to recap: * maven-metadata.xml is not an artifact (so also not "Versioned artifact"), it is metadata (completely different beast), that is UNUSED by Maven core in "everyday" operation. was (Author: cstamas): So, we have several things in play: Maven - out of the box (when user does not customize anything), the default update policy for *RELEASE* repositories is *never*. It is exactly due immutability (of releases), nothing is updated unless you say so. Have to note two things: we are talking about release repositories and their use in POMs: you usually "address" a release artifact by G:A:V where V is some version. The support from Maven2 times where "LATEST" or "RELEASE" was supported is gone. Hence, Maven when collects project dependencies (actually this is true for plugins and plugin dependencies) it goes *directly* for artifact, it does not even download metadata to "discover existing versions". You are mixing in things with one specific plugin and it's goal: the versions plugin. Versions plugin allows you to automate (well, get a report of) plugin updates. But to produce this report, plugins asks resolver to list versions. And for that, the metadata is used. Use case used by versions plugins is "discover versions", and that use case does require metadata (that as you saw, enlists "existing versions"). I have to repeat, "everyday" Maven does NOT use this metadata at all... easy to check: perform a simple build with empty local repository, and look into local repository: how many GA level maven metadata will you find there? (and repeat and emphasize, we talk about release remote repositories, for snapshots things are a bit different) Still, plugin runs within maven, that configures resolver (based on user configuration or defaults). Hence, we can argue is maven out of the box default configuration sane (it is cautious at least, for exact reasons you brought up) or not, but one thing sure: the code works as expected :) > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726654#comment-17726654 ] Tamas Cservenak commented on MRESOLVER-363: --- So, we have several things in play: Maven - out of the box (when user does not customize anything), the default update policy for *RELEASE* repositories is *never*. It is exactly due immutability (of releases), nothing is updated unless you say so. Have to note two things: we are talking about release repositories and their use in POMs: you usually "address" a release artifact by G:A:V where V is some version. The support from Maven2 times where "LATEST" or "RELEASE" was supported is gone. Hence, Maven when collects project dependencies (actually this is true for plugins and plugin dependencies) it goes *directly* for artifact, it does not even download metadata to "discover existing versions". You are mixing in things with one specific plugin and it's goal: the versions plugin. Versions plugin allows you to automate (well, get a report of) plugin updates. But to produce this report, plugins asks resolver to list versions. And for that, the metadata is used. Use case used by versions plugins is "discover versions", and that use case does require metadata (that as you saw, enlists "existing versions"). I have to repeat, "everyday" Maven does NOT use this metadata at all... easy to check: perform a simple build with empty local repository, and look into local repository: how many GA level maven metadata will you find there? (and repeat and emphasize, we talk about release remote repositories, for snapshots things are a bit different) Still, plugin runs within maven, that configures resolver (based on user configuration or defaults). Hence, we can argue is maven out of the box default configuration sane (it is cautious at least, for exact reasons you brought up) or not, but one thing sure: the code works as expected :) > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726644#comment-17726644
]
Garret Wilson commented on MRESOLVER-363:
-
Good morning. There are two big things I don't understand about this behavior:
1.
Modern build systems has the beautiful concept of an immutable, repeatable
build. If an artifact is versioned, then once you have an artifact with a
version, you know that it's the latest, so there is no point in ever updating
it. In fact you _shouldn't_ (unless there was some error in the process, in
which case you can override it to fix the error). Everything I'm saying here
you already know and could recite in your sleep I'm sure.
But {{maven-metadata-central.xml}} is not a versioned artifact. It has no
version. We _know_ that we may update this artifact–in fact no only that we
"may" update the artifact, we know that _we probably will_ update this
artifact. The whole purpose of this artifact is to _track the changing state of
the server_. It is like {{HEAD}} in get. {{HEAD}} is not immutable. It simply
tells us whether we're in sync with the server or not. It is very closely
analogous to a {{-SNAPSHOT}} version. In fact it is a "shapshot" of the server.
_It is not a versioned artifact._
So why on earth would {{maven-metadata-central.xml}} have a policy of "never
update"? How could that ever be even close to correct? It's not versioned. It's
purpose is not to track some finalized state; it's purpose is rather to track
the synchronization state of _things that are always changing_. Could you
imagine putting a "never update" policy on Git {{HEAD}}? I'm not understanding
the reasoning here.
2.
Orthogonally, the current behavior is _not_ to update the metadata if
{{resolver-status.properties}} is missing (or does not have the expected "last
updated" information). This also doesn't make sense to me. When I am writing
software that synchronizes with a server, if the "last-updated" flag is
missing, the reasonable action to me is to synchronize (because we don't know
when it was last updated) and then update the "last-updated" flag so we'll know
in the future. I don't see any benefits to the approach of, "if we don't know
when we last updated, assume that we last updated recently".
In fact this approach is demonstrably incorrect, because if you wait long
enough, the behavior is guaranteed to be wrong. Assume that we only need to
update once every 1 year. If the "last-updated" flag is missing, the current
approach assumes that it has been updated less a year ago. And for a while that
will be correct. But eventually that will be wrong; eventually more than one
year will have past, so the assumption will be wrong. The point is that this
approach guarantees that _eventually the behavior will always be incorrect_.
Even if you only want to refresh after 100 years. Even if you put 1000 years.
If the software assumes that everything is up-to-date when the "last-updated"
flag is missing, then that approach _guarantees_ incorrect behavior eventually.
A better approach is to update the file and set the "last-updated" flag if the
"last-updated" flag is missing. This may at most result in a single "extra"
update, but that is benign, and going forward it will function correctly.
Taking the other approach _guarantees_ incorrect behavior forever, for hundreds
and thousands of years.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-361) Unreliable TCP and retries on upload
[ https://issues.apache.org/jira/browse/MRESOLVER-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726643#comment-17726643 ] ASF GitHub Bot commented on MRESOLVER-361: -- cstamas commented on PR #288: URL: https://github.com/apache/maven-resolver/pull/288#issuecomment-156450 No idea, but presence of these options allows to make resolver work "as before". Just an escape hatch, nothing more. > Unreliable TCP and retries on upload > > > Key: MRESOLVER-361 > URL: https://issues.apache.org/jira/browse/MRESOLVER-361 > Project: Maven Resolver > Issue Type: Bug >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)
[GitHub] [maven-resolver] cstamas commented on pull request #288: [MRESOLVER-361] Unreliable TCP and retries
cstamas commented on PR #288: URL: https://github.com/apache/maven-resolver/pull/288#issuecomment-156450 No idea, but presence of these options allows to make resolver work "as before". Just an escape hatch, nothing more. -- 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-361) Unreliable TCP and retries on upload
[ https://issues.apache.org/jira/browse/MRESOLVER-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726642#comment-17726642 ] ASF GitHub Bot commented on MRESOLVER-361: -- Eh2406 commented on PR #288: URL: https://github.com/apache/maven-resolver/pull/288#issuecomment-1564498299 Under what circumstances would a user want the standard retry handler? > Unreliable TCP and retries on upload > > > Key: MRESOLVER-361 > URL: https://issues.apache.org/jira/browse/MRESOLVER-361 > Project: Maven Resolver > Issue Type: Bug >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)
[GitHub] [maven-antrun-plugin] dependabot[bot] opened a new pull request, #81: Bump ant from 1.10.12 to 1.10.13
dependabot[bot] opened a new pull request, #81: URL: https://github.com/apache/maven-antrun-plugin/pull/81 Bumps ant from 1.10.12 to 1.10.13. [](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
[GitHub] [maven-site] cstamas opened a new pull request, #424: Maven 3.9.3 Release notes
cstamas opened a new pull request, #424: URL: https://github.com/apache/maven-site/pull/424 WIP -- 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-7771) Don't use ArtifactResolutionException#getMessage() w/o knowing whether there are other exceptions or not
[
https://issues.apache.org/jira/browse/MNG-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7771:
---
Assignee: (was: Michael Osipov)
> Don't use ArtifactResolutionException#getMessage() w/o knowing whether there
> are other exceptions or not
>
>
> Key: MNG-7771
> URL: https://issues.apache.org/jira/browse/MNG-7771
> Project: Maven
> Issue Type: Sub-task
>Affects Versions: 3.8.8, 3.9.1, 4.0.0-alpha-5
>Reporter: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.x-candidate, 4.0.x-candidate
>
>
> {{ArtifactResolutionException#getMessage()}} only considers the message from
> the first cause, completely ignoring other causes. So it is order-dependent
> and can be misleading. Create an expeception-agnotic message and all
> submessages shall be retrieved through API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7770) Implement workaround for MNG-7758/MRESOLVER-335
[ https://issues.apache.org/jira/browse/MNG-7770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MNG-7770: --- Assignee: (was: Michael Osipov) > Implement workaround for MNG-7758/MRESOLVER-335 > --- > > Key: MNG-7770 > URL: https://issues.apache.org/jira/browse/MNG-7770 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.8.8, 3.9.1, 4.0.0-alpha-5 >Reporter: Michael Osipov >Priority: Major > Fix For: 3.8.x-candidate, 3.9.x-candidate, 4.0.x-candidate > > > Details see tickets. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPIR-431) Dependency file details section: segregate Java version column into execution and test versions
[ https://issues.apache.org/jira/browse/MPIR-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726623#comment-17726623 ] ASF GitHub Bot commented on MPIR-431: - dependabot[bot] opened a new pull request, #53: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/53 Bumps commons-io from 1.0 to 2.7. [](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) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/maven-project-info-reports-plugin/network/alerts). > Dependency file details section: segregate Java version column into execution > and test versions > --- > > Key: MPIR-431 > URL: https://issues.apache.org/jira/browse/MPIR-431 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: dependencies >Reporter: Gabriel Belingueres >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.4.4 > > > In order to easily spot which is the minimum java version for execution > versus the minimum java version for building the project, divide the "Java > version" column into two columns: > Java version: max version between dependencies with scopes: compile, runtime, > provided, system. > Test Java version: max java version between all the test scoped dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-project-info-reports-plugin] dependabot[bot] opened a new pull request, #53: Bump commons-io from 1.0 to 2.7 in /src/it/MPIR-431
dependabot[bot] opened a new pull request, #53: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/53 Bumps commons-io from 1.0 to 2.7. [](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) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/maven-project-info-reports-plugin/network/alerts). -- 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] (MPIR-431) Dependency file details section: segregate Java version column into execution and test versions
[ https://issues.apache.org/jira/browse/MPIR-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-431. --- Fix Version/s: 3.4.4 Resolution: Fixed Fixed with [dbd863fed69f4e86dfddd82e239646a8cf61cf1f|https://gitbox.apache.org/repos/asf?p=maven-project-info-reports-plugin.git&a=commit&h=dbd863fed69f4e86dfddd82e239646a8cf61cf1f]. > Dependency file details section: segregate Java version column into execution > and test versions > --- > > Key: MPIR-431 > URL: https://issues.apache.org/jira/browse/MPIR-431 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: dependencies >Reporter: Gabriel Belingueres >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.4.4 > > > In order to easily spot which is the minimum java version for execution > versus the minimum java version for building the project, divide the "Java > version" column into two columns: > Java version: max version between dependencies with scopes: compile, runtime, > provided, system. > Test Java version: max java version between all the test scoped dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPIR-431) Dependency file details section: segregate Java version column into execution and test versions
[ https://issues.apache.org/jira/browse/MPIR-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726621#comment-17726621 ] ASF GitHub Bot commented on MPIR-431: - asfgit closed pull request #47: [MPIR-431] Dependency file details section: segregate Java version URL: https://github.com/apache/maven-project-info-reports-plugin/pull/47 > Dependency file details section: segregate Java version column into execution > and test versions > --- > > Key: MPIR-431 > URL: https://issues.apache.org/jira/browse/MPIR-431 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: dependencies >Reporter: Gabriel Belingueres >Assignee: Michael Osipov >Priority: Minor > > In order to easily spot which is the minimum java version for execution > versus the minimum java version for building the project, divide the "Java > version" column into two columns: > Java version: max version between dependencies with scopes: compile, runtime, > provided, system. > Test Java version: max java version between all the test scoped dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-project-info-reports-plugin] asfgit closed pull request #47: [MPIR-431] Dependency file details section: segregate Java version
asfgit closed pull request #47: [MPIR-431] Dependency file details section: segregate Java version URL: https://github.com/apache/maven-project-info-reports-plugin/pull/47 -- 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] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-363. - Resolution: Not A Problem This is actually not a bug, maven-resolver and maven behave correctly. What may be questionable are the Maven defaults, as explained here: [https://maven.apache.org/ref/3.9.2/maven-settings/settings.html#releases] that are by default "never". https://github.com/mojohaus/versions/pull/965The proper fix is done in plugin > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-363: -- Fix Version/s: (was: 1.9.11) > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726593#comment-17726593 ] Tamas Cservenak edited comment on MRESOLVER-363 at 5/26/23 11:21 AM: - This is actually not a bug, maven-resolver and maven behave correctly. What may be questionable are the Maven defaults, as explained here: [https://maven.apache.org/ref/3.9.2/maven-settings/settings.html#releases] that are by default "never". [https://github.com/mojohaus/versions/pull/965 |https://github.com/mojohaus/versions/pull/965] the proper fix is done in plugin was (Author: cstamas): This is actually not a bug, maven-resolver and maven behave correctly. What may be questionable are the Maven defaults, as explained here: [https://maven.apache.org/ref/3.9.2/maven-settings/settings.html#releases] that are by default "never". https://github.com/mojohaus/versions/pull/965The proper fix is done in plugin > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726592#comment-17726592 ] ASF GitHub Bot commented on MRESOLVER-363: -- cstamas closed pull request #291: [MRESOLVER-363] Maven metadata not updated in some cases URL: https://github.com/apache/maven-resolver/pull/291 > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726591#comment-17726591 ] ASF GitHub Bot commented on MRESOLVER-363: -- cstamas commented on PR #291: URL: https://github.com/apache/maven-resolver/pull/291#issuecomment-1564236459 This is completely wrong, and resolver DOES behaves correctly, as update policy is "never" > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas closed pull request #291: [MRESOLVER-363] Maven metadata not updated in some cases
cstamas closed pull request #291: [MRESOLVER-363] Maven metadata not updated in some cases URL: https://github.com/apache/maven-resolver/pull/291 -- 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-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726587#comment-17726587
]
Tamas Cservenak commented on MRESOLVER-363:
---
We need more discussion here. I fixed locally, and noticed that a UT fails,
this one:
[https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.10/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManagerTest.java#L427-L434]
My "experiment" PR to address is this:
[https://github.com/apache/maven-resolver/pull/291]
As policy "never" IS in effect. I think Garret does not override it. Effective
update policies explained here:
[https://maven.apache.org/ref/3.9.2/maven-settings/settings.html#releases]
So, to me it seems that:
* reporter case was covered with UT (with exact opposite outcome), am still
trying to figure out the intent here (why is this expected behavior)
* otherwise maven behaves "consistently": by default policy "never" is
applied, so yes, seems Garret is right: in case of downloaded metadata, they
are NOT updated anymore (!) unless explicitly asked for with {{-U}}
* in case of Maven, this seems consistent to me
But, there is a twist: this behavior when combined with versions-maven-plugin,
may result in undesired result! Today, from experience, almost everyone use
versions-maven-display-plugin:display-XXX-updates along with {{-U}} switch.
But IMHO, the {{-U}} is like shooting with a cannon on a bird, as it will
update {_}everything{_}as Maven will set "update" globally here:
[https://github.com/apache/maven/blob/maven-3.9.2/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L168]
This will result in enormous download, basically check ANY file Maven during
execution "touches", even the versions plugin itself.
So, to me this looks like it is versions-maven-plugin responsibility to set
this, but in "targeted" way: https://github.com/mojohaus/versions/pull/965
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.11
>
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726579#comment-17726579 ] ASF GitHub Bot commented on MRESOLVER-363: -- cstamas opened a new pull request, #291: URL: https://github.com/apache/maven-resolver/pull/291 In case of metadata, when XML file exists, but the resolver-status.properties file does not, or the "lastUpdated" key is not found, the XML is never updated. NOTE: UT fails, we need more discussion about this, see JIRA issue. --- https://issues.apache.org/jira/browse/MRESOLVER-363 > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas opened a new pull request, #291: [MRESOLVER-363] Maven metadata not updated in some cases
cstamas opened a new pull request, #291: URL: https://github.com/apache/maven-resolver/pull/291 In case of metadata, when XML file exists, but the resolver-status.properties file does not, or the "lastUpdated" key is not found, the XML is never updated. NOTE: UT fails, we need more discussion about this, see JIRA issue. --- https://issues.apache.org/jira/browse/MRESOLVER-363 -- 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] (MRELEASE-1125) Add a waitAfterTagging config parameter
Roberto Lo Giacco created MRELEASE-1125: --- Summary: Add a waitAfterTagging config parameter Key: MRELEASE-1125 URL: https://issues.apache.org/jira/browse/MRELEASE-1125 Project: Maven Release Plugin Issue Type: New Feature Components: prepare Reporter: Roberto Lo Giacco Our Jenkins pipeline gets activated upon pushing to the GIT repository and checks if the current commit has a release tag to decide if the build must produce an artifact. Sometimes the commit to prepare for the next release gets pushed before the pipeline gets a chance to start, thus skipping the release process and forcing a rollback and restart. With the introduction of a *waitAfterTagging* configuration property we can provide a 3-5sec delay to ensure the pipeline gets activated before the next commit gets pushed in. If desireable I can provide a pull request for this: I really need it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRELEASE-1123) Maven Release plugin doesn't work in maven 4
[
https://issues.apache.org/jira/browse/MRELEASE-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MRELEASE-1123.
-
Fix Version/s: 3.0.1
Assignee: Slawomir Jaranowski (was: Guillaume Nodet)
Resolution: Fixed
{{generate-release-poms}} depends on MNG-7784 so will be work with 4.0.0-alpha-6
> Maven Release plugin doesn't work in maven 4
>
>
> Key: MRELEASE-1123
> URL: https://issues.apache.org/jira/browse/MRELEASE-1123
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.0.0
> Environment: Any
>Reporter: Lenny Primak
>Assignee: Slawomir Jaranowski
>Priority: Blocker
> Fix For: 3.0.1
>
>
> {code:java}
> mvn -B -ntp -C release:prepare release:perform{code}
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:3.0.0:prepare (default-cli) on
> project flowlogix: Unable to parse configuration of mojo
> org.apache.maven.plugins:maven-release-plugin:3.0.0:prepare for parameter
> projectVersionPolicyConfig: Cannot set 'projectVersionPolicyConfig' in class
> org.apache.maven.plugins.release.PrepareReleaseMojo: Can not set
> org.codehaus.plexus.configuration.xml.XmlPlexusConfiguration field
> org.apache.maven.plugins.release.PrepareReleaseMojo.projectVersionPolicyConfig
> to org.apache.maven.internal.xml.XmlPlexusConfiguration -> [Help 1]{code}
> Maven 4.0.0-alpha-5 and release plugin 3.0.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1123) Maven Release plugin doesn't work in maven 4
[
https://issues.apache.org/jira/browse/MRELEASE-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726575#comment-17726575
]
ASF GitHub Bot commented on MRELEASE-1123:
--
slawekjaranowski closed pull request #187: [MRELEASE-1123] Use the
PlexusConfiguration interface instead of the final class
URL: https://github.com/apache/maven-release/pull/187
> Maven Release plugin doesn't work in maven 4
>
>
> Key: MRELEASE-1123
> URL: https://issues.apache.org/jira/browse/MRELEASE-1123
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.0.0
> Environment: Any
>Reporter: Lenny Primak
>Assignee: Guillaume Nodet
>Priority: Blocker
>
> {code:java}
> mvn -B -ntp -C release:prepare release:perform{code}
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:3.0.0:prepare (default-cli) on
> project flowlogix: Unable to parse configuration of mojo
> org.apache.maven.plugins:maven-release-plugin:3.0.0:prepare for parameter
> projectVersionPolicyConfig: Cannot set 'projectVersionPolicyConfig' in class
> org.apache.maven.plugins.release.PrepareReleaseMojo: Can not set
> org.codehaus.plexus.configuration.xml.XmlPlexusConfiguration field
> org.apache.maven.plugins.release.PrepareReleaseMojo.projectVersionPolicyConfig
> to org.apache.maven.internal.xml.XmlPlexusConfiguration -> [Help 1]{code}
> Maven 4.0.0-alpha-5 and release plugin 3.0.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1123) Maven Release plugin doesn't work in maven 4
[
https://issues.apache.org/jira/browse/MRELEASE-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726574#comment-17726574
]
ASF GitHub Bot commented on MRELEASE-1123:
--
slawekjaranowski commented on PR #187:
URL: https://github.com/apache/maven-release/pull/187#issuecomment-1564173805
suppressed by #186
> Maven Release plugin doesn't work in maven 4
>
>
> Key: MRELEASE-1123
> URL: https://issues.apache.org/jira/browse/MRELEASE-1123
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.0.0
> Environment: Any
>Reporter: Lenny Primak
>Assignee: Guillaume Nodet
>Priority: Blocker
>
> {code:java}
> mvn -B -ntp -C release:prepare release:perform{code}
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:3.0.0:prepare (default-cli) on
> project flowlogix: Unable to parse configuration of mojo
> org.apache.maven.plugins:maven-release-plugin:3.0.0:prepare for parameter
> projectVersionPolicyConfig: Cannot set 'projectVersionPolicyConfig' in class
> org.apache.maven.plugins.release.PrepareReleaseMojo: Can not set
> org.codehaus.plexus.configuration.xml.XmlPlexusConfiguration field
> org.apache.maven.plugins.release.PrepareReleaseMojo.projectVersionPolicyConfig
> to org.apache.maven.internal.xml.XmlPlexusConfiguration -> [Help 1]{code}
> Maven 4.0.0-alpha-5 and release plugin 3.0.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-release] slawekjaranowski closed pull request #187: [MRELEASE-1123] Use the PlexusConfiguration interface instead of the final class
slawekjaranowski closed pull request #187: [MRELEASE-1123] Use the PlexusConfiguration interface instead of the final class URL: https://github.com/apache/maven-release/pull/187 -- 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] (MRELEASE-1123) Maven Release plugin doesn't work in maven 4
[
https://issues.apache.org/jira/browse/MRELEASE-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726573#comment-17726573
]
ASF GitHub Bot commented on MRELEASE-1123:
--
slawekjaranowski merged PR #186:
URL: https://github.com/apache/maven-release/pull/186
> Maven Release plugin doesn't work in maven 4
>
>
> Key: MRELEASE-1123
> URL: https://issues.apache.org/jira/browse/MRELEASE-1123
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.0.0
> Environment: Any
>Reporter: Lenny Primak
>Assignee: Guillaume Nodet
>Priority: Blocker
>
> {code:java}
> mvn -B -ntp -C release:prepare release:perform{code}
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:3.0.0:prepare (default-cli) on
> project flowlogix: Unable to parse configuration of mojo
> org.apache.maven.plugins:maven-release-plugin:3.0.0:prepare for parameter
> projectVersionPolicyConfig: Cannot set 'projectVersionPolicyConfig' in class
> org.apache.maven.plugins.release.PrepareReleaseMojo: Can not set
> org.codehaus.plexus.configuration.xml.XmlPlexusConfiguration field
> org.apache.maven.plugins.release.PrepareReleaseMojo.projectVersionPolicyConfig
> to org.apache.maven.internal.xml.XmlPlexusConfiguration -> [Help 1]{code}
> Maven 4.0.0-alpha-5 and release plugin 3.0.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-release] slawekjaranowski merged pull request #186: [MRELEASE-1123] Fix for Maven 4 compatibility
slawekjaranowski merged PR #186: URL: https://github.com/apache/maven-release/pull/186 -- 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-364) Revert MRESOLVER-132
[ https://issues.apache.org/jira/browse/MRESOLVER-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726572#comment-17726572 ] Michael Osipov commented on MRESOLVER-364: -- Quite depressing... > Revert MRESOLVER-132 > > > Key: MRESOLVER-364 > URL: https://issues.apache.org/jira/browse/MRESOLVER-364 > Project: Maven Resolver > Issue Type: Task >Reporter: 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] [Comment Edited] (MRESOLVER-364) Revert MRESOLVER-132
[ https://issues.apache.org/jira/browse/MRESOLVER-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726571#comment-17726571 ] Tamas Cservenak edited comment on MRESOLVER-364 at 5/26/23 10:08 AM: - Yes, if we'd be 100% there is no possibility for this to happen. But we KNOW that is not the case, For example today, it is enough to use versions-maven-plugin 2.12 that is not so old even (current today is 2.15) was (Author: cstamas): Yes, if we'd be 100% there is no possibility for this to happen. But we KNOW that is not the case, > Revert MRESOLVER-132 > > > Key: MRESOLVER-364 > URL: https://issues.apache.org/jira/browse/MRESOLVER-364 > Project: Maven Resolver > Issue Type: Task >Reporter: 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] [Commented] (MRESOLVER-364) Revert MRESOLVER-132
[ https://issues.apache.org/jira/browse/MRESOLVER-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726571#comment-17726571 ] Tamas Cservenak commented on MRESOLVER-364: --- Yes, if we'd be 100% there is no possibility for this to happen. But we KNOW that is not the case, > Revert MRESOLVER-132 > > > Key: MRESOLVER-364 > URL: https://issues.apache.org/jira/browse/MRESOLVER-364 > Project: Maven Resolver > Issue Type: Task >Reporter: 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] [Commented] (SUREFIRE-2164) Simplify serialization of elapsed time in StatelessXmlReporter
[
https://issues.apache.org/jira/browse/SUREFIRE-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726570#comment-17726570
]
ASF GitHub Bot commented on SUREFIRE-2164:
--
slawekjaranowski commented on code in PR #645:
URL: https://github.com/apache/maven-surefire/pull/645#discussion_r1206532613
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java:
##
@@ -387,7 +390,9 @@ private void startTestElement(XMLWriter ppw,
WrappedReportEntry report) throws I
ppw.addAttribute("classname", extraEscapeAttribute(className));
}
-ppw.addAttribute("time", report.elapsedTimeAsString());
Review Comment:
ok
> Simplify serialization of elapsed time in StatelessXmlReporter
> --
>
> Key: SUREFIRE-2164
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2164
> Project: Maven Surefire
> Issue Type: Improvement
> Components: xml generation
>Affects Versions: 3.1.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.1.1
>
>
> The current code uses a convoluted solution based on {{NumberFormat}} which
> refers to an outdated defintion on Ant's XML report file. These days, we can
> use {{String#valueOf()}} to serialize the string representation of a float
> value since:
> * Easier to understand and this is not human output (separation of concerns)
> * Ant's XMLJUnitResultFormatter does exactly the same with a double value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] slawekjaranowski commented on a diff in pull request #645: Simplify serialization/deserialization of elapsed time (SUREFIRE-2164 + SUREFIRE-2167)
slawekjaranowski commented on code in PR #645:
URL: https://github.com/apache/maven-surefire/pull/645#discussion_r1206532613
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java:
##
@@ -387,7 +390,9 @@ private void startTestElement(XMLWriter ppw,
WrappedReportEntry report) throws I
ppw.addAttribute("classname", extraEscapeAttribute(className));
}
-ppw.addAttribute("time", report.elapsedTimeAsString());
Review Comment:
ok
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-364) Revert MRESOLVER-132
[ https://issues.apache.org/jira/browse/MRESOLVER-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726568#comment-17726568 ] Michael Osipov commented on MRESOLVER-364: -- So without Maven Compat this revert would not be necessary? > Revert MRESOLVER-132 > > > Key: MRESOLVER-364 > URL: https://issues.apache.org/jira/browse/MRESOLVER-364 > Project: Maven Resolver > Issue Type: Task >Reporter: 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] [Created] (MRESOLVER-364) Revert MRESOLVER-132
Tamas Cservenak created MRESOLVER-364: - Summary: Revert MRESOLVER-132 Key: MRESOLVER-364 URL: https://issues.apache.org/jira/browse/MRESOLVER-364 Project: Maven Resolver Issue Type: Task Reporter: Tamas Cservenak Revert this 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-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: -- Description: 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. was: Revert this 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. > Revert MRESOLVER-132 > > > Key: MRESOLVER-364 > URL: https://issues.apache.org/jira/browse/MRESOLVER-364 > Project: Maven Resolver > Issue Type: Task >Reporter: 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-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: -- Fix Version/s: 1.9.11 > Revert MRESOLVER-132 > > > Key: MRESOLVER-364 > URL: https://issues.apache.org/jira/browse/MRESOLVER-364 > Project: Maven Resolver > Issue Type: Task >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > Revert this 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] [Commented] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar
[
https://issues.apache.org/jira/browse/MRESOLVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726561#comment-17726561
]
Michael Osipov commented on MRESOLVER-362:
--
I am against being lenient with violators.
> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a
> test that uses the resolver API to collect a bunch of dependencies, and
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not
> transfer artifact
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13
> from/to spring-snapshots (https://repo.spring.io/snapshot):
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
> ... 45 more
> Caused by: java.nio.file.NoSuchFileException:
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
> at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
> {noformat}
> The test is here
> https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar
[
https://issues.apache.org/jira/browse/MRESOLVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726559#comment-17726559
]
Tamas Cservenak edited comment on MRESOLVER-362 at 5/26/23 9:38 AM:
Current stance: This is not a bug. but user Transport implementation violates
contract, that previous code was not so rigorous about, but now is a bit more.
Still, we could make code around
[https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.10/maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/BasicRepositoryConnector.java#L500]
a bit more "forgiving", but still, I'd not do it just to support transport
implementations that violates contract (ie "worked before but not now").
was (Author: cstamas):
Current stance: This is not a bug. but user Transport implementation violates
contract, that previous code was not so rigorous about, but now is a bit more.
Still, we could make code around
[https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.10/maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/BasicRepositoryConnector.java#L500]
a bit more "forgiving", but still, I'd not do it just to support transport
implementations that violates contact (ie "worked before but not now").
> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a
> test that uses the resolver API to collect a bunch of dependencies, and
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not
> transfer artifact
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13
> from/to spring-snapshots (https://repo.spring.io/snapshot):
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
> ... 45 more
> Caused by: java.nio.file.NoSuchFileException:
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
> at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
> {noformat}
> The test is here
> https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar
[
https://issues.apache.org/jira/browse/MRESOLVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726559#comment-17726559
]
Tamas Cservenak commented on MRESOLVER-362:
---
Current stance: This is not a bug. but user Transport implementation violates
contract, that previous code was not so rigorous about, but now is a bit more.
Still, we could make code around
[https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.10/maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/BasicRepositoryConnector.java#L500]
a bit more "forgiving", but still, I'd not do it just to support transport
implementations that violates contact (ie "worked before but not now").
> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a
> test that uses the resolver API to collect a bunch of dependencies, and
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not
> transfer artifact
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13
> from/to spring-snapshots (https://repo.spring.io/snapshot):
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
> ... 45 more
> Caused by: java.nio.file.NoSuchFileException:
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
> at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
> {noformat}
> The test is here
> https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar
[
https://issues.apache.org/jira/browse/MRESOLVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-362:
--
Fix Version/s: (was: 1.9.11)
> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a
> test that uses the resolver API to collect a bunch of dependencies, and
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not
> transfer artifact
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13
> from/to spring-snapshots (https://repo.spring.io/snapshot):
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
> ... 45 more
> Caused by: java.nio.file.NoSuchFileException:
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
> at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
> {noformat}
> The test is here
> https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar
[
https://issues.apache.org/jira/browse/MRESOLVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726557#comment-17726557
]
Michael Osipov edited comment on MRESOLVER-362 at 5/26/23 9:32 AM:
---
I can reproduce it as well.
was (Author: michael-o):
I can reproduce it as well.
[~cstamas], any pointers already?
> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a
> test that uses the resolver API to collect a bunch of dependencies, and
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not
> transfer artifact
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13
> from/to spring-snapshots (https://repo.spring.io/snapshot):
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
> ... 45 more
> Caused by: java.nio.file.NoSuchFileException:
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
> at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
> {noformat}
> The test is here
> https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar
[
https://issues.apache.org/jira/browse/MRESOLVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726558#comment-17726558
]
Tamas Cservenak commented on MRESOLVER-362:
---
Created change proposal (but unsure about actual use case)
https://github.com/snicoll-scratches/MRESOLVER-362/pull/1
> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
> Fix For: 1.9.11
>
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a
> test that uses the resolver API to collect a bunch of dependencies, and
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not
> transfer artifact
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13
> from/to spring-snapshots (https://repo.spring.io/snapshot):
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
> ... 45 more
> Caused by: java.nio.file.NoSuchFileException:
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
> at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
> {noformat}
> The test is here
> https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar
[
https://issues.apache.org/jira/browse/MRESOLVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726557#comment-17726557
]
Michael Osipov commented on MRESOLVER-362:
--
I can reproduce it as well.
[~cstamas], any pointers already?
> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
> Fix For: 1.9.11
>
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a
> test that uses the resolver API to collect a bunch of dependencies, and
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not
> transfer artifact
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13
> from/to spring-snapshots (https://repo.spring.io/snapshot):
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
> ... 45 more
> Caused by: java.nio.file.NoSuchFileException:
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
> at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
> {noformat}
> The test is here
> https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar
[
https://issues.apache.org/jira/browse/MRESOLVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726555#comment-17726555
]
Tamas Cservenak commented on MRESOLVER-362:
---
So far, to me it seems is bug in your JarSkippingTransportFactory, it violates
API contract. The reproducer passes OK when I comment out these lines:
[https://github.com/snicoll-scratches/MRESOLVER-362/blob/main/src/main/java/com/example/mresolver362/DependencyResolver.java#L250-L252]
For ref, I have locally this:
{noformat}
@Override
public void get(GetTask task) throws Exception {
// if (task.getLocation().getPath().endsWith(".jar")) {
// return;
// }
this.delegate.get(task);
} {noformat}
Problem occurs later, as from debug logs (thanks for setting that up!) it
becomes apparent, that resolver NEVER asks for JAR, but does these two requests:
GET
https://repo.spring.io/snapshot/org/springframework/cloud/spring-cloud-contract-stub-runner/4.0.3/spring-cloud-contract-stub-runner-4.0.3.jar.sha1
(receives 404)
GET
https://repo.spring.io/snapshot/org/springframework/cloud/spring-cloud-contract-stub-runner/4.0.3/spring-cloud-contract-stub-runner-4.0.3.jar.md5
(receives 404)
Then it reports validation error (as validation is WARN, so is reported and it
goes on)
{noformat}
2023-05-26 10:31:11,049 WARN [main] o.e.a.i.i.WarnChecksumPolicy
[WarnChecksumPolicy.java : 35] -- Could not validate integrity of download from
https://repo.spring.io/snapshot/org/springframework/cloud/spring-cloud-contract-stub-runner/4.0.3/spring-clou
d-contract-stub-runner-4.0.3.jar
org.eclipse.aether.transfer.ChecksumFailureException: Checksum validation
failed, no checksums available
at
org.eclipse.aether.internal.impl.AbstractChecksumPolicy.onNoMoreChecksums(AbstractChecksumPolicy.java:63)
{noformat}
and finally it arrives here:
[https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.10/maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/BasicRepositoryConnector.java#L500]
Now, the problem is, that at this point, code expected: that "main payload" is
downloaded, as transport did not throw anything (it was just return). This is
violation of transport contract.
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.10/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/transport/Transporter.java#L74-L81
No, as I see, you want POMs only? Or even only GAs? Or this is just for demo
purposes?
> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
> Fix For: 1.9.11
>
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a
> test that uses the resolver API to collect a bunch of dependencies, and
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not
> transfer artifact
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13
> from/to spring-snapshots (https://repo.spring.io/snapshot):
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
> at
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
> ... 45 more
> Caused by: java.nio.file.NoSuchFileException:
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
> ->
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-b
[jira] [Commented] (MNG-7795) IllegalArgumentException: 'other' has different root during plugin validation
[
https://issues.apache.org/jira/browse/MNG-7795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726532#comment-17726532
]
ASF GitHub Bot commented on MNG-7795:
-
adangel commented on code in PR #1128:
URL: https://github.com/apache/maven/pull/1128#discussion_r1206441400
##
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java:
##
@@ -247,7 +247,11 @@ private String pluginOccurrence(MavenSession mavenSession)
{
File currentPom = prj.getFile();
if (currentPom != null) {
File rootBasedir = mavenSession.getTopLevelProject().getBasedir();
-result += " (" +
rootBasedir.toPath().relativize(currentPom.toPath()) + ")";
+if (currentPom.getPath().startsWith(rootBasedir.getPath())) {
Review Comment:
> And can we make the local variable name consistent, i.e. name it
`topBasedir` instead of `rootBasedir` ?
Done.
I've also updated ExecutionEventLogger. It seems, this was the only other
place, where Path::relativize is used.
> IllegalArgumentException: 'other' has different root during plugin validation
> -
>
> Key: MNG-7795
> URL: https://issues.apache.org/jira/browse/MNG-7795
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.2
>Reporter: Andreas Dangel
>Assignee: Andreas Dangel
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> This bug happens under Windows only and is the reason, why one IT
> (MPMD-323-ruleset-basedir-jgitver) is failing for m-pmd-p with the following
> exception:
>
> {code:java}
> java.lang.IllegalArgumentException: 'other' has different root
> at sun.nio.fs.WindowsPath.relativize (WindowsPath.java:404)
> at sun.nio.fs.WindowsPath.relativize (WindowsPath.java:42)
> at
> org.apache.maven.plugin.internal.DefaultPluginValidationManager.pluginOccurrence
> (DefaultPluginValidationManager.java:224)
> at
> org.apache.maven.plugin.internal.DefaultPluginValidationManager.reportPluginValidationIssue
> (DefaultPluginValidationManager.java:111)
> at
> org.apache.maven.plugin.internal.PlexusContainerDefaultDependenciesValidator.doValidate
> (PlexusContainerDefaultDependenciesValidator.java:49)
> at
> org.apache.maven.plugin.internal.AbstractMavenPluginDependenciesValidator.validate
> (AbstractMavenPluginDependenciesValidator.java:50)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
> (DefaultMavenPluginManager.java:560)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:114)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:462)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:325)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:2
[GitHub] [maven] adangel commented on a diff in pull request #1128: [MNG-7795] IllegalArgumentException: 'other' has different root durin…
adangel commented on code in PR #1128:
URL: https://github.com/apache/maven/pull/1128#discussion_r1206441400
##
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java:
##
@@ -247,7 +247,11 @@ private String pluginOccurrence(MavenSession mavenSession)
{
File currentPom = prj.getFile();
if (currentPom != null) {
File rootBasedir = mavenSession.getTopLevelProject().getBasedir();
-result += " (" +
rootBasedir.toPath().relativize(currentPom.toPath()) + ")";
+if (currentPom.getPath().startsWith(rootBasedir.getPath())) {
Review Comment:
> And can we make the local variable name consistent, i.e. name it
`topBasedir` instead of `rootBasedir` ?
Done.
I've also updated ExecutionEventLogger. It seems, this was the only other
place, where Path::relativize is used.
--
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-7795) IllegalArgumentException: 'other' has different root during plugin validation
[
https://issues.apache.org/jira/browse/MNG-7795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726528#comment-17726528
]
ASF GitHub Bot commented on MNG-7795:
-
gnodet commented on code in PR #1128:
URL: https://github.com/apache/maven/pull/1128#discussion_r1206422683
##
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java:
##
@@ -247,7 +247,11 @@ private String pluginOccurrence(MavenSession mavenSession)
{
File currentPom = prj.getFile();
if (currentPom != null) {
File rootBasedir = mavenSession.getTopLevelProject().getBasedir();
-result += " (" +
rootBasedir.toPath().relativize(currentPom.toPath()) + ")";
+if (currentPom.getPath().startsWith(rootBasedir.getPath())) {
Review Comment:
And can we make the local variable name consistent, i.e. name it
`topBasedir` instead of `rootBasedir` ?
> IllegalArgumentException: 'other' has different root during plugin validation
> -
>
> Key: MNG-7795
> URL: https://issues.apache.org/jira/browse/MNG-7795
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.2
>Reporter: Andreas Dangel
>Assignee: Andreas Dangel
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> This bug happens under Windows only and is the reason, why one IT
> (MPMD-323-ruleset-basedir-jgitver) is failing for m-pmd-p with the following
> exception:
>
> {code:java}
> java.lang.IllegalArgumentException: 'other' has different root
> at sun.nio.fs.WindowsPath.relativize (WindowsPath.java:404)
> at sun.nio.fs.WindowsPath.relativize (WindowsPath.java:42)
> at
> org.apache.maven.plugin.internal.DefaultPluginValidationManager.pluginOccurrence
> (DefaultPluginValidationManager.java:224)
> at
> org.apache.maven.plugin.internal.DefaultPluginValidationManager.reportPluginValidationIssue
> (DefaultPluginValidationManager.java:111)
> at
> org.apache.maven.plugin.internal.PlexusContainerDefaultDependenciesValidator.doValidate
> (PlexusContainerDefaultDependenciesValidator.java:49)
> at
> org.apache.maven.plugin.internal.AbstractMavenPluginDependenciesValidator.validate
> (AbstractMavenPluginDependenciesValidator.java:50)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
> (DefaultMavenPluginManager.java:560)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:114)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:462)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:325)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven
