Scott Glajch created MDEP-346:
---------------------------------
Summary: maven-dependency-plugin violates artifact dependencies,
causing unstable incremental builds
Key: MDEP-346
URL: https://jira.codehaus.org/browse/MDEP-346
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy, copy-dependencies, unpack, unpack-dependencies
Affects Versions: 2.4
Environment: Tested on Ubuntu Linux 10.10 (Maverick) with maven 3.0.4
Reporter: Scott Glajch
If you tell the dependency plugin to unpack or copy a dependency, you are for
some reason allowed to specify and artifact that's not in the project's
dependency listing, whether it be transitively or specifically called out in
the pom file.
What this then means is that your project can depend an another module (since
the dependency plugin will use it), but as far as maven knows, it is not a
dependency of the project. Therefore the reactor will not consider it when
ordering modules on a build, as well as ignore it when running incremental
builds (such as the -amd flag).
In our case we have a very large project (200+ modules) that we build
incrementally, with help from the "incremental build" option in jenkins. This
will determine which projects need building by looking at the recent changes in
source control, thus building a list of projects to build. It passes those
projects into maven using the project list option (i.e. -pl
groupId1:artifactId1,groupId2:artifactId2). It also passes the -amd flag to
then build all the modules that those projects depend on.
I have provided a very simple test case to show the problem. There is a
toplevel project named "maven-toplevel-test", and 3 sub-modules named
component1, component2, and component3.
Component1 depends on component3 the normal way, as an explicit dependency, and
you can see that maven knows about this because when you run, from the
toplevel, "mvn clean install -pl :component3 -amd", maven will correctly build
component3 and any component that depends on it, which will be component1.
Component1 also depends on component2, though not explicity, but instead by
running the "copy" goal of the maven-dependency-plugin and specifying
component2 there. If you try run "mvn clean install -pl :component2 -amd",
you'll see that only component2 gets built, because maven doesn't know enough
to dig into the plugin configuration for component1 and see that component2
should be a dependency.
Now there is another similar bug open (since 2008), but that has a very
different focus. http://jira.codehaus.org/browse/MDEP-153
You'll see in that bug it is trying to somehow fix the maven reactor to dig
into these plugin configurations and inject dependencies.
I argue for a much different solution. I think that the
maven-dependency-plugin shouldn't let you specify an artifact that isn't
already a dependency of your project, or at the very least, have a flag
("strict mode" or something?) that requires all of the artifacts you are trying
to copy/unpack to be dependencies of your project.
The obvious fix for our project for now is to go through all of the poms that
use maven-dependency-plugin, figure out which artifacts are being manipulated
and add them as dependencies to the projects, but this solution makes it hard
to future-proof our projects from further mistakes. Who's to say that
developers won't just keep adding new copy/unpack goals to their projects and
not add those dependencies to the pom file? After all it won't break the build
so the problem will only manifest itself as an unstable incremental build
further down the line.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
