¡Hello! I need to do something that, according to what I know, it is not
supported by maven. Tell me if I am wrong.
Let BoM be a Bill of Materials (a POM with pom packaging type that,
apart of the coordinates, only contains a <dependencyManagement> element
which specifies the version of a bundle of artifacts).
Let A3 be an artifact contained in BoM (its version is specified in the
<dependencyManagement> element of BoM).
Let A2 be third party artifact that depends on A3 with compile scope.
Let A1 be an artifact that depends on A2 also with compile scope.
Let E be POM that imports (or inherits from) BoM and whose
<dependencies> element contains A1.
Suppose it is needed to override the scope of A3 in E. By example,
change it to 'provided' because E packaging type is 'ear' and A3 is
provided by the application server.
According to my knowledge, there is no proper way to override the scope
of A3 without specifying its version nor losing granularity.
If I made use of the <dependencyManagement> element of E to override the
scope of A3, I would be forced to specify an A3's valid version, and
that opposes to the "Bill of Materials" pattern.
If I added A3 as another dependency of E with the desired scope, I would
fall in the error of forcing E to depend on A3, fact that could be true
in the current A2 version but may change in the future.
For the case of the example, the only solution I found is to put A3 as
an excluded transitive dependency this way:
<code>
...
<artifactId>E</artifactId>
...
<dependencies>
...
<dependency>
<groupId>org.test</groupId>
<artifactId>A2</artifactId>
<excludes>
<exclude>
<groupId>org.test</groupId>
<artifactId>A3</groupId>
</exclude>
<excludes>
...
</dependency>
</dependencies>
...
</code>
The drawbacks of this approach are:
- It only solves the case of the mentioned example where the final
objective is to avoid A3 be included in the "E.ear".
- If another artifact, call it X, depended on E with compile scope, it
would (at least) throw compilation error if X tries to define a class
that inherits from a class defined in A3.
- If E has many direct dependencies that transitively depend on A3, the
exclusion would be necessarily and inconveniently repeated in all of them.
If I am not wrong and the above mentioned is not supported by maven, it
occurred to me two improvements to solve it: To permit the
<dependencyManagement> element to contain dependencies whose cordinates
don't specify the version of artifacts that are already managed in a
parent's of imported POM's <dependencyManagement> element; or to add a
new kind of element inside the <dependencies> element to manage scope
overrides. I prefer the second alternative because in the first some
granularity is lost because the <dependencyManagement> element affects
the children also.
I hope I am wrong and you illuminate my brain,
Happily,
Gustavo Pollitzer
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
