Retain locally defined dependency scopes and excludes when removing dependency management

[pgier]

Some builds define dependency scopes in dependency management either in a local pom or in a parent pom. When v-man removes the local dependency management to replace it with an external dependency management, the scope definition is sometimes lost.

For an example of a build which defines scopes in dependency management, see apache cxf The dependency scope is defined in this parent pom: http://repo1.maven.org/maven2/org/apache/cxf/cxf-parent/2.4.9/cxf-parent-2.4.9.pom And the dependency is used in this pom: http://repo1.maven.org/maven2/org/apache/cxf/cxf-rt-core/2.4.9/cxf-rt-core-2.4.9.pom

If it's not possible to automatically set the scope directly in the dependency, then v-man should at least provide a warning that the scope has been removed, and it may need to be manually added.

The same problem occurs with dependency exclusions. They are removed from the local dependency management which causes a change in the behaviour of the pom.

[rnc]

Possibly the bommodder modifyDep check for whether there is an existing scope/exclusions is incorrect...

[jdcasey]

The problem here is that managed dependency information from BOMs is only used IF there is no colliding managed dependency already declared in the local POM.

Incidentally, this is why the first BOM to declare a dependency 'wins' over all the others...managed dependencies are copied directly into the project instance in memory, making them look like locally declared deps for the next BOM that's encountered.

Maven will simply discard colliding managed dependencies, and if we leave scope / exclusions but discard the version, we'll be left with an invalid POM.

In fact, the current code does almost this (the boolean logic is broken), and that is definitely a bug...it will render an invalid POM if that logic is ever triggered.

[pgier]

What I had in mind for this is that v-man would move scope and exclusion to the actual dependency declaration in the pom where the dependency is used (instead of the parent where the dependencyManagement is defined). The dependencyManagement information would still be removed similar to how it is now. AFAIK, exclusions and scope defined directly in the dependency will override what's defined in depMgmt, but the build will still take the version from the depMgmt.

[jdcasey]

How will this work for projects inheriting from a particular POM but which are outside the immediate build set? For instance, any number of projects that depend on jboss-as-parent?

If jboss-as-parent has one of these managed dependencies, how can we track down everything that inherits from it and inject the managed scope/exclusions??

It seems like we might be able to take advantage of another feature we've been talking about implementing: injecting a property with a standardized name into the dependency version, and allowing this dependency to override the one in the BOM. Then, adding this property to the capture POM, to prompt the builder to add it to the toolchain POM.

This version property could even reference one of the ${version.foo} properties in the version-master POM, if available. In fact, it might be a good idea to try to keep this together with the BOM versions somehow.

At any rate, a version property like this would allow us to retain central control over the version while still allowing POMs to inherit from things outside the local build group.

Thoughts?

On 10/23/12 8:06 AM, Paul Gier wrote:

What I had in mind for this is that v-man would move scope and exclusion to the actual dependency declaration in the pom where the dependency is used (instead of the parent where the dependencyManagement is defined). The dependencyManagement information would still be removed similar to how it is now. AFAIK, exclusions and scope defined directly in the dependency will override what's defined in depMgmt, but the build will still take the version from the depMgmt.

— Reply to this email directly or view it on GitHub https://github.com/jdcasey/pom-version-manipulator/issues/49#issuecomment-9700849.

John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey

[pgier]

Good point, it's probably not practical to pull the scope and exclusion information out of all the parents in the hierarchy. So this wouldn't work in every case.

[jdcasey]

Looks like we have a solution working now with the injection of version properties to the toolchain POM (capture POM, which prompts for inclusion into the toolchain).

Where possible, it will look for he appropriate BOM-managed dependency if no version property can be found, and inject that as the value for the version property marked for inclusion in the toolchain POM.