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

Samik R edited comment on MRESOURCES-237 at 12/3/24 12:28 PM:
--------------------------------------------------------------

I ended up using a roundabout way to achieve what I wanted (symlinks are 
followed and original file is copied):
 * In my parent pom, excluded processing files that are symlinks. For me, they 
had a specific extension, so it was easy. You might have to come up with some 
scheme to achieve this.
 ** 
{code:java}
<build>
    <finalName>${project.artifactId}</finalName>    
    <!-- Exclude sql files from the test resources to be copied. We will copy 
them over separately. -->
    <resources>
        <resource>
            <directory>src/test/resources</directory>
            <excludes>
                <exclude>*.sql</exclude>
            </excludes>
        </resource>
    </resources>
....
 {code}

 * In the child poms in projects where I had these specific file, I used 
`exec-maven-plugin` to execute a shell script to copy over the file to the 
required folder. I could not add this directive to parent pom itself, since the 
${basedir} keeps changing from project to project and creates problem for me.

 
{code:java}
<!-- We want to copy the symlinked files to the target folder, so that we can 
run tests -->
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>3.5.0</version>
    <executions>
        <execution>
            <id>copySoftLinks</id>
            <phase>process-test-resources</phase>
            <goals>
                <goal>exec</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <executable>${basedir}/../bin/copySoftLinks</executable>
        <arguments>
            <argument>${basedir}/src/test/resources</argument>
            <argument>${basedir}/target/test-classes</argument>
        </arguments>
    </configuration>
</plugin>
{code}
 

Here is the script I used:
{code:java}
#!/bin/bash
############################################################################
# - Shell script to copy all the symbolic links in a directory to a new 
directory
# - Should copy the actual files, not the symbolic links
###########################################################################

if [ "$#" -ne 2 ]; then
    echo "Usage: $0 <source directory> <destination directory>"
    exit -1
fi

# Get the symlinks in the source directory
sourceDir=$1
destDir=$2

# Find the symlinks in the source folder, and copy the original file (not the 
symlinks) to the destination
# Reference: 
https://stackoverflow.com/questions/8377312/how-to-convert-symlink-to-regular-file
# First check if the source directory exists
if [ -d $sourceDir ]; then
    echo "Copying soft links from $sourceDir to $destDir"
    cd $sourceDir
    for f in $(find . -type l)
    do
        echo "-- Copying $f"
        cp --remove-destination $(readlink $f) $destDir
    done
fi{code}
 

Currently this is Linux/WSL specific. Folks with Win might need to adapt. HTH!


was (Author: samikrc):
I ended up using a roundabout way to achieve what I wanted (symlinks are 
followed and original file is copied):
 # In my parent pom, excluded processing files that are symlinks. For me, they 
had a specific extension, so it was easy. You might have to come up with some 
scheme to achieve this.
 ** 
{code:java}
<build>
    <finalName>${project.artifactId}</finalName>    
    <!-- Exclude sql files from the test resources to be copied. We will copy 
them over separately. -->
    <resources>
        <resource>
            <directory>src/test/resources</directory>
            <excludes>
                <exclude>*.sql</exclude>
            </excludes>
        </resource>
    </resources>
....
 {code}

 # In the child poms in projects where I had these specific file, I used 
`exec-maven-plugin` to execute a shell script to copy over the file to the 
required folder. I could not add this directive to parent pom itself, since the 
${basedir} keeps changing from project to project and creates problem for me.

 
{code:java}
<!-- We want to copy the symlinked files to the target folder, so that we can 
run tests -->
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>3.5.0</version>
    <executions>
        <execution>
            <id>copySoftLinks</id>
            <phase>process-test-resources</phase>
            <goals>
                <goal>exec</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <executable>${basedir}/../bin/copySoftLinks</executable>
        <arguments>
            <argument>${basedir}/src/test/resources</argument>
            <argument>${basedir}/target/test-classes</argument>
        </arguments>
    </configuration>
</plugin>
{code}
 

Here is the script I used:

 
{code:java}
#!/bin/bash
############################################################################
# - Shell script to copy all the symbolic links in a directory to a new 
directory
# - Should copy the actual files, not the symbolic links
###########################################################################

if [ "$#" -ne 2 ]; then
    echo "Usage: $0 <source directory> <destination directory>"
    exit -1
fi

# Get the symlinks in the source directory
sourceDir=$1
destDir=$2

# Find the symlinks in the source folder, and copy the original file (not the 
symlinks) to the destination
# Reference: 
https://stackoverflow.com/questions/8377312/how-to-convert-symlink-to-regular-file
# First check if the source directory exists
if [ -d $sourceDir ]; then
    echo "Copying soft links from $sourceDir to $destDir"
    cd $sourceDir
    for f in $(find . -type l)
    do
        echo "-- Copying $f"
        cp --remove-destination $(readlink $f) $destDir
    done
fi{code}
 

Currently this is Linux/WSL specific. Folks with Win might need to adapt. HTH!

 

 

> 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)

Reply via email to