[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2024-04-05 Thread Frank Leja (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834293#comment-17834293
 ] 

Frank Leja commented on MRESOURCES-237:
---

I had exactly the same problem and expect a configuration to steer the 
behaviour at least in the same manner as in v2.x (mean resolving the file, 
instead of just copy the link itself, what is useless). 

I used the symlink of the share library (ABC_api.so) pointing to the current 
version of this library (ABC_api.so.2.2.0.3). 

My workaround is to include the symlink target file in the resource plugin 
config, skipping the link and its benefits completely. 
{code:java}

ABC_api.so.*
{code}

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2023-05-24 Thread Thorsten Glaser (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725918#comment-17725918
 ] 

Thorsten Glaser commented on MRESOURCES-237:


Yes, so far my comment from 2022-01-07 has been ignored, and this issue is 
still keeping me on MRESOURCE 2.x in all Java™ projects.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2023-05-24 Thread josh gruenberg (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725883#comment-17725883
 ] 

josh gruenberg commented on MRESOURCES-237:
---

Despite the "Closed/Fixed" status marked on this issue, my experience suggests 
this has not been "fixed": as of version 3.3.1, symlinks are still copied 
verbatim into the target-directory, which, for relative links to files outside 
of the resource-directory (the kind I'd expect to find under version-control), 
results in FileNotFoundExceptions when dereferencing the link from the target 
directory. Turning on filtering for symlinked resource-files is a viable 
workaround, but this likely doesn't address all reasonable use-cases. I'd 
suggest either marking this ticket "Won't Fix" -- with an explanation of the 
decision and guidance for achieving each desired behavior -- or reopening the 
issue. 

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2022-12-18 Thread Emmanuel Bourg (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649042#comment-17649042
 ] 

Emmanuel Bourg commented on MRESOURCES-237:
---

This issue is marked as fixed in the version 3.3.0, but there is no mention of 
MRESOURCES-237 in the commit history. Is the resolution actually Won't Fix ?

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2022-01-07 Thread Thorsten Glaser (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470929#comment-17470929
 ] 

Thorsten Glaser commented on MRESOURCES-237:


Turns out that there are +*three*+ distinct cases, to apply for each 
{{}} directory:
 * {{true}} — here, the symlinks are always followed 
because the files themselves are possibly manipulated
 * {{false}} with symlinks followed by default (m-r-p 
2.x behaviour)
 * {{false}} with symlinks copied as-is (m-r-p 3.0/3.1 
behaviour)

And it also turns out I need to be able to mix them in a project, so I’m now 
even stronger in favour of an option per resource directory (or otherwise 
configured).

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2021-12-13 Thread Thorsten Glaser (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458325#comment-17458325
 ] 

Thorsten Glaser commented on MRESOURCES-237:


{quote}[~mirabilos] Thank you for your comment. We both seem to have valid 
use-cases.
{quote}
Precisely. Valid and opposite.
{quote}Feel free to comment there as well.
{quote}
I’ll see when I find the time. Things are hectic this week ☻
{quote}I have not tried to turn filtering off because we need filtering of our 
resources
{quote}
I have projects that have both filtered and unfiltered resources ☺ I definitely 
need both, and the symlink behaviour needs to be independent of whether it’s 
filtered.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2021-12-13 Thread Jimisola Laursen (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458323#comment-17458323
 ] 

Jimisola Laursen commented on MRESOURCES-237:
-

[~mirabilos] Thank you for your comment. We both seem to have valid use-cases. 
I created MSHARED-1004 a few days ago but it from my POV. Feel free to comment 
there as well.
There are two MWE that exopose the FileAlreadyExistsException.

I have not tried to turn filtering off because we need filtering of our 
resources (Spring Boot's application.yml among others).

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2021-12-13 Thread Thorsten Glaser (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458306#comment-17458306
 ] 

Thorsten Glaser commented on MRESOURCES-237:


I assume you’ve added a configuration item (or, perhaps ideally, a 
per-resource-directory setting, just like {{false}} vs. 
{{{}false{}}}) which we can use to configure this? 
Because [~lfvjimisola] and I have totally opposite requirements: I *must* have 
the symbolic links copied *as-is* while [~lfvjimisola] needs to have the 
*content* of the symbolic link *targets* copied.

I could not find a release announcement for either maven-resources of 
maven-filtering 3.3.0 on 
[https://www.mail-archive.com/announce@maven.apache.org/] so I’ve got no idea 
how we can even test both behaviours.
{quote}There seems to be inconsistency since another symbolic link that points 
to a directory has all its content (5-6 files) copied to target/classes.

That is, actual directory structure is copied if sym link but just sym link if 
it is a file. Is this correct or have I missed something?
{quote}
This would also be really bad. I *require* that symbolic links be copied as 
symlinks, no matter whether they point to a file, directory, or are even 
dangling in the source repository. (I have a project in which the symlink under 
{{src/main/resources/}} is deliberately “broken” so that, when it is copied to 
{{target/something/}} it will be correct. This is actually my use case, and one 
which works with the 2.x series of Maven’s relevant plugins.)

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2021-12-07 Thread Jimisola Laursen (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454788#comment-17454788
 ] 

Jimisola Laursen commented on MRESOURCES-237:
-

[~slachiewicz] It does not work me. With the explicit dependcy on 
3.3.0-SNAPSHOT Maven succeeds without errors. However, the symbolic link of the 
file is copied to target/classes and not the actual file. I'm back to square 1. 
I would like for maven-resources-plugin to copy the actual file to 
target/classes. 

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2021-12-06 Thread Sylwester Lachiewicz (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454125#comment-17454125
 ] 

Sylwester Lachiewicz commented on MRESOURCES-237:
-

Please try with updated maven-filtering dependency - should be fixed now

{{        org.apache.maven.plugins}}
{{        maven-resources-plugin}}
{{        3.2.0}}
{{        }}
{{                }}
{{                        org.apache.maven.shared}}
{{                        maven-filtering}}
{{                        3.3.0-SNAPSHOT}}
{{                    }}
{{          }}
[Edit|https://issues.apache.org/jira/secure/EditComment!default.jspa?id=13337258=17454108]
 
[Delete|https://issues.apache.org/jira/secure/DeleteComment!default.jspa?id=13337258=17454108]

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2021-09-22 Thread Martin Desruisseaux (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418698#comment-17418698
 ] 

Martin Desruisseaux commented on MRESOURCES-237:


Yes, but it may be cause I do not apply any filtering. I only copy a 
{{LICENSE}} file verbatim. I saw the alternative proposed in earlier comment 
(to put the license in a separated module and use the 
{{maven-remote-resources-plugin}}), but it seems an overkill for me for what 
should be a very simple task.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2021-09-22 Thread Thorsten Glaser (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418689#comment-17418689
 ] 

Thorsten Glaser commented on MRESOURCES-237:


2.7 works for you? I ran into MSHARED-325 there and had to downgrade to 2.6, 
cf. org.evolvis.tartools:maven-parent in Central.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2021-09-22 Thread Martin Desruisseaux (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418686#comment-17418686
 ] 

Martin Desruisseaux commented on MRESOURCES-237:


I had to dowgrade to version 2.7 for the same reason.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2021-05-26 Thread Andrew Lundgren (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352062#comment-17352062
 ] 

Andrew Lundgren commented on MRESOURCES-237:


We are using symbolic links for resource files (translations).  For now, we've 
also forced the version back 2.7

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2021-03-11 Thread Andrew Shcheglov (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299977#comment-17299977
 ] 

Andrew Shcheglov commented on MRESOURCES-237:
-

I support [~mirabilos]'s idea with a configuration option. But my case is the 
opposite. I have a project with the implementation of a couple of NIO2 
filesystems and my "test/resources" directory is full of different kinds of 
links: absolute, relative, broken, circular and they should be preserved as-is.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2020-10-26 Thread jks (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220873#comment-17220873
 ] 

jks commented on MRESOURCES-237:


I created MRESOURCES-269.  I've given up trying to track down the source of the 
problem.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2020-10-26 Thread jks (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220844#comment-17220844
 ] 

jks commented on MRESOURCES-237:


[~mirabilos] I'm not even sure where to report that bug.  
maven-resources-plugin seems to be a thin wrapper over other libraries. The 
problem might be in plexus or commons-io.  I've been trying to trace through 
different repositories but I haven't figured it out yet.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2020-10-26 Thread Thorsten Glaser (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220815#comment-17220815
 ] 

Thorsten Glaser commented on MRESOURCES-237:


[~j...@iname.com]that’s almost certainly an unrelated bug in the handling of 
copying of symlinks; I’d report it as new issue. (I think something like if 
(source exists && source is symlink) must be changed to if (source exists || 
source is symlink) to fix that; “exists” tests dereference symlinks, hence the 
extra test.)

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2020-10-26 Thread jks (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220802#comment-17220802
 ] 

jks commented on MRESOURCES-237:


A related problem popped up for me when I upgraded from 3.1.0 to 3.2.0.  It 
seems copying a symlink fails if the target does not exist.  If you are 
symlinking from test/resources/dirs/b to test/resources/dirs/a and the b 
directory is traversed before the a directory the symlink of that resource will 
fail.  Worse the order of traversal is inconsistent between git checkouts.  If 
the target was copied instead of the symlink this wouldn't happen.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2020-08-11 Thread Thorsten Glaser (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17175613#comment-17175613
 ] 

Thorsten Glaser commented on MRESOURCES-237:


I don’t know what an IT test is, but if you want a reproducer… attached: 
[^a.tgz]

Run as {{mvn clean compile}} for m-r-p 2.6, or with {{mvn clean compile 
-Dmaven.resources.version=3.1.0}} to test the version I have issues with 
(“expected” vs. “actual”).

Note that the “actual” was requested in MRESOURCES-212 so we’ll most likely 
need {{mvn clean compile -Dmaven.resources.version=3.3.0 -Dsomething}} to get 
the “expected” value.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2020-08-11 Thread Olivier Lamy (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17175450#comment-17175450
 ] 

Olivier Lamy commented on MRESOURCES-237:
-

[~mirabilos] maybe provide an IT test to help us working on it?

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2020-08-05 Thread Thorsten Glaser (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17171557#comment-17171557
 ] 

Thorsten Glaser commented on MRESOURCES-237:


I see that now even the target milestone 3.2.0 has been removed.

Is this *ever* going to be fixed? This is a *blocker* from upgrading multiple 
plugins (war, ear, resources) to their 3.x counterparts (see 
[https://repo1.maven.org/maven2/org/evolvis/tartools/maven-parent/1.28/maven-parent-1.28.pom]
 )…

 

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2020-04-09 Thread Thorsten Glaser (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079153#comment-17079153
 ] 

Thorsten Glaser commented on MRESOURCES-237:


A valid usecase for “broken” symlinks in the source that get fixed in the 
target are test fixtures, so I wouldn’t discount it completely.

But a parameter is *long* overdue.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.1.1
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2020-04-08 Thread Jan-Philipp (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17078717#comment-17078717
 ] 

Jan-Philipp commented on MRESOURCES-237:


Would be really great to have a flag at least.

But actually, I think the actual behaviour (whether intended, or not) is a a 
bug. A symlink is always only valid from its location as it is relative. When 
it is copied somewhere else, it only remains valid if it s copied exactly to a 
sibling location. This just does not make sense. So at least it should be the 
case that the symlink points to the same target after copying.

Still, a flag wether the symlink should be followed would be the right thing to 
have.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.1.1
>
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2020-02-13 Thread Olivier Lamy (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036605#comment-17036605
 ] 

Olivier Lamy commented on MRESOURCES-237:
-

the main issue with this change: it has never been documented and I guess it's 
an non intended change :) 

it causes this issue [https://issues.jenkins-ci.org/browse/JENKINS-59291] 

I will try to add a parameter to be able to restore the previous behaviour (a 
parameter to be backward compatible :P )

 

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2018-10-04 Thread Thorsten Glaser (JIRA)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638699#comment-16638699
 ] 

Thorsten Glaser commented on MRESOURCES-237:


Then, a new version which has a boolean parameter keepSymlinks or something 
like that would be welcome. As I said, I’d have preferred a default of false, 
but a default of true is ok as long as I can change this… I see now that newer 
maven-ear-plugin versions use maven-resources-plugin 3.x so this has become 
somewhat of a blocker of updating other plugins.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2018-09-13 Thread Karl Heinz Marbaise (JIRA)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613670#comment-16613670
 ] 

Karl Heinz Marbaise commented on MRESOURCES-237:


If you agree that there is no need for symlinks inside jar than there is no 
need for symlinks at all nor to follow them...Following symlinks during a build 
is from my point of view a wrong way covering things which are not correctly 
configured or not solved with things like remote-resources-plugin or other 
solutions...As in the description of this ticket...

You wrote about "Multi language project with Java, JavaScript, shell and other 
parts" ? Ok you don't have it in your jar file that's fine...than ignore my 
question about that...

Furthermore other people wish to have symlinks kept can be currently summarized 
to exactly two people (or to be accurate only one person cause for the first 
use case I have given a solution)...and yes an option (boolean parameter) would 
be a way which could be gone.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2018-09-13 Thread Thorsten Glaser (JIRA)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613650#comment-16613650
 ] 

Thorsten Glaser commented on MRESOURCES-237:


“So there should be no need having symlinks inside a jar file”

Exactly. Which is why I require the 2.x behaviour of *following* symlinks 
instead of *preserving* them during copy.

However, *other* people wish to have symlinks kept. That’s why I argue in 
favour of an option.

“The question is why a shell script is packaged into a WAR file?” I never said 
that. (There’s other stuff packaged into a WAR, which makes perfect sense in 
our environment though. I can’t disclose details.)

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2018-09-13 Thread Karl Heinz Marbaise (JIRA)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613639#comment-16613639
 ] 

Karl Heinz Marbaise commented on MRESOURCES-237:


There are two..things from my point of view.

# If you have a multi language project this should be handled by the frameworks 
you are using either Java or Javascript. So there should be no need having 
symlinks inside a jar file (which will never work inside the jar file). Apart 
from that who will change the links? The question is why a shell script is 
packaged into a WAR file? Does not make sense from my point of view...
# The behaviour has been changed from 2.X to 3.X which means major version 
change (see [semantical version|https://semver.org/]) which introduced breaking 
changes. 

Furthermore as I mentioned in my previous comment. If you like change this 
behaviour the best would be to offer a pull request with an option which is by 
default {{false}}. cause otherwise it would break backward compatibility within 
the same major version line which will never work.

Apart from that the documentation should be enhanced with this information 
which unfortunately was not the case. 

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2018-09-13 Thread Thorsten Glaser (JIRA)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613582#comment-16613582
 ] 

Thorsten Glaser commented on MRESOURCES-237:


+1, I just lost about two hours debugging an application initialisation failure 
because a file was not copied to a JAR inside a WAR… turns out that an upgrade 
of maven-resources-plugin in the parent POM (from 2.6 to 3.0.2… I wonder if we 
should go to 3.1.0 even) broke this: the symlink (instead of its target, as 
before) is copied from {{src/main/resources/FOO}} to {{target/classes/FOO}} 
breaking relative link targets, and then it’s omitted from the JAR because it’s 
a broken symlink. (In my scenario, this does not affect tests, and the symlink 
is necessary, since it’s a multi-language project, with Java™, JavaScript, 
shell and other parts.)

Given MRESOURCES-212 “maven resource plugin does not preserve symlinks” I think 
that, while ① there _should_ be a +configuration option whether to copy 
symlinks as symlinks or to follow them+, ② this configuration option *MUST* 
+default to follow them+, to *not break pre-existing behaviour*.

Please fix this quickly. I think we’ll lower the version to 2.7 in the 
meantime, assuming that fixes it.

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2018-03-29 Thread Karl Heinz Marbaise (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419339#comment-16419339
 ] 

Karl Heinz Marbaise commented on MRESOURCES-237:


The simple solution for this is to make a separate module within your project 
which contains that configuration ( {{/src/test/resources}}; make a test-jar of 
it ) and make it a dependency (scope:test) to the other modules which is OS 
independent..works everywhere...

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2018-01-09 Thread Jonathan Haber (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16319069#comment-16319069
 ] 

Jonathan Haber commented on MRESOURCES-237:
---

Would you accept a PR that fixes this issue with symlinks?

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior

2018-01-09 Thread Jonathan Haber (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16319066#comment-16319066
 ] 

Jonathan Haber commented on MRESOURCES-237:
---

Just ran into this issue as well. We're seeing this cause the plugin execution 
to fail which prevents the build from proceeding. The output is:

bq. [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources 
(default-resources) on project FacsimileApi: 
/usr/share/hubspot/build/workspace/Facsimile/FacsimileApi/target/classes/migrations.xml
 (No such file or directory) -> [Help 1]

> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing 
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
>
> It looks like the handling of symbolic links in the 
> {{maven-resources-plugin}} has changed in version 3.0.x.  I'm submitting a 
> JIRA because it breaks the previous behavior and I have not been able to find 
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project.  We have a custom log4j2 
> configuration file we use during testing.  Instead of maintaining this file 
> in multiple {{src/test/resources}} directories, we instead maintain a single 
> copy of the file at the project's root level and create symbolic links from 
> each module's {{src/test/resources}} directory to the file using relative 
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to 
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim. 
>  The symlink's relative path results in the symlink pointing to the wrong 
> file location.  The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document 
> the change and provide a configuration parameter to allow the legacy behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)