2

I have a weird problem with Maven that I've not run into before. I appear to be the only one having the problem on my team and this is for a project that has existed for a significant period of time (10+ years). I'm new to the team, but so are other members who do not seem to be having this problem.

Here's the problem:

If I do a mvn clean compile, I get the following error:

[ERROR] Failed to execute goal org.codehaus.mojo:dependency-maven-plugin:1.0:copy (copy-dependencies)
  on project deployable-war: Error copying artifact
  from C:\...\dependency\target\classes
  to C:\...\deployable-war\target\dependency\jws\lib\classes:
  C:\...\dependency\target\classes (Access is denied) -> [Help 1]

Now, the weird part is that source and destination folders (dependency\target\classes and deployable-war\target\dependency\jws\lib\classes) were both created by Maven during the same compile command. This is a multi-module project, so mvn compile will go through all 9 modules. This is module 8. The dependency module is module 7.

If I re-run mvn compile (without the clean) afterwards, it gives the same error, so it does not seem to be a timing issue.

If I manually create the folder (mkdir ...\deployable-war\target\dependency\jws\lib\classes) and re-run mvn compile, everything works fine. That includes it copying JAR files inside of the lib folder that it said was access denied when it tried to create the classes folder.

I've tried deleting the \target\ folder entirely.

I've tried running Maven as an administrator.

I've tried checking out a new copy of the project from Git into a new directory on my local.

I've checked folder permissions on the project itself to ensure that my user and the administrator user have full control.

OS is Windows 10 Enterprise.

Any suggestions?

EDIT: From discussion, tracked the error down to this part of the pom.xml for the module:

<build>
        <finalName>deployable</finalName>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>dependency-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>copy-dependencies</id>
                        <phase>compile</phase>
                        <goals>
                            <goal>copy</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>${project.build.directory}/${project.build.finalName}/jws/lib</outputDirectory>
                            <artifactItems>
                                <artifactItem>

Now, the issue appears to be related to a subset of the artifactItem - particular, artifactItems that do not have explicitly-defined destFileNames.

Gerold Broser
  • 14,080
  • 5
  • 48
  • 107
Jeremy Smith
  • 311
  • 2
  • 13
  • 1
    Have you tried it on the command line (with alle IDEs closed)? – J Fabian Meier Sep 20 '19 at 19:15
  • Just shut down everything except Chrome and a new Dos prompt and ran it again - same result. I'd been running it in Git Bash so just tried in both Git Bash and Dos prompt, but both ways resulted in the error. – Jeremy Smith Sep 20 '19 at 19:28
  • 1
    Have you seen [maven-dependency-plugin target/classes - Access is denied](https://stackoverflow.com/q/8823342/1744774) already? – Gerold Broser Sep 20 '19 at 20:00
  • Thanks, @GeroldBroser. I'm going through that module's pom.xml to see if I can find anything that might be causing it but not having much luck. I'll edit with the part of the pom.xml in question. – Jeremy Smith Sep 20 '19 at 20:15
  • A bunch of testing identified that any artifactItem that didn't have a destFileName caused the failure. Unfortunately, I didn't write the pom.xml for this and the person who did is no longer with the company, so I can't try to find out what the point of it was – Jeremy Smith Sep 20 '19 at 20:27
  • 1
    You're using [`org.codehaus.mojo:dependency-maven-plugin:copy`](https://search.maven.org/search?q=g:org.codehaus.mojo%20AND%20a:dependency-maven-plugin&core=gav) which is 13 years old. What about using [`org.apache.maven.plugins:maven-dependency-plugin:copy`](https://maven.apache.org/plugins/maven-dependency-plugin/copy-mojo.html) instead? – Gerold Broser Sep 20 '19 at 20:43
  • Yeah, there are a lot of things in this project that have not been updated this decade... updating to this had the same result. org.apache.maven.plugins maven-dependency-plugin – Jeremy Smith Sep 20 '19 at 20:51
  • 1
    Two further points: 1. there's `copy-dependencies` but `copy`. This is misleading, at least, if not a configuration error. 2. From [Copying specific artifacts](https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html#Copying_specific_artifacts): "_The `dependency:copy` goal can also be used to copy the just built artifact to a custom location if desired. **It must be bound to any phase after the package phase** so that the artifact exists in the repository._" – Gerold Broser Sep 20 '19 at 21:21

1 Answers1

0

Long time coming back to this, but Gerold's comment lead me to the right resolution. The problem was the copy-dependencies happens after package. So the problem was that I was mvn clean compile, when I needed to be mvn clean package

I limped along taking way too long to sort that out. The fun of multi-module, interdependent projects

Jeremy Smith
  • 311
  • 2
  • 13