cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans <>
Subject Re: building trunk.
Date Tue, 10 Apr 2007 17:32:41 GMT
Reinhard Poetz wrote:

> I'm asking because I don't understand who the customers of creating a 
> <dependencyMangement> section in Cocoon are? Is it the Cocoon project 
> alone or also all projects that use Cocoon?

AFAICT dependencyManagement does not come into play unless you're 
inheriting from the pom that declares it, so it would be only useful to 
us internally.

> In the first case I doubt that there is much value in doing all this 
> work as long as the build runs through, isn't it?


> Or is the idea  that the user looks into our released parent pom and 
> copies our <dependencyMangement> section into his own project or even 
> inherits from our root pom?

I don't think any of these options is desired. Our main goal should be 
to keep our own dependency tree as clean as possible, ie <exclude> 
transitive dependencies in 3rd party libs that are clearly 
wrong/optional etc.

In any case, why wouldn't maven apply proper dependency resolution and 
selection when presented with multiple versions of the same artifact ?

Example: say i have a webapp pom that includes
- cocoon-core (which has CL 1.1)
- cocoon-thread-impl (which has CL 1.0.4)

then maven will just select CL 1.1 for inclusion, not both. If i however 
define in my webapp pom CL 1.0.4 then it will select only that.


View raw message