[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458306#comment-17458306
]
Thorsten Glaser edited comment on MRESOURCES-237 at 1/7/22, 10:37 PM:
----------------------------------------------------------------------
I assume you’ve added a configuration item (or, perhaps ideally, a
per-resource-directory setting, just like {{<filtering>false</filtering>}} vs.
{{{}<filtering>false</filtering>{}}}) which we can use to configure this?
Because there are totally opposite requirements: some *must* have the symbolic
links copied *as-is* while others need 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. In the “do not follow symlinks” case, 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. In another, the symlinks are only correct in the source
directory; this is actually my use case, and one which works with the 2.x
series of Maven’s relevant plugins.)
was (Author: mirabilos):
I assume you’ve added a configuration item (or, perhaps ideally, a
per-resource-directory setting, just like {{<filtering>false</filtering>}} vs.
{{{}<filtering>false</filtering>{}}}) 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)
