[
https://jira.codehaus.org/browse/MDEP-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Glajch updated MDEP-346:
------------------------------
Attachment: maven_dependency_test.zip
Test code mentioned in the original bug report.
> 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
> Attachments: maven_dependency_test.zip
>
>
> 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
