Your example is a little complicated and not exactly expressed in Maven
terms but I can respond to a bit of what you wrote.
In general, you might want to start with what you are trying to build.
Maven is used by thousands on people to build many different types of
applications.
Maven enforces a certain way of looking at the universe and will defeat
you (or make you wish you gave up) if you try to fight it.
See below for specific comments
On 28/10/2011 5:21 PM, G. Gustavo Pollitzer wrote:
¡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 X has a dependency on Y, then it should either define the dependency
itself or depend on something that exposes Y. Having it depend on a
project E that excludes Y will not get you Y.
- If E has many direct dependencies that transitively depend on A3,
the exclusion would be necessarily and inconveniently repeated in all
of them.
Not sure that is needs to be true.
You can fix this by building proper libraries that contain exactly what
you want and depend on them.
Probably A3 needs to a "provided" scope dependency in A2 and provided to
all modules once, in a library POM or an application 'core' library that
gets you the common stuff.
Then you don't need the exclusion since it is not included in A2.
http://blog.artifact-software.com/tech/?p=121
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 would focus on getting your project properly structured and working.
It takes a while to figure out Maven if you come at it very fixed ideas.
First figure out why Maven is doing it the best possible way and what
your project structure should be to get the most out of Maven.
You will likely find that your request is not a good idea.
We have several large portal applications (70+ modules with over 100
third party libraries) and Maven works very effectively in this
environment with very small POM files with no custom plug-ins or any
fancy stuff.
I hope I am wrong and you illuminate my brain,
You probably are.
If you want to continue the conversation, you should maybe tell everyone
a bit about what you are trying to build and why your application
structure has to be so different from everyone else building the same
type of application.
That will get you much better advice since there are probably dozens of
people in the forum who have built applications to run in exactly the
same environment.
If you can tell them where you are deviating from the standard
structure, they may be able to give you some good advice.
If you are building a normal web application that runs in one of the
normal environments, Maven will work very simply as is.
I hope that this helps.
Happily,
Gustavo Pollitzer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
