maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: dependencies in reactorized builds
Date Mon, 31 Jan 2005 11:12:35 GMT
I thnik John's described it very well, and it's spot on.

It does seem very similar to Vincent's previous musing, though I think 
that it makes more sense in an extended project than in a global 
dependency. It's rare you'd want this to apply globally, but even if you 
did you'd use a company wide root POM rather than a global setting. This 
may get to the point of multiple levels of inheritence though I'd like 
to avoid the complication.

I agree with Mark's post too, and would like to take a separate look at 
how projects are aggregated (the master build vs. the parent pom) and 
how multiple projects are versioned (in particular how the parent pom is 
versioned). But that's a discussion for another day. Don't worry, it's 
on my TODO list :)

Some more of Michal's points addressed below:

>a) during the reactor powered builds we know what's the latest version of
>any project which is visble for reactor.
This is talking more about versions of unrelated projects, not those run 
inside the reactor.

>b) reactorized builds should be rare for any considerably big project. I
>mean that we should rather promote ci tools.
What about the very first time you have to build plexus, or build clean? 
>From experience it takes a -very long time- to do properly individually 
because the poms don't correctly interact in the reactor.

>   It doesn't make sense to rebuild entire project if a changes in single
>module were made.
No it doesn't - but that's not every going to be any different here - 
things still need to build on their own.

>   In the second case (distributions) I am not attempting to build any
>artifacts - I am using what already exists in the repository. 
Possibly, but you need to be able to build clean for a release.

>   Note that if builds were made by ci system we could do a lot of "tricks -
>e.g. made dual builds:
>   - against dependecies stated in the pom 
>   - against the latest version visible for ci system. 
That's already planned.

>c) the problem with management of dependencies version exists only because
>we don't have good tools 
>   for helping to deal with this difficulty (e.g. to upgrade a version of
>given dependency in multiple project). 
But I don't think we should come to reliance on a tool to do this either 
if there is a practical and logical way to share the information.

>d) (MAIN ISSUE) Project inheritance leads to yet another dependency. If we
>are going to change a 
As above, I agree we need to sort out how this will work in practice, 
but I think it needs to be easier to deal with than changing everywhere.

>[off topic]
>I think that the fact that given dependecy should be bundled in the war
>should be expressed using "bindTo" semantic.
>Simply all runtime dependecies should be bundled in the war. That's why I
>suspect that "include/exclude" like semantic for "bindTo" 
>will be more appropiate the just "include".
I agree with this - this is something that was discussed in my earlier 
musings. I'll rewrite the outstanding stuff and resend it to the list as 
an RFC.


View raw message