I have a project split in different modules, each of them with their own web resources. I'm using maven-dependency-plugin to unpack these modules so I can copy their content to the webcontent folder of the main project to pack it into a war file. The plugin works fine when these dependencies come from the .m2 repository. The problem is the plugin stops when it finds a dependency that is an open project. I'm using workspace resolution on eclipse so I can deploy easily to a tomcat server.
Is there any way to make the plugin not to stop and finish all declared dependencies?
I have never seen Maven treat artifacts global repositories any differently that artifacts in my local repository. Could it be that there is a netwroking issue that is preventing Maven from getting the global artifact? This is all just guess because you did not post the output from Maven.
Also, you might try running Maven with the -X option, that might give you some more details about what is going wrong.
This is what I get after a mvn clean install. The project x is closed so it unpacks correctly. The project y is open and it fails when trying to unpack.
Could it be something related to the goal I have configured? I tried but they do nothing.
Joined: Feb 24, 2010
I tried changing the phase to package and now I get this error:
I read something about a problem between maven-war-plugin and m2eclipse workspace resolution but I didn't find any solution. Is there any way to resolve this? I tried with the 2.3 version of the war plugin but it still doesn't work.
Looking at the original output, here is the problem:
[INFO] Unpacking C:\STS Workspace\Modularization\y\target\classes to C:\STS Workspace\Modularization\mywebapp\target\m2e-wtp\web-resources with includes "WEB-INF/layouts/**/*.jsp,WEB-INF/views/**/*.jsp,WEB-INF/layouts/**/*.html,WEB-INF/views/**/*.html,WEB-INF/tld/**/*.tld" and excludes ""
This INFO statement is about what Maven is about to do. The ERROR that follows is the reason why it couldn't perform this task.
You cannot unpack the classes directory! How are you referring to "y" in your dependencies? Are you using some mechanism to reference dependencies outside of the repository?
Joined: Feb 24, 2010
The problem with 'y' is just it's an open project in eclipse. If I close the project making maven retrieve that dependency from repository, it works fine. What we've done in our project to solve this problem right now is overwrite the maven-dependency-plugin so, in the part of the code where it detects the dependency is a directory, the plugin returns nothing instead of throwing an exception (that's what it does right now with the resolve workspace dependencies option active). To copy the files we need to the webapp directory of the open projects we are using filesync plugin. This way we let maven unpack the files we need when the dependency is a close project and use filesync to copy the files from these open projects.
We are doing all these in order to have a way to develop our application with eclipse. Without this it would be impossible to code the different modules and deploy them in our tomcat without having to install and close the projects all the time.
So you are making changes to the open source project? Is that an open source project owned by someone else or is it yours? And that's why you have the open source project created in Eclipse.
What I would do is:
1) Store the source code for the open source project in Subversion (substitute your favorite version control system)
2) Modify the pom.xml for the open source artifact to differentiate it from the officially released one. A slightly different groupId, artfiactId or version will do.
3) Create a job in Jenkins to build the open source project and place the result in a Nexus repository (you include a sources jar also if you need one)
4) Change the pom.xml for my projects to use the the coordinates defined in step "2"
Now when Jenkins builds your app, it uses your custom version of the open source artifact.
In fact, I have done the above for a few projects where we required modified open source. Note that we use a suite of tools (Subversion, Nexus, Maven, Jenkins) to define our build environment.
Joined: Feb 24, 2010
Something like that is what we finally did. And we are using exactly the same tools