Maven Compile Access Denied Copying Dependencies - windows

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.

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

Related

Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin: 3.0.0-M4 (default-test). There are test failures- JENKINS

I did download the project from github without any problem, i provided th maven commands mvn clean install and the project build successfully but when it comes to run the tests i get the following error. Any hints? I'am providing my pom.xml file, i tried all the suggestions but nothing.
Does your pom.xml contains the plugin surefire tag ? If thats missing then maven wont download this plugin at runtime and hence the error. Also if its there but maven cant download then may be you have to allow internet connectivity or copy the jars manually inside the .m2 directory on the Jenkins/Node server machine.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.4</version>
</plugin>

"Artifact is not fully assembled" error with maven-invoker-plugin in parallel build

According to the docs, maven-invoker-plugin is "thread-safe and supports parallel builds." However, when I build by multi-module project with -T 1C, I get an error like the following:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-invoker-plugin:1.10:install (integration-test) on project my-archetype: Failed to install project dependencies: MavenProject: com.tavianator:my-archetype:1.6-SNAPSHOT # /home/tavianator/code/Project/my-archetype/pom.xml: Failed to install project artifacts: MavenProject: com.tavianator:my-project:1.6-SNAPSHOT # /home/tavianator/code/Project/my-project/pom.xml: Failed to install artifact: com.tavianator:my-project:jar:1.6-SNAPSHOT: Artifact is not fully assembled: /home/tavianator/code/Project/my-project/target/classes -> [Help 1]
The project layout is like this:
Root
|--Project 1
|--Project 2
|--Archetype (depends on Project 1, scope=test)
The archetype integration tests use the maven-invoker-plugin to install the relevant dependencies (Root and Project 1) to a local repository, then runs the normal archetype integration tests. In parallel builds, Archetype and Project 2 run at the same time. When the maven-invoker-plugin runs, it tries to install Project 2 to the local repo, but Project 2 isn't built yet, hence the error.
But since Project 2 isn't even needed for the tests, I should be able to work around the problem by explicitly installing only the needed dependencies. I don't see how to get the invoker plugin to do that, but is there another plugin I can use?
I reported the maven-invoker-plugin bug here. I have an example project that demonstrates the error here.
I ran into this problem as well, in addition to other problems with the setup suggested in Fast Build Configuration (such as some artifacts being downloaded by the invoked project in every run), and implemented my own solution. Instead of the invoker:install goal, you would use the following:
<plugin>
<groupId>com.github.veithen.invoker</groupId>
<artifactId>resolver-proxy-maven-plugin</artifactId>
<version>0.1</version>
<executions>
<execution>
<goals>
<goal>start</goal>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
Note that there is no need to explicitly configure settings.xml or a dedicated local repository. This is done automatically.
Currently the code in the plugin is experimental. If it turns out to be robust enough, I will submit a patch integrating it into maven-invoker-plugin. More information here.

Is maven-download-plugin not portable, or am I crazy?

TL;DR: I stumbled upon a situation where my pom.xml works fine on Windows, but fails on Linux. Since I'm rather new to maven, I'm not sure whether it's a common situation, or if I messed up somewhere.
More details:
I use the maven-download-plugin like this:
<plugin>
<groupId>com.googlecode.maven-download-plugin</groupId>
<artifactId>maven-download-plugin</artifactId>
<version>1.1.0</version>
<executions>
<execution>
<id>get-stuff</id>
<phase>generate-sources</phase>
<goals>
<goal>wget</goal>
</goals>
<configuration>
<url>http://myUrl/my.tar.gz</url>
<unpack>true</unpack>
<outputDirectory>${project.build.directory}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
On Windows it works like a charm (ie: it downloads and unpack).
On Linux, it fails with the following error:
[ERROR] Failed to execute goal com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget (get-moab)
on project my-project: Execution get-stuff of goal com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget failed:
An API incompatibility was encountered while executing com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget: java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.Commandline.createArg()Lorg/codehaus/plexus/util/cli/Arg;
I found a workaround (<unpack>false</unpack>, and then "manually" unpack with antrun), but my pom.xml looked better without those additional 15 lines...
To put it in a nutshell:
Is it actually a portability issue, or have I messed up somewhere?
If it's an portability issue: is it common with maven, or am I unlucky on this one?
More technical details:
I used the same plugin both on Linux and Windows (same version, same maven repository)
It failed on a Centos, and a VM with Ubuntu 12.04
My first troubleshooting step when a build works on one machine and not another is to clean out the local Maven repository on the failing machine, and let Maven re-download all of the artifacts. That's often enough to fix the problem.
If the build fails with the same error, then I clean out the local repository on the working machine and build. Usually then I see that I've missed a dependency in the POM that just happened to exist in my local repository already. Fixing the POM often makes the build work on both systems.
Did you check the Maven versions (mvn -version)? org.codehaus.plexus.util is a dependency of Maven Core, so if maven-download-plugin is running under a different version of Maven it was compiled for, this would explain the error.

intellij not picking up maven project structure

I have a mavenized java project in Intellij 122.327. Unfortunately (due to legacy code) certain code in the src directory uses tests in the test directory. I'm trying to remove these dependencies but its a long shot. In the meanwhile, I'm able to compile and deploy by using the build-helper maven plugin and adding src/test/java as sources:
<execution>
<id>add-test-dir-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/test/java</source>
</sources>
</configuration>
</execution>
Problem is whenever I restart Intellij it keeps marking the src/test directory as a "test" directory (if I go to Project Structure -> Modules -> Sources, src/test is marked in green). So every time I have to manually mark test/java as "Sources". Is there a way to permanently mark this as sources? Even better, does Intellij have a way to read from the pom and infer the project structure?
Check the logs for any related exceptions. There can be many reasons for this problem like a proxy with the self signed certificate, invalid VM options, network issues, etc. See also this answer.
If the issue persists, contact support with the logs attached.

How do I deploy the results of a tycho p2 repository build to a place on the local file system or a locally maintained p2 repository

I have a working Tycho build that produces a working p2 repository. My current work flow is to manually drag and drop the results of this build from the project's target dir to the web server that hosts the p2 repository. The results of my tycho build look normal:
${projectBaseDir}/target/repository
- features
- com.my.product.feature.201111071414.jar
- plugins
- com.my.product.plugins
- artifacts.jar
- content.jar
So, what is the "industry standard" for taking the results of this build in the repository directory and placing them on a web server.
In this case, I am running the p2 repository's web server on the same machine that is running the build sever, so a simple copy to a directory command would work.
I've tried the maven-resources-plugin using the resources:copy-resources with no luck. I kept getting an error about the invalid output directory. I don't really feel like copy-resources is the way to go here, since the general purpose of that goal is to copy files to the target directory of your maven build, and not to copy files from the target directory of a maven build.
My task seems simple, and I realize there are a lot of options to copy files, but I'm looking for the "maven way" or better yet, "the tycho way" of doing this. If such a standard exists.
thanks,
TW
You can achieve what you want with the antrun plugin. It lets you use ant tasks/targets (like copying files) to do things during a Maven build.
I expect something like the following would work for you:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<id>configFix</id>
<phase>package</phase>
<configuration>
<target name="configFix">
<copy file="${project.build.directory}/p2/some.file" todir="C:\My\Directory" overwrite="true">
</copy>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
There is an example of Minerva how to publish the repository.
I just finished a plugin for that: http://download.ralph-schuster.eu/eu.ralph-schuster.uploadfiles-maven-plugin/STABLE/. It provides even ways to execute commands on the repository server, e.g. in order to delete old files before or merge artifacts after the deployment.
Hope it resolves the deploy problem. :)

Resources