[jira] [Commented] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787063#comment-17787063
]
Herve Boutemy commented on MNG-7906:
MPH-183 is a first step: be able to know where the effective import comes from
then on the dedupe algorithm and clarification, we'll be able to discuss:
[~aalmiray] is doing a series of talks in many conferences for 1 or 2 years on
Maven Dependency surprises, we should probably ask him to share his examples so
we can improve explanations and feedback when building
on this notion of "closer", we need to define that it means depth first then
order
once we explicit that, in the case of dependencyManagement, there is no depth,
then there is only order: that's the same, just a notion that de-facto does not
exist
When I saw Andres talk first, I found that most cases he reported were due to
cases like that: no clarity on what a vague term like "closer" means, then
surprises when trying to apply in a context that has different initial facts.
But no rush on conclusions, let's go step by step on this dependencyManagement
import clarification (and I have to fight against saying "dependency import",
because dependencyManagement is fundamentally different from dependency: there
is no transitivity, then no depth, then consequences)
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Reporter: Tamas Cservenak
>Priority: Blocker
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId
[
https://issues.apache.org/jira/browse/MJAVADOC-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787061#comment-17787061
]
AO Industries, Inc. commented on MJAVADOC-682:
--
We have tested version 3.6.2 and confirm this issue remains.
> Reactor builds fail when multiple modules with same groupId:artifactId
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1,
> 3.5.0, 3.6.0, 3.6.2
> Environment: Debian Linux versions 10.10 through 12.2
> OpenJDK 64-bit versions 11.0.11 through 17.0.9
> Maven versions 3.8.1 through 3.9.5
>Reporter: AO Industries, Inc.
>Priority: Major
> Labels: jpms
>
> In versions 3.1.0 through 3.6.2, when a reactor build has multiple projects
> with the same groupId and artifactId, even when different versions, the
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>
> — Copy from demo project README.md —
> h2. To Reproduce:
> # Clone this project: {{git clone
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
> # Change to project directory: {{cd
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
> # Perform build to see error in {{jar}} goal: {{mvn verify}}
> # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
> * Can build individual modules directly, such as {{(cd module-1 && mvn
> verify)}}
> * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
> * Changing the groupId or artifactId in either module-1 or module-2 makes it
> work.
> * Changing module names, package names, or class names in modules has no
> effect.
> * We believe this to be distinct from [Issue
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId
[
https://issues.apache.org/jira/browse/MJAVADOC-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AO Industries, Inc. updated MJAVADOC-682:
-
Description:
In versions 3.1.0 through 3.6.2, when a reactor build has multiple projects
with the same groupId and artifactId, even when different versions, the javadoc
fails with:
Exit code: 1 - error: module not found: com.aoindustries.example
Plugin 3.0.1 works.
We have created a minimal example project that demonstrates this bug:
[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
— Copy from demo project README.md —
h2. To Reproduce:
# Clone this project: {{git clone
[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
# Change to project directory: {{cd
maven-javadoc-plugin-failing-multiple-projects-same-name}}
# Perform build to see error in {{jar}} goal: {{mvn verify}}
# Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
h2. Notes:
* Can build individual modules directly, such as {{(cd module-1 && mvn
verify)}}
* Reverting to maven-javadoc-plugin version 3.0.1 makes it work
* Changing the groupId or artifactId in either module-1 or module-2 makes it
work.
* Changing module names, package names, or class names in modules has no
effect.
* We believe this to be distinct from [Issue
#673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
was:
In versions 3.1.0 through 3.6.0, when a reactor build has multiple projects
with the same groupId and artifactId, even when different versions, the javadoc
fails with:
Exit code: 1 - error: module not found: com.aoindustries.example
Plugin 3.0.1 works.
We have created a minimal example project that demonstrates this bug:
[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
— Copy from demo project README.md —
h2. To Reproduce:
# Clone this project: {{git clone
[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
# Change to project directory: {{cd
maven-javadoc-plugin-failing-multiple-projects-same-name}}
# Perform build to see error in {{jar}} goal: {{mvn verify}}
# Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
h2. Notes:
* Can build individual modules directly, such as {{(cd module-1 && mvn
verify)}}
* Reverting to maven-javadoc-plugin version 3.0.1 makes it work
* Changing the groupId or artifactId in either module-1 or module-2 makes it
work.
* Changing module names, package names, or class names in modules has no
effect.
* We believe this to be distinct from [Issue
#673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
> Reactor builds fail when multiple modules with same groupId:artifactId
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1,
> 3.5.0, 3.6.0, 3.6.2
> Environment: Debian Linux versions 10.10 through 12.2
> OpenJDK 64-bit versions 11.0.11 through 17.0.9
> Maven versions 3.8.1 through 3.9.5
>Reporter: AO Industries, Inc.
>Priority: Major
> Labels: jpms
>
> In versions 3.1.0 through 3.6.2, when a reactor build has multiple projects
> with the same groupId and artifactId, even when different versions, the
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>
> — Copy from demo project README.md —
> h2. To Reproduce:
> # Clone this project: {{git clone
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
> # Change to project directory: {{cd
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
> # Perform build to see error in {{jar}} goal: {{mvn verify}}
> # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
> * Can build individual modules directly, such as {{(cd module-1 && mvn
> verify)}}
> * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
> * Changing the groupId or artifactId in either module-1 or module-2 makes it
> work.
> * Changing module names, package names, or class names in modules has no
> effect.
> * We believe this to be distinct from [Issue
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId
[
https://issues.apache.org/jira/browse/MJAVADOC-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AO Industries, Inc. updated MJAVADOC-682:
-
Environment:
Debian Linux versions 10.10 through 12.2
OpenJDK 64-bit versions 11.0.11 through 17.0.9
Maven versions 3.8.1 through 3.9.5
was:
Debian Linux versions 10.10 through 12.1
OpenJDK 64-bit versions 11.0.11 through 17.0.8
Maven versions 3.8.1 through 3.9.4
> Reactor builds fail when multiple modules with same groupId:artifactId
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1,
> 3.5.0, 3.6.0, 3.6.2
> Environment: Debian Linux versions 10.10 through 12.2
> OpenJDK 64-bit versions 11.0.11 through 17.0.9
> Maven versions 3.8.1 through 3.9.5
>Reporter: AO Industries, Inc.
>Priority: Major
> Labels: jpms
>
> In versions 3.1.0 through 3.6.0, when a reactor build has multiple projects
> with the same groupId and artifactId, even when different versions, the
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>
> — Copy from demo project README.md —
> h2. To Reproduce:
> # Clone this project: {{git clone
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
> # Change to project directory: {{cd
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
> # Perform build to see error in {{jar}} goal: {{mvn verify}}
> # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
> * Can build individual modules directly, such as {{(cd module-1 && mvn
> verify)}}
> * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
> * Changing the groupId or artifactId in either module-1 or module-2 makes it
> work.
> * Changing module names, package names, or class names in modules has no
> effect.
> * We believe this to be distinct from [Issue
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId
[
https://issues.apache.org/jira/browse/MJAVADOC-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AO Industries, Inc. updated MJAVADOC-682:
-
Affects Version/s: 3.6.2
> Reactor builds fail when multiple modules with same groupId:artifactId
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1,
> 3.5.0, 3.6.0, 3.6.2
> Environment: Debian Linux versions 10.10 through 12.1
> OpenJDK 64-bit versions 11.0.11 through 17.0.8
> Maven versions 3.8.1 through 3.9.4
>Reporter: AO Industries, Inc.
>Priority: Major
> Labels: jpms
>
> In versions 3.1.0 through 3.6.0, when a reactor build has multiple projects
> with the same groupId and artifactId, even when different versions, the
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>
> — Copy from demo project README.md —
> h2. To Reproduce:
> # Clone this project: {{git clone
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
> # Change to project directory: {{cd
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
> # Perform build to see error in {{jar}} goal: {{mvn verify}}
> # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
> * Can build individual modules directly, such as {{(cd module-1 && mvn
> verify)}}
> * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
> * Changing the groupId or artifactId in either module-1 or module-2 makes it
> work.
> * Changing module names, package names, or class names in modules has no
> effect.
> * We believe this to be distinct from [Issue
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787043#comment-17787043
]
ASF GitHub Bot commented on MRESOLVER-372:
--
laeubi commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815804015
> @laeubi me having done some analysis about file locking on windows. uhmmm
LOL you may confuse with someone else ;)
Hm... it should have been @michael-o sorry for the confusion no idea why
github has suggested your name and I didn't notice :-D
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
laeubi commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815804015 > @laeubi me having done some analysis about file locking on windows. uhmmm LOL you may confuse with someone else ;) Hm... it should have been @michael-o sorry for the confusion no idea why github has suggested your name and I didn't notice :-D -- 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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787039#comment-17787039
]
ASF GitHub Bot commented on MRESOLVER-372:
--
olamy commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815797221
@laeubi me having done some analysis about file locking on windows. uhmmm
LOL you may confuse with someone else ;)
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
olamy commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815797221 @laeubi me having done some analysis about file locking on windows. uhmmm LOL you may confuse with someone else ;) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787033#comment-17787033
]
ASF GitHub Bot commented on MRESOLVER-372:
--
laeubi commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815784844
@cstamas I'm a bit late to the party **but** as @rdicroce already tested
showed I cna only tell that Maven 3.8.x ("old"? resolver) has worked under
Windows why upgrade to 3.9.x ("new"? resolver) shows reproducible problems in
this regard.
I'm not a windows expert enough to tell but think @olamy has done already
some analysis in the past about the Move/Sync problem.
In general I think it would really be beneficial if resolver would simply
use time-stamped SNAPSHOTs instead of "normalized", maybe one can even for a
while simply **write** the SNAPSHOT as an additional file (on windows) and
**symlink** under Linux but resolver use/returns the timestamped file to start
a migration?
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
laeubi commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815784844
@cstamas I'm a bit late to the party **but** as @rdicroce already tested
showed I cna only tell that Maven 3.8.x ("old"? resolver) has worked under
Windows why upgrade to 3.9.x ("new"? resolver) shows reproducible problems in
this regard.
I'm not a windows expert enough to tell but think @olamy has done already
some analysis in the past about the Move/Sync problem.
In general I think it would really be beneficial if resolver would simply
use time-stamped SNAPSHOTs instead of "normalized", maybe one can even for a
while simply **write** the SNAPSHOT as an additional file (on windows) and
**symlink** under Linux but resolver use/returns the timestamped file to start
a migration?
--
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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786938#comment-17786938
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815289902
I propose this last change as final PR, will ask for re-review from everyone
adding review so far.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
cstamas commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815289902 I propose this last change as final PR, will ask for re-review from everyone adding review so far. -- 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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786936#comment-17786936
]
ASF GitHub Bot commented on MRESOLVER-372:
--
rdicroce commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815268637
@cstamas #365 works on my machine.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
rdicroce commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815268637 @cstamas #365 works on my machine. -- 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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786932#comment-17786932
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815231993
@rdicroce updated this but also the backport PR
https://github.com/apache/maven-resolver/pull/365
Please try!
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
cstamas commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815231993 @rdicroce updated this but also the backport PR https://github.com/apache/maven-resolver/pull/365 Please try! -- 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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786925#comment-17786925
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815208135
Wow, @rdicroce Thanks for testing this!
So, this for me proves even more, that problem lies within WindowsFS
As I said, my intent with use of "atomic moves" was actually to prevent
other processes to end up reading partially written file content... And this
code @rdicroce tested, while does, does not prevent this
So, maybe IF win old_code ELSE new_code? Hm
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
cstamas commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815208135 Wow, @rdicroce Thanks for testing this! So, this for me proves even more, that problem lies within WindowsFS As I said, my intent with use of "atomic moves" was actually to prevent other processes to end up reading partially written file content... And this code @rdicroce tested, while does, does not prevent this So, maybe IF win old_code ELSE new_code? Hm -- 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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786923#comment-17786923
]
ASF GitHub Bot commented on MRESOLVER-372:
--
rdicroce commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815195848
So for shits and giggles, I decided to paste the 1.6.0 file copy code into
the 1.9.x branch. Here's what it looks like:
```
public static CollocatedTempFile newTempFile(Path file) throws
IOException {
Path parent = requireNonNull(file.getParent(), "file must have
parent");
Files.createDirectories(parent);
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
@Override
public Path getPath() {
return tempFile;
}
@Override
public void move() throws IOException {
try (InputStream in = Files.newInputStream(tempFile);
OutputStream out = Files.newOutputStream(file)) {
copy(out, in);
}
}
@Override
public void close() throws IOException {
Files.deleteIfExists(tempFile);
}
};
}
private static long copy( OutputStream os, InputStream is )
throws IOException
{
long total = 0L;
ByteBuffer buffer = ByteBuffer.allocate( 1024 * 32 );
byte[] array = buffer.array();
while ( true )
{
int bytes = is.read( array );
if ( bytes < 0 )
{
break;
}
os.write( array, 0, bytes );
total += bytes;
}
return total;
}
```
Then I tried the same test as before. This code did NOT throw an exception.
And it appears to have actually worked. The file on disk has different
timestamps inside the JAR. Eclipse even seems to have noticed that it changed,
although that's difficult to say for sure.
Why does this work and the other code doesn't? I have no idea. Probably has
something to do with the fact that this code actually copies the content of the
file, byte by byte. Whereas the MoveFile approach probably only tries to change
the actual location on disk that the file points to.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
rdicroce commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815195848
So for shits and giggles, I decided to paste the 1.6.0 file copy code into
the 1.9.x branch. Here's what it looks like:
```
public static CollocatedTempFile newTempFile(Path file) throws
IOException {
Path parent = requireNonNull(file.getParent(), "file must have
parent");
Files.createDirectories(parent);
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
@Override
public Path getPath() {
return tempFile;
}
@Override
public void move() throws IOException {
try (InputStream in = Files.newInputStream(tempFile);
OutputStream out = Files.newOutputStream(file)) {
copy(out, in);
}
}
@Override
public void close() throws IOException {
Files.deleteIfExists(tempFile);
}
};
}
private static long copy( OutputStream os, InputStream is )
throws IOException
{
long total = 0L;
ByteBuffer buffer = ByteBuffer.allocate( 1024 * 32 );
byte[] array = buffer.array();
while ( true )
{
int bytes = is.read( array );
if ( bytes < 0 )
{
break;
}
os.write( array, 0, bytes );
total += bytes;
}
return total;
}
```
Then I tried the same test as before. This code did NOT throw an exception.
And it appears to have actually worked. The file on disk has different
timestamps inside the JAR. Eclipse even seems to have noticed that it changed,
although that's difficult to say for sure.
Why does this work and the other code doesn't? I have no idea. Probably has
something to do with the fact that this code actually copies the content of the
file, byte by byte. Whereas the MoveFile approach probably only tries to change
the actual location on disk that the file points to.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786895#comment-17786895
]
Tamas Cservenak commented on MRESOLVER-372:
---
So far as I see, the statement "Download fails if file is currently in use
under windows" was true for any resolver (when on windows), even the pre-1.9
resolver did fail, it did not "forgive" or swallow IOExceptions. So this issue
not that is unrelated to locking, but is "red herring" in general, as this was
happening before resolver 1.9, with resolver 1.9, and will happen after it as
well. Simply put, let Maven manage local repository ONLY, or, ask your OS
vendor to do something about this.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786893#comment-17786893
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815036588
Similarly, @laeubi i don't see pre1.9 resolver code as "forgiving" and
swallowing IOEx, here is the same method from 1.6.0:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.6.0/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultFileProcessor.java#L153
If target is open, line 166 would fail, no?
So to me it seems "when file is opened by something else" failed Resolver
1.6.0 as well. So, imho, this use case is red herring: we cannot do anything
here.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
cstamas commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1815036588 Similarly, @laeubi i don't see pre1.9 resolver code as "forgiving" and swallowing IOEx, here is the same method from 1.6.0: https://github.com/apache/maven-resolver/blob/maven-resolver-1.6.0/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultFileProcessor.java#L153 If target is open, line 166 would fail, no? So to me it seems "when file is opened by something else" failed Resolver 1.6.0 as well. So, imho, this use case is red herring: we cannot do anything here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786882#comment-17786882
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814992318
There is one use case I have no idea what to do with, but I do know what I
don't want to do:
> If a file is open for any reason, it can't be replaced. (on Windows)
In this case, if resolver would "silently give up" (for example an
installation attempt), it would mean it is _**intentionally** leaving your
local repository in an **inconsistent state**_. And this is unacceptable for
me. Hence, "ignoring IOExceptions" i consider as a non-option: no software
should intentionally make transition from "consistent" to "inconsistent" state.
Least I can do is implemented similar trick as for directory fsync, and make
resolver broken on windows. But this would imply, that we have to state
somewhere (release notes? site?) that "by design, resolver is not supported on
Windows"?
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
cstamas commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814992318 There is one use case I have no idea what to do with, but I do know what I don't want to do: > If a file is open for any reason, it can't be replaced. (on Windows) In this case, if resolver would "silently give up" (for example an installation attempt), it would mean it is _**intentionally** leaving your local repository in an **inconsistent state**_. And this is unacceptable for me. Hence, "ignoring IOExceptions" i consider as a non-option: no software should intentionally make transition from "consistent" to "inconsistent" state. Least I can do is implemented similar trick as for directory fsync, and make resolver broken on windows. But this would imply, that we have to state somewhere (release notes? site?) that "by design, resolver is not supported on Windows"? -- 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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786862#comment-17786862
]
ASF GitHub Bot commented on MRESOLVER-372:
--
gnodet commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1396050259
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
Review Comment:
Ok, so order is specified as being the reversed order of declaration, which
makes sense of course, so this should work because the BufferedOutputStream
will be closed just before the CollocatedTempFile.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
gnodet commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1396050259
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
Review Comment:
Ok, so order is specified as being the reversed order of declaration, which
makes sense of course, so this should work because the BufferedOutputStream
will be closed just before the CollocatedTempFile.
--
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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786859#comment-17786859
]
ASF GitHub Bot commented on MRESOLVER-372:
--
gnodet commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1396043178
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
Review Comment:
This is not safe. The `CollocatedTempFile` should provide a way to create
an `OutputStream` so that it can be closed before the `CollocatedTempFile`.
This is needed so that buffered streams are fully written to disk before moving
the file.
See
https://github.com/apache/maven-resolver/blob/e721b01be9576396e36e4167da337180b44e38e9/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultFileProcessor.java#L90-L96
The code is using a `BufferedOutputStream` so that it may not be completely
written to the disk. I'm not sure if there's any guarantee on the ordering of
the `close()` methods in the `try/finally` block.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
gnodet commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1396043178
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
Review Comment:
This is not safe. The `CollocatedTempFile` should provide a way to create
an `OutputStream` so that it can be closed before the `CollocatedTempFile`.
This is needed so that buffered streams are fully written to disk before moving
the file.
See
https://github.com/apache/maven-resolver/blob/e721b01be9576396e36e4167da337180b44e38e9/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultFileProcessor.java#L90-L96
The code is using a `BufferedOutputStream` so that it may not be completely
written to the disk. I'm not sure if there's any guarantee on the ordering of
the `close()` methods in the `try/finally` block.
--
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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786854#comment-17786854
]
ASF GitHub Bot commented on MRESOLVER-372:
--
gnodet commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1396036846
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
+fsyncFile(tempFile);
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+if (!IS_WINDOWS) {
+fsyncParent(tempFile);
+}
Review Comment:
If the `fsync` is not important, then this commit is nearly wrong. If
should simply be a matter of making sure the calls are ordered correctly ?
https://github.com/apache/maven-resolver/blob/c6b8a728727220a4362b45e50317deb40562c0bc/maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/BasicRepositoryConnector.java#L496
The call to move should be performed after the commit which actually writes
to the file ?
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
gnodet commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1396036846
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
+fsyncFile(tempFile);
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+if (!IS_WINDOWS) {
+fsyncParent(tempFile);
+}
Review Comment:
If the `fsync` is not important, then this commit is nearly wrong. If
should simply be a matter of making sure the calls are ordered correctly ?
https://github.com/apache/maven-resolver/blob/c6b8a728727220a4362b45e50317deb40562c0bc/maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/BasicRepositoryConnector.java#L496
The call to move should be performed after the commit which actually writes
to the file ?
--
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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786841#comment-17786841
]
ASF GitHub Bot commented on MRESOLVER-372:
--
rdicroce commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814805054
I tested this on Windows and it does not fix the problem. The way I tested
it was:
1. Build the #365 branch.
2. Replace all of the maven-resolver JARs in Eclipse's
plugins\org.eclipse.m2e.maven.runtime_3.9.400.20230826-0755\jars directory by
renaming the originals to have .orig on the end, and then changing the names of
the built JARs to match the 1.9.14 filenames. I'm using Eclipse 2023-09.
3. Open a workspace containing project A. This project has a SNAPSHOT
dependency on project B.
4. Open a second workspace containing project B.
5. Run a 'clean install' build of project B.
I agree with @laeubi's assessment. If a file is open for any reason, it
can't be replaced. At least, I've never heard of any way of doing it on
Windows. Linux is a different story.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
rdicroce commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814805054 I tested this on Windows and it does not fix the problem. The way I tested it was: 1. Build the #365 branch. 2. Replace all of the maven-resolver JARs in Eclipse's plugins\org.eclipse.m2e.maven.runtime_3.9.400.20230826-0755\jars directory by renaming the originals to have .orig on the end, and then changing the names of the built JARs to match the 1.9.14 filenames. I'm using Eclipse 2023-09. 3. Open a workspace containing project A. This project has a SNAPSHOT dependency on project B. 4. Open a second workspace containing project B. 5. Run a 'clean install' build of project B. I agree with @laeubi's assessment. If a file is open for any reason, it can't be replaced. At least, I've never heard of any way of doing it on Windows. Linux is a different story. -- 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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786778#comment-17786778
]
Tamas Cservenak commented on MRESOLVER-372:
---
I'd be very grateful for some feedback of those who use Windows...
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786776#comment-17786776
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1395807029
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
+fsyncFile(tempFile);
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+if (!IS_WINDOWS) {
+fsyncParent(tempFile);
+}
+}
Files.deleteIfExists(tempFile);
}
};
}
+/**
+ * Performs fsync: makes sure no OS "dirty buffers" exist for given file.
+ *
+ * @param target Path that must not be {@code null}, must exist as plain
file.
+ */
+private static void fsyncFile(Path target) throws IOException {
+try (FileChannel file = FileChannel.open(target,
StandardOpenOption.WRITE)) {
+file.force(true);
+}
Review Comment:
Lucene code in case of file does not ignore exception, so I think we should
not either.
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
+fsyncFile(tempFile);
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+if (!IS_WINDOWS) {
+fsyncParent(tempFile);
+}
Review Comment:
https://github.com/apache/maven-resolver/pull/364#issuecomment-1814516829
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclip
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
cstamas commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1395807029
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
+fsyncFile(tempFile);
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+if (!IS_WINDOWS) {
+fsyncParent(tempFile);
+}
+}
Files.deleteIfExists(tempFile);
}
};
}
+/**
+ * Performs fsync: makes sure no OS "dirty buffers" exist for given file.
+ *
+ * @param target Path that must not be {@code null}, must exist as plain
file.
+ */
+private static void fsyncFile(Path target) throws IOException {
+try (FileChannel file = FileChannel.open(target,
StandardOpenOption.WRITE)) {
+file.force(true);
+}
Review Comment:
Lucene code in case of file does not ignore exception, so I think we should
not either.
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
+fsyncFile(tempFile);
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+if (!IS_WINDOWS) {
+fsyncParent(tempFile);
+}
Review Comment:
https://github.com/apache/maven-resolver/pull/364#issuecomment-1814516829
--
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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786774#comment-17786774
]
ASF GitHub Bot commented on MRESOLVER-372:
--
slawekjaranowski commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1395786775
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
+fsyncFile(tempFile);
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+if (!IS_WINDOWS) {
+fsyncParent(tempFile);
+}
+}
Files.deleteIfExists(tempFile);
}
};
}
+/**
+ * Performs fsync: makes sure no OS "dirty buffers" exist for given file.
+ *
+ * @param target Path that must not be {@code null}, must exist as plain
file.
+ */
+private static void fsyncFile(Path target) throws IOException {
+try (FileChannel file = FileChannel.open(target,
StandardOpenOption.WRITE)) {
+file.force(true);
+}
Review Comment:
should we also ignore exception here as is in `fsyncParent`?
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
slawekjaranowski commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1395786775
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
+fsyncFile(tempFile);
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+if (!IS_WINDOWS) {
+fsyncParent(tempFile);
+}
+}
Files.deleteIfExists(tempFile);
}
};
}
+/**
+ * Performs fsync: makes sure no OS "dirty buffers" exist for given file.
+ *
+ * @param target Path that must not be {@code null}, must exist as plain
file.
+ */
+private static void fsyncFile(Path target) throws IOException {
+try (FileChannel file = FileChannel.open(target,
StandardOpenOption.WRITE)) {
+file.force(true);
+}
Review Comment:
should we also ignore exception here as is in `fsyncParent`?
--
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-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786773#comment-17786773
]
ASF GitHub Bot commented on MRESOLVER-372:
--
slawekjaranowski commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1395782170
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
+fsyncFile(tempFile);
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+if (!IS_WINDOWS) {
+fsyncParent(tempFile);
+}
Review Comment:
Why here ... delete tempFile can also change directory content ... so maybe
should be sync after delete
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-319) Improve (documentation on) DocumentRenderer interface/DocumentRenderingContext class
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786772#comment-17786772
]
ASF GitHub Bot commented on DOXIASITETOOLS-319:
---
michael-o commented on PR #118:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/118#issuecomment-1814542992
@hboutemy, any objections?
> Improve (documentation on) DocumentRenderer
> interface/DocumentRenderingContext class
>
>
> Key: DOXIASITETOOLS-319
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-319
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Site renderer
>Affects Versions: 2.0.0-M13
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0-M16
>
>
> This is a followup to MSHARED-1326.
> {{#getOutputName()}} does not clearly say that is actually an optional base
> *path* and base name (base location) of the report item from a reporting
> output directory. It needs at least a doc update and maybe even a rename to
> {{#getOutputPath()}}/{{#getOutputPathLocation()}}?
> Same applies for {{#getInputName()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
slawekjaranowski commented on code in PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#discussion_r1395782170
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -98,23 +108,59 @@ public static CollocatedTempFile newTempFile(Path file)
throws IOException {
Path tempFile = parent.resolve(file.getFileName() + "."
+
Long.toUnsignedString(ThreadLocalRandom.current().nextLong()) + ".tmp");
return new CollocatedTempFile() {
+private final AtomicBoolean wantsMove = new AtomicBoolean(false);
+
@Override
public Path getPath() {
return tempFile;
}
@Override
-public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+public void move() {
+wantsMove.set(true);
}
@Override
public void close() throws IOException {
+if (wantsMove.get() && Files.isReadable(tempFile)) {
+fsyncFile(tempFile);
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+if (!IS_WINDOWS) {
+fsyncParent(tempFile);
+}
Review Comment:
Why here ... delete tempFile can also change directory content ... so maybe
should be sync after delete
--
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
Re: [PR] [DOXIASITETOOLS-319] Improve (documentation on) DocumentRenderer inte… [maven-doxia-sitetools]
michael-o commented on PR #118: URL: https://github.com/apache/maven-doxia-sitetools/pull/118#issuecomment-1814542992 @hboutemy, any objections? -- 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] (MSITE-990) org.eclipse.jetty.util.MultiException: Multiple exceptions
[
https://issues.apache.org/jira/browse/MSITE-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786770#comment-17786770
]
Michael Osipov commented on MSITE-990:
--
Ideally, fix the component or try to exclude the dependency. That may work.
> org.eclipse.jetty.util.MultiException: Multiple exceptions
> --
>
> Key: MSITE-990
> URL: https://issues.apache.org/jira/browse/MSITE-990
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:run
>Affects Versions: 3.12.1
> Environment: Windows 10 and git bash
>Reporter: mikael petterson
>Priority: Major
> Attachments: multi_exceptions.log, mvn_site_3.12.1.log
>
>
> mvn --version
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: C:\apache-maven-3.8.5
> Java version: 17.0.6, vendor: Azul Systems, Inc., runtime: C:\Program
> Files\Zulu\zulu-17
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> When trying to run:
> mvn site:run
> {code:java}
> [INFO] jetty-9.4.46.v20220331; built: 2022-03-31T16:38:08.030Z; git:
> bc17a0369a11ecf40bb92c839b9ef0a8ac50ea18; jvm 17.0.6+10-LTS
> [INFO] NO JSP Support for /, did not find
> org.eclipse.jetty.jsp.JettyJspServlet
> [INFO] DefaultSessionIdManager workerName=node0
> [INFO] No SessionScavenger set, using defaults
> [INFO] node0 Scavenging every 66ms
> [WARNING] Failed startup of context
> o.e.j.w.WebAppContext@64d42d3d{/,file:///C:/Users/userid/git/my-app/target/site-webapp/,UNAVAILABLE}
> org.eclipse.jetty.util.MultiException: Multiple exceptions
> at org.eclipse.jetty.util.MultiException.ifExceptionThrow
> (MultiException.java:122)
> at org.eclipse.jetty.servlet.ServletHandler.initialize
> (ServletHandler.java:757)
> at org.eclipse.jetty.servlet.ServletContextHandler.startContext
> (ServletContextHandler.java:379)
> at org.eclipse.jetty.webapp.WebAppContext.startWebapp
> (WebAppContext.java:1449)
> at org.eclipse.jetty.webapp.WebAppContext.startContext
> (WebAppContext.java:1414)
> at org.eclipse.jetty.server.handler.ContextHandler.doStart
> (ContextHandler.java:916)
> at org.eclipse.jetty.servlet.ServletContextHandler.doStart
> (ServletContextHandler.java:288)
> at org.eclipse.jetty.webapp.WebAppContext.doStart (WebAppContext.java:524)
> at org.eclipse.jetty.util.component.AbstractLifeCycle.start
> (AbstractLifeCycle.java:73)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.start
> (ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start (Server.java:423)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart
> (ContainerLifeCycle.java:110)
> at org.eclipse.jetty.server.handler.AbstractHandler.doStart
> (AbstractHandler.java:97)
> at org.eclipse.jetty.server.Server.doStart (Server.java:387)
> at org.eclipse.jetty.util.component.AbstractLifeCycle.start
> (AbstractLifeCycle.java:73)
> at org.apache.maven.plugins.site.run.SiteRunMojo.execute
> (SiteRunMojo.java:87)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786766#comment-17786766
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814516829
Frankly, I'd remove the fsync on directory, as unlike Lucene (that depends
on readability of new commit marker), Maven uses layout, so any other process
will calculate the path and go directly for artifact jar
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Fallback to non-atomic move on AccessDeniedEx [maven-resolver]
cstamas commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814516829 Frankly, I'd remove the fsync on directory, as unlike Lucene (that depends on readability of new commit marker), Maven uses layout, so any other process will calculate the path and go directly for artifact jar -- 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] (MARCHETYPES-76) maven-archetype-quickstart generates EOLed maven.compiler setup
[ https://issues.apache.org/jira/browse/MARCHETYPES-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786761#comment-17786761 ] ASF GitHub Bot commented on MARCHETYPES-76: --- judovana commented on PR #18: URL: https://github.com/apache/maven-archetypes/pull/18#issuecomment-1814472875 Note, that the PR is in real just: ``` -#compilerProperties( "1.7" ) +#compilerProperties( "1.8" ) ``` the rest is adjusting of tests to the new reality. Renaming s/8/7/g in names and s/1.8/1.7/g in theyrs pom.xml > maven-archetype-quickstart generates EOLed maven.compiler setup > > > Key: MARCHETYPES-76 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-76 > Project: Maven Archetype Bundles > Issue Type: Bug >Reporter: jiri vanek >Priority: Major > > The default imput to #compilerProperties is 1.7, which is making any > generated project to be not buildable with fresh jdk21. The default should > be1.8. Where jdk8 is still live and jdk21 is still comaptible with it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MARCHETYPES-76] maven-archetype-quickstart generates EOLed maven.compiler setup [maven-archetypes]
judovana commented on PR #18: URL: https://github.com/apache/maven-archetypes/pull/18#issuecomment-1814472875 Note, that the PR is in real just: ``` -#compilerProperties( "1.7" ) +#compilerProperties( "1.8" ) ``` the rest is adjusting of tests to the new reality. Renaming s/8/7/g in names and s/1.8/1.7/g in theyrs pom.xml -- 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] (MARCHETYPES-76) maven-archetype-quickstart generates EOLed maven.compiler setup
[ https://issues.apache.org/jira/browse/MARCHETYPES-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786760#comment-17786760 ] ASF GitHub Bot commented on MARCHETYPES-76: --- judovana opened a new pull request, #18: URL: https://github.com/apache/maven-archetypes/pull/18 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MARCHETYPES) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MARCHETYPES-XXX] SUMMARY`, where you replace `MARCHETYPES-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). > maven-archetype-quickstart generates EOLed maven.compiler setup > > > Key: MARCHETYPES-76 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-76 > Project: Maven Archetype Bundles > Issue Type: Bug >Reporter: jiri vanek >Priority: Major > > The default imput to #compilerProperties is 1.7, which is making any > generated project to be not buildable with fresh jdk21. The default should > be1.8. Where jdk8 is still live and jdk21 is still comaptible with it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MARCHETYPES-76] maven-archetype-quickstart generates EOLed maven.compiler setup [maven-archetypes]
judovana opened a new pull request, #18: URL: https://github.com/apache/maven-archetypes/pull/18 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MARCHETYPES) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MARCHETYPES-XXX] SUMMARY`, where you replace `MARCHETYPES-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MARCHETYPES-77) maven-archetype-quickstart ignores -DjavaCompilerVersion=XY and -DjunitVersion=AB commandline-passed properties
[ https://issues.apache.org/jira/browse/MARCHETYPES-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jiri vanek updated MARCHETYPES-77: -- Description: The javaCompilerVersion and junitVersion are correctly accepted from archetype.properties however they can not be set from commandline In addition, usage of archetype.properties is undocumented, and thus those two properties are practically immutable was:The javaCompilerVersion and junitVersion are correctly accepted from archetype.properties however they can not be set from commandline > maven-archetype-quickstart ignores -DjavaCompilerVersion=XY and > -DjunitVersion=AB commandline-passed properties > > > Key: MARCHETYPES-77 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-77 > Project: Maven Archetype Bundles > Issue Type: Bug >Reporter: jiri vanek >Priority: Major > > The javaCompilerVersion and junitVersion are correctly accepted from > archetype.properties however they can not be set from commandline > > In addition, usage of archetype.properties is undocumented, and thus those > two properties are practically immutable -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MARCHETYPES-77) maven-archetype-quickstart ignores -DjavaCompilerVersion=XY and -DjunitVersion=AB commandline-passed properties
[ https://issues.apache.org/jira/browse/MARCHETYPES-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jiri vanek updated MARCHETYPES-77: -- Summary: maven-archetype-quickstart ignores -DjavaCompilerVersion=XY and -DjunitVersion=AB commandline-passed properties (was: maven-archetype-quickstart ignores -DjavaCompilerVersion=XY and -DjunitVersion=AB commandline switches) > maven-archetype-quickstart ignores -DjavaCompilerVersion=XY and > -DjunitVersion=AB commandline-passed properties > > > Key: MARCHETYPES-77 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-77 > Project: Maven Archetype Bundles > Issue Type: Bug >Reporter: jiri vanek >Priority: Major > > The javaCompilerVersion and junitVersion are correctly accepted from > archetype.properties however they can not be used from commandline -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MARCHETYPES-77) maven-archetype-quickstart ignores -DjavaCompilerVersion=XY and -DjunitVersion=AB commandline-passed properties
[ https://issues.apache.org/jira/browse/MARCHETYPES-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jiri vanek updated MARCHETYPES-77: -- Description: The javaCompilerVersion and junitVersion are correctly accepted from archetype.properties however they can not be set from commandline (was: The javaCompilerVersion and junitVersion are correctly accepted from archetype.properties however they can not be used from commandline) > maven-archetype-quickstart ignores -DjavaCompilerVersion=XY and > -DjunitVersion=AB commandline-passed properties > > > Key: MARCHETYPES-77 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-77 > Project: Maven Archetype Bundles > Issue Type: Bug >Reporter: jiri vanek >Priority: Major > > The javaCompilerVersion and junitVersion are correctly accepted from > archetype.properties however they can not be set from commandline -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MARCHETYPES-77) maven-archetype-quickstart ignores -DjavaCompilerVersion=XY and -DjunitVersion=AB commandline switches
jiri vanek created MARCHETYPES-77: - Summary: maven-archetype-quickstart ignores -DjavaCompilerVersion=XY and -DjunitVersion=AB commandline switches Key: MARCHETYPES-77 URL: https://issues.apache.org/jira/browse/MARCHETYPES-77 Project: Maven Archetype Bundles Issue Type: Bug Reporter: jiri vanek The javaCompilerVersion and junitVersion are correctly accepted from archetype.properties however they can not be used from commandline -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MARCHETYPES-76) maven-archetype-quickstart generates EOLed maven.compiler setup
jiri vanek created MARCHETYPES-76: - Summary: maven-archetype-quickstart generates EOLed maven.compiler setup Key: MARCHETYPES-76 URL: https://issues.apache.org/jira/browse/MARCHETYPES-76 Project: Maven Archetype Bundles Issue Type: Bug Reporter: jiri vanek The default imput to #compilerProperties is 1.7, which is making any generated project to be not buildable with fresh jdk21. The default should be1.8. Where jdk8 is still live and jdk21 is still comaptible with it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786741#comment-17786741
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814394810
@slawekjaranowski @laeubi reworked fully...
After a LOT of reading, seemingly we had several issues:
* move() call literally MOVED the file, but the writer of that file may kept
the file still opened for write
* due that above and also due lack of fsync() Windows MAY detect "dirty
buffers", hence AccessDeniedEx
* on non-Windows is recommended to fsync() the containing directory as well
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Fallback to non-atomic move on AccessDeniedEx [maven-resolver]
cstamas commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814394810 @slawekjaranowski @laeubi reworked fully... After a LOT of reading, seemingly we had several issues: * move() call literally MOVED the file, but the writer of that file may kept the file still opened for write * due that above and also due lack of fsync() Windows MAY detect "dirty buffers", hence AccessDeniedEx * on non-Windows is recommended to fsync() the containing directory as well -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Add some love to the API [maven]
gnodet opened a new pull request, #1310: URL: https://github.com/apache/maven/pull/1310 (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] [Commented] (MSITE-990) org.eclipse.jetty.util.MultiException: Multiple exceptions
[
https://issues.apache.org/jira/browse/MSITE-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786716#comment-17786716
]
mikael petterson commented on MSITE-990:
[~michael-o] so what should I do ?
> org.eclipse.jetty.util.MultiException: Multiple exceptions
> --
>
> Key: MSITE-990
> URL: https://issues.apache.org/jira/browse/MSITE-990
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:run
>Affects Versions: 3.12.1
> Environment: Windows 10 and git bash
>Reporter: mikael petterson
>Priority: Major
> Attachments: multi_exceptions.log, mvn_site_3.12.1.log
>
>
> mvn --version
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: C:\apache-maven-3.8.5
> Java version: 17.0.6, vendor: Azul Systems, Inc., runtime: C:\Program
> Files\Zulu\zulu-17
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> When trying to run:
> mvn site:run
> {code:java}
> [INFO] jetty-9.4.46.v20220331; built: 2022-03-31T16:38:08.030Z; git:
> bc17a0369a11ecf40bb92c839b9ef0a8ac50ea18; jvm 17.0.6+10-LTS
> [INFO] NO JSP Support for /, did not find
> org.eclipse.jetty.jsp.JettyJspServlet
> [INFO] DefaultSessionIdManager workerName=node0
> [INFO] No SessionScavenger set, using defaults
> [INFO] node0 Scavenging every 66ms
> [WARNING] Failed startup of context
> o.e.j.w.WebAppContext@64d42d3d{/,file:///C:/Users/userid/git/my-app/target/site-webapp/,UNAVAILABLE}
> org.eclipse.jetty.util.MultiException: Multiple exceptions
> at org.eclipse.jetty.util.MultiException.ifExceptionThrow
> (MultiException.java:122)
> at org.eclipse.jetty.servlet.ServletHandler.initialize
> (ServletHandler.java:757)
> at org.eclipse.jetty.servlet.ServletContextHandler.startContext
> (ServletContextHandler.java:379)
> at org.eclipse.jetty.webapp.WebAppContext.startWebapp
> (WebAppContext.java:1449)
> at org.eclipse.jetty.webapp.WebAppContext.startContext
> (WebAppContext.java:1414)
> at org.eclipse.jetty.server.handler.ContextHandler.doStart
> (ContextHandler.java:916)
> at org.eclipse.jetty.servlet.ServletContextHandler.doStart
> (ServletContextHandler.java:288)
> at org.eclipse.jetty.webapp.WebAppContext.doStart (WebAppContext.java:524)
> at org.eclipse.jetty.util.component.AbstractLifeCycle.start
> (AbstractLifeCycle.java:73)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.start
> (ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start (Server.java:423)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart
> (ContainerLifeCycle.java:110)
> at org.eclipse.jetty.server.handler.AbstractHandler.doStart
> (AbstractHandler.java:97)
> at org.eclipse.jetty.server.Server.doStart (Server.java:387)
> at org.eclipse.jetty.util.component.AbstractLifeCycle.start
> (AbstractLifeCycle.java:73)
> at org.apache.maven.plugins.site.run.SiteRunMojo.execute
> (SiteRunMojo.java:87)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.cla
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786713#comment-17786713
]
ASF GitHub Bot commented on MRESOLVER-372:
--
laeubi commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814261616
> I really hope "atomic on windows" will NOT replace the file and then throw
😄 otherwise, am really unsure what that OS is able to guarantee for at all.
You can just look into the Widnows File system implementation of the JDK to
see whats going on.
> If you check older resolvers (and let's assume "they worked"), they used
pre-nio2 copy+delete
"Old" code simply ignored when replace goes wrong, so you have the problem
that afterwards you maybe use the old file. I don't say that new way is "wrong"
just that not using atomic move does not solve the problem reported in the
issue that is some other process (or the current) is currently opend that file
and in such case you cam't overwrite/delete/replace/move ... to that file under
windows.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Fallback to non-atomic move on AccessDeniedEx [maven-resolver]
laeubi commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814261616 > I really hope "atomic on windows" will NOT replace the file and then throw 😄 otherwise, am really unsure what that OS is able to guarantee for at all. You can just look into the Widnows File system implementation of the JDK to see whats going on. > If you check older resolvers (and let's assume "they worked"), they used pre-nio2 copy+delete "Old" code simply ignored when replace goes wrong, so you have the problem that afterwards you maybe use the old file. I don't say that new way is "wrong" just that not using atomic move does not solve the problem reported in the issue that is some other process (or the current) is currently opend that file and in such case you cam't overwrite/delete/replace/move ... to that file under windows. -- 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] (MINSTALL-194) Fail to install snapshot artifact when clean phase is used
[
https://issues.apache.org/jira/browse/MINSTALL-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786710#comment-17786710
]
Candice Tosi Michelon edited comment on MINSTALL-194 at 11/16/23 11:20 AM:
---
This issue was fixed by removing the tag 'aggregate' from pmd plugin
configuration.
!image-2023-11-16-08-15-07-597.png!
This solution was based on [maven PMD plugin team's
suggestion|https://issues.apache.org/jira/browse/MPMD-277?focusedCommentId=16814718&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16814718]
Now all our builds are running smoothly again.
was (Author: JIRAUSER302781):
This issue was fixed by removing the tag 'aggregate' from pmd plugin
configuration.
!image-2023-11-16-08-15-07-597.png!
This solution was based on maven PMD plugin team's suggestion
Now all our builds are running smoothly again.
> Fail to install snapshot artifact when clean phase is used
> --
>
> Key: MINSTALL-194
> URL: https://issues.apache.org/jira/browse/MINSTALL-194
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 3.1.1
> Environment: Apache Maven 3.9.5
> (57804ffe001d7215b5e7bcb531cf83df38f93546)
> Maven home: C:\Program Files\Maven\apache-maven-3.9.5-bin\apache-maven-3.9.5
> Java version: 11.0.18, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk-11
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Candice Tosi Michelon
>Priority: Minor
> Attachments: StackTrace.txt, StackTraceDebug.txt,
> image-2023-11-16-08-15-07-597.png
>
>
> {*}After ugrading maven from version 3.6.3 to 3.9.4 a few maven projects
> started failing in the install phase with the error below{*}:
> Failed to install artifact xx:jar:1.1-SNAPSHOT:
> x-1.1-SNAPSHOT.jar.3154215231322123456.tmp -> x-1.1-SNAPSHOT.jar ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-install-plugin:3.1.1:install
> (default-install) on project x: Failed to install artifact
> x:jar:1.1-SNAPSHOT: x-1.1-SNAPSHOT.jar
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> Caused by: org.eclipse.aether.installation.InstallationException:
> Caused by: java.nio.file.AccessDeniedException:
>
> *Command used:* mvn clean install
>
> *All the projects affected have the following characteristics:*
> * Multi-modules
> * The clean phase is used at least once
> * The pmd check is performed
> * A jar snapshot of the module already existis in the maven repository
> folder (.m2)
> This is not a blocker issue because *it is still possible to build the
> projects and install the snapshots* in the local repository if the follwoing
> options are used:
> * Option 1: Avoid using the clean phase. Use only 'mvn install'.
> * Option 2: Use the following mvn commands:
> ** mvn clean
> ** mvn install -N
> ** mvn install -rf
> * Option 3: Use the following commands:
> ** mvn clean install (the build will fail trying to install the jar of one
> of the modules in the .m2 folder)
> ** mvn install -rf installed>
> * Option 4: skip pmd check:
> ** mvn clean install -Dpmd.skip=true
> * Option 5: delete the jar snapshots previously installed in the maven
> repository folder.
> I can't provide a sample project or pom because I was not able to reproduce
> the issue in a new project. Also, there are other projects with the same
> characteristcs that does not present the problem, I could not identify any
> significant difference between them as dependencies and plugins versions, as
> well as build configuration, are mostly the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINSTALL-194) Fail to install snapshot artifact when clean phase is used
[
https://issues.apache.org/jira/browse/MINSTALL-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786710#comment-17786710
]
Candice Tosi Michelon commented on MINSTALL-194:
This issue was fixed by removing the tag 'aggregate' from pmd plugin
configuration.
!image-2023-11-16-08-15-07-597.png!
This solution was based on maven PMD plugin team's suggestion
Now all our builds are running smoothly again.
> Fail to install snapshot artifact when clean phase is used
> --
>
> Key: MINSTALL-194
> URL: https://issues.apache.org/jira/browse/MINSTALL-194
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 3.1.1
> Environment: Apache Maven 3.9.5
> (57804ffe001d7215b5e7bcb531cf83df38f93546)
> Maven home: C:\Program Files\Maven\apache-maven-3.9.5-bin\apache-maven-3.9.5
> Java version: 11.0.18, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk-11
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Candice Tosi Michelon
>Priority: Minor
> Attachments: StackTrace.txt, StackTraceDebug.txt,
> image-2023-11-16-08-15-07-597.png
>
>
> {*}After ugrading maven from version 3.6.3 to 3.9.4 a few maven projects
> started failing in the install phase with the error below{*}:
> Failed to install artifact xx:jar:1.1-SNAPSHOT:
> x-1.1-SNAPSHOT.jar.3154215231322123456.tmp -> x-1.1-SNAPSHOT.jar ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-install-plugin:3.1.1:install
> (default-install) on project x: Failed to install artifact
> x:jar:1.1-SNAPSHOT: x-1.1-SNAPSHOT.jar
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> Caused by: org.eclipse.aether.installation.InstallationException:
> Caused by: java.nio.file.AccessDeniedException:
>
> *Command used:* mvn clean install
>
> *All the projects affected have the following characteristics:*
> * Multi-modules
> * The clean phase is used at least once
> * The pmd check is performed
> * A jar snapshot of the module already existis in the maven repository
> folder (.m2)
> This is not a blocker issue because *it is still possible to build the
> projects and install the snapshots* in the local repository if the follwoing
> options are used:
> * Option 1: Avoid using the clean phase. Use only 'mvn install'.
> * Option 2: Use the following mvn commands:
> ** mvn clean
> ** mvn install -N
> ** mvn install -rf
> * Option 3: Use the following commands:
> ** mvn clean install (the build will fail trying to install the jar of one
> of the modules in the .m2 folder)
> ** mvn install -rf installed>
> * Option 4: skip pmd check:
> ** mvn clean install -Dpmd.skip=true
> * Option 5: delete the jar snapshots previously installed in the maven
> repository folder.
> I can't provide a sample project or pom because I was not able to reproduce
> the issue in a new project. Also, there are other projects with the same
> characteristcs that does not present the problem, I could not identify any
> significant difference between them as dependencies and plugins versions, as
> well as build configuration, are mostly the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINSTALL-194) Fail to install snapshot artifact when clean phase is used
[
https://issues.apache.org/jira/browse/MINSTALL-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Candice Tosi Michelon updated MINSTALL-194:
---
Attachment: image-2023-11-16-08-15-07-597.png
> Fail to install snapshot artifact when clean phase is used
> --
>
> Key: MINSTALL-194
> URL: https://issues.apache.org/jira/browse/MINSTALL-194
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 3.1.1
> Environment: Apache Maven 3.9.5
> (57804ffe001d7215b5e7bcb531cf83df38f93546)
> Maven home: C:\Program Files\Maven\apache-maven-3.9.5-bin\apache-maven-3.9.5
> Java version: 11.0.18, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk-11
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Candice Tosi Michelon
>Priority: Minor
> Attachments: StackTrace.txt, StackTraceDebug.txt,
> image-2023-11-16-08-15-07-597.png
>
>
> {*}After ugrading maven from version 3.6.3 to 3.9.4 a few maven projects
> started failing in the install phase with the error below{*}:
> Failed to install artifact xx:jar:1.1-SNAPSHOT:
> x-1.1-SNAPSHOT.jar.3154215231322123456.tmp -> x-1.1-SNAPSHOT.jar ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-install-plugin:3.1.1:install
> (default-install) on project x: Failed to install artifact
> x:jar:1.1-SNAPSHOT: x-1.1-SNAPSHOT.jar
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> Caused by: org.eclipse.aether.installation.InstallationException:
> Caused by: java.nio.file.AccessDeniedException:
>
> *Command used:* mvn clean install
>
> *All the projects affected have the following characteristics:*
> * Multi-modules
> * The clean phase is used at least once
> * The pmd check is performed
> * A jar snapshot of the module already existis in the maven repository
> folder (.m2)
> This is not a blocker issue because *it is still possible to build the
> projects and install the snapshots* in the local repository if the follwoing
> options are used:
> * Option 1: Avoid using the clean phase. Use only 'mvn install'.
> * Option 2: Use the following mvn commands:
> ** mvn clean
> ** mvn install -N
> ** mvn install -rf
> * Option 3: Use the following commands:
> ** mvn clean install (the build will fail trying to install the jar of one
> of the modules in the .m2 folder)
> ** mvn install -rf installed>
> * Option 4: skip pmd check:
> ** mvn clean install -Dpmd.skip=true
> * Option 5: delete the jar snapshots previously installed in the maven
> repository folder.
> I can't provide a sample project or pom because I was not able to reproduce
> the issue in a new project. Also, there are other projects with the same
> characteristcs that does not present the problem, I could not identify any
> significant difference between them as dependencies and plugins versions, as
> well as build configuration, are mostly the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MRESOLVER-372:
-
Assignee: Tamas Cservenak
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSITE-990) org.eclipse.jetty.util.MultiException: Multiple exceptions
[
https://issues.apache.org/jira/browse/MSITE-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSITE-990:
-
Fix Version/s: (was: waiting-for-feedback)
> org.eclipse.jetty.util.MultiException: Multiple exceptions
> --
>
> Key: MSITE-990
> URL: https://issues.apache.org/jira/browse/MSITE-990
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:run
>Affects Versions: 3.12.1
> Environment: Windows 10 and git bash
>Reporter: mikael petterson
>Priority: Major
> Attachments: multi_exceptions.log, mvn_site_3.12.1.log
>
>
> mvn --version
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: C:\apache-maven-3.8.5
> Java version: 17.0.6, vendor: Azul Systems, Inc., runtime: C:\Program
> Files\Zulu\zulu-17
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> When trying to run:
> mvn site:run
> {code:java}
> [INFO] jetty-9.4.46.v20220331; built: 2022-03-31T16:38:08.030Z; git:
> bc17a0369a11ecf40bb92c839b9ef0a8ac50ea18; jvm 17.0.6+10-LTS
> [INFO] NO JSP Support for /, did not find
> org.eclipse.jetty.jsp.JettyJspServlet
> [INFO] DefaultSessionIdManager workerName=node0
> [INFO] No SessionScavenger set, using defaults
> [INFO] node0 Scavenging every 66ms
> [WARNING] Failed startup of context
> o.e.j.w.WebAppContext@64d42d3d{/,file:///C:/Users/userid/git/my-app/target/site-webapp/,UNAVAILABLE}
> org.eclipse.jetty.util.MultiException: Multiple exceptions
> at org.eclipse.jetty.util.MultiException.ifExceptionThrow
> (MultiException.java:122)
> at org.eclipse.jetty.servlet.ServletHandler.initialize
> (ServletHandler.java:757)
> at org.eclipse.jetty.servlet.ServletContextHandler.startContext
> (ServletContextHandler.java:379)
> at org.eclipse.jetty.webapp.WebAppContext.startWebapp
> (WebAppContext.java:1449)
> at org.eclipse.jetty.webapp.WebAppContext.startContext
> (WebAppContext.java:1414)
> at org.eclipse.jetty.server.handler.ContextHandler.doStart
> (ContextHandler.java:916)
> at org.eclipse.jetty.servlet.ServletContextHandler.doStart
> (ServletContextHandler.java:288)
> at org.eclipse.jetty.webapp.WebAppContext.doStart (WebAppContext.java:524)
> at org.eclipse.jetty.util.component.AbstractLifeCycle.start
> (AbstractLifeCycle.java:73)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.start
> (ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start (Server.java:423)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart
> (ContainerLifeCycle.java:110)
> at org.eclipse.jetty.server.handler.AbstractHandler.doStart
> (AbstractHandler.java:97)
> at org.eclipse.jetty.server.Server.doStart (Server.java:387)
> at org.eclipse.jetty.util.component.AbstractLifeCycle.start
> (AbstractLifeCycle.java:73)
> at org.apache.maven.plugins.site.run.SiteRunMojo.execute
> (SiteRunMojo.java:87)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (
[jira] [Closed] (MSITE-990) org.eclipse.jetty.util.MultiException: Multiple exceptions
[
https://issues.apache.org/jira/browse/MSITE-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSITE-990.
Resolution: Information Provided
Look at the output:
{noformat}
[DEBUG]org.tinyjee.dim:doxia-include-macro:jar:1.1:runtime
[DEBUG] org.mozilla:rhino:jar:1.7R3:runtime
[DEBUG] com.thoughtworks.qdox:qdox:jar:1.12:runtime
[DEBUG] net.sourceforge.jchardet:jchardet:jar:1.0:runtime
[DEBUG] org.codehaus.jackson:jackson-core-asl:jar:1.9.0:runtime
[DEBUG] org.apache.xmlgraphics:batik-transcoder:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:fop:jar:0.94:runtime
[DEBUG] org.apache.xmlgraphics:xmlgraphics-commons:jar:1.2:runtime
[DEBUG]
org.apache.avalon.framework:avalon-framework-api:jar:4.3.1:runtime
[DEBUG]
org.apache.avalon.framework:avalon-framework-impl:jar:4.3.1:runtime
[DEBUG] org.apache.xmlgraphics:batik-awt-util:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-bridge:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-anim:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-css:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-parser:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-dom:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-gvt:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-svggen:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-util:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-xml:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-script:jar:1.7:runtime
[DEBUG] org.apache.xmlgraphics:batik-ext:jar:1.7:runtime
[DEBUG] javax.xml.bind:jaxb-api:jar:2.1:runtime
[DEBUG] javax.xml.stream:stax-api:jar:1.0-2:runtime
[DEBUG] javax.activation:activation:jar:1.1:runtime
[DEBUG] com.sun.xml.bind:jaxb-impl:jar:2.1.13:runtime
[DEBUG] com.sun.xml.bind:jaxb-xjc:jar:2.1.13:runtime
[DEBUG] org.apache.velocity:velocity-tools:jar:2.0:compile
[DEBUG] commons-beanutils:commons-beanutils:jar:1.7.0:compile
[DEBUG] commons-digester:commons-digester:jar:1.8:compile
[DEBUG] commons-chain:commons-chain:jar:1.1:compile
[DEBUG] commons-logging:commons-logging:jar:1.1:compile
[DEBUG] javax.servlet:servlet-api:jar:2.3:compile
{noformat}
This one pulls in Servlet API 2.3 which lacks:
https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletContext.html#createServlet(java.lang.Class).
Jetty 9.4 needs Servlet 3.1 API.
Here is the the broken CP for Jetty ({{site:run}}):
{noformat}
org/apache/maven/plugins/maven-site-plugin/3.12.1/maven-site-plugin-3.12.1.jar
org/tinyjee/dim/doxia-include-macro/1.1/doxia-include-macro-1.1.jar
org/mozilla/rhino/1.7R3/rhino-1.7R3.jar
com/thoughtworks/qdox/qdox/1.12/qdox-1.12.jar
net/sourceforge/jchardet/jchardet/1.0/jchardet-1.0.jar
org/codehaus/jackson/jackson-core-asl/1.9.0/jackson-core-asl-1.9.0.jar
org/apache/xmlgraphics/batik-transcoder/1.7/batik-transcoder-1.7.jar
org/apache/xmlgraphics/fop/0.94/fop-0.94.jar
org/apache/xmlgraphics/xmlgraphics-commons/1.2/xmlgraphics-commons-1.2.jar
org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1.jar
org/apache/avalon/framework/avalon-framework-impl/4.3.1/avalon-framework-impl-4.3.1.jar
org/apache/xmlgraphics/batik-awt-util/1.7/batik-awt-util-1.7.jar
org/apache/xmlgraphics/batik-bridge/1.7/batik-bridge-1.7.jar
org/apache/xmlgraphics/batik-anim/1.7/batik-anim-1.7.jar
org/apache/xmlgraphics/batik-css/1.7/batik-css-1.7.jar
org/apache/xmlgraphics/batik-parser/1.7/batik-parser-1.7.jar
org/apache/xmlgraphics/batik-dom/1.7/batik-dom-1.7.jar
org/apache/xmlgraphics/batik-gvt/1.7/batik-gvt-1.7.jar
org/apache/xmlgraphics/batik-svg-dom/1.7/batik-svg-dom-1.7.jar
org/apache/xmlgraphics/batik-svggen/1.7/batik-svggen-1.7.jar
org/apache/xmlgraphics/batik-util/1.7/batik-util-1.7.jar
org/apache/xmlgraphics/batik-xml/1.7/batik-xml-1.7.jar
org/apache/xmlgraphics/batik-script/1.7/batik-script-1.7.jar
org/apache/xmlgraphics/batik-ext/1.7/batik-ext-1.7.jar
javax/xml/bind/jaxb-api/2.1/jaxb-api-2.1.jar
javax/xml/stream/stax-api/1.0-2/stax-api-1.0-2.jar
javax/activation/activation/1.1/activation-1.1.jar
com/sun/xml/bind/jaxb-impl/2.1.13/jaxb-impl-2.1.13.jar
com/sun/xml/bind/jaxb-xjc/2.1.13/jaxb-xjc-2.1.13.jar
org/apache/velocity/velocity-tools/2.0/velocity-tools-2.0.jar
commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
commons-digester/commons-digester/1.8/commons-digester-1.8.jar
commons-chain/commons-chain/1.1/commons-chain-1.1.jar
commons-logging/commons-logging/1.1/commons-logging-1.1.jar
javax/servlet/servlet-api/2.3/servlet-api-2.3.jar
commons-validator/commons-validator/1.3.1/commons-validator-1.3.1.jar
dom4j/dom4j/1.1/dom4j-1.1.ja
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786702#comment-17786702
]
Tamas Cservenak commented on MRESOLVER-372:
---
So, just to recap:
* this has nothing to do with locking (we do not lock artifact or metadata
files)
* Pre 1.9 resolver did the very same thing, no change in this area (it also
normalized snapshots and replaced files on download/install).
* The ONLY change in this respect Resolver 1.9 did is change the move operation
implementation from pre-nio2 (as it was in 1.8) to nio2 + atomic (1.9).
So, my guts are telling me that the culprit is "atomic" on Windows. The reason
for atomic is to prevent partially written files being read by some other
process (ie IDE).
Also, according to that above, Resolver 1.8 was also normalizing snapshots and
was rewriting files (if existing) on install/resolve, hence very same problems
would be reported against it as well, but are not.
Hence, I am pretty sure it is "atomic" that is the culrpit of this issue...
Please test the PR.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786696#comment-17786696
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814162045
If you check older resolvers (and let's assume "they worked"), they used
pre-nio2 copy+delete, so they also did this but with a "window of possibility"
to allow other process to read partially written file. That was implemented
using pre-nio2 Java. All that resolver 1.9.x did, is to migrate the code to
nio2 AND use atomic. My guts are telling me that the "atomic" is the problem
here...
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Fallback to non-atomic move on AccessDeniedEx [maven-resolver]
cstamas commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814162045 If you check older resolvers (and let's assume "they worked"), they used pre-nio2 copy+delete, so they also did this but with a "window of possibility" to allow other process to read partially written file. That was implemented using pre-nio2 Java. All that resolver 1.9.x did, is to migrate the code to nio2 AND use atomic. My guts are telling me that the "atomic" is the problem here... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786695#comment-17786695
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas commented on PR #364:
URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814159292
I really hope "atomic on windows" will NOT replace the file and then throw
:smile: otherwise, am really unsure what that OS is able to guarantee for at
all.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> 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.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Fallback to non-atomic move on AccessDeniedEx [maven-resolver]
cstamas commented on PR #364: URL: https://github.com/apache/maven-resolver/pull/364#issuecomment-1814159292 I really hope "atomic on windows" will NOT replace the file and then throw :smile: otherwise, am really unsure what that OS is able to guarantee for at all. -- 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
