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

[jira-importer]

Brian D. Johnson opened MRESOURCES-237 and commented

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.

---

Affects: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0

Attachments:

• a.tgz (1.05 kB)

Issue Links:

• MSHARED-1004 Two (2) issues with symbolic links

• MRESOURCES-212 maven resource plugin does not preserve symlinks

11 votes, 20 watchers

[jira-importer]

Jonathan Haber commented

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:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources (default-resources) on project MyProject: /usr/MyProject/target/classes/myfile.xml (No such file or directory) -> [Help 1]

[jira-importer]

Jonathan Haber commented

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

[jira-importer]

Karl Heinz Marbaise commented

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...
But of course you can make a PR and we take a look at it....

[jira-importer]

Thorsten Glaser commented

+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.

[jira-importer]

Karl Heinz Marbaise commented

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

1. 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...
2. The behaviour has been changed from 2.X to 3.X which means major version change (see semantical version) 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.

[jira-importer]

Thorsten Glaser commented

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

[jira-importer]

Karl Heinz Marbaise commented

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.

[jira-importer]

Thorsten Glaser commented

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.

[jira-importer]

Olivier Lamy commented

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 )

 

[jira-importer]

Jan-Philipp Kappmeier commented

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.

[jira-importer]

Thorsten Glaser commented

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.

[jira-importer]

Thorsten Glaser commented

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

 

[jira-importer]

Olivier Lamy commented

Thorsten Glaser maybe provide an IT test to help us working on it?

[jira-importer]

Thorsten Glaser commented

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.

[jira-importer]

jks commented

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.