Christian Clausen wrote:
Well, yes and no. Think of it this way: if you have B.war depending on A-1.0.jar, and you update A-1.0.jar to A-1.1.jar, have you changed the dependency tree? The answer is no - B.war still depends on A-1.0.jar because thats the explicity dependency you've written down. Maven won't try to figure out whether you mean for B to be upgraded or not.Brian Ewins wrote:OK, so being forced to update all dependencies can be seen as a "patch certification procedure". Is there a way to get a single overview of a potentially large dependency tree? (I mean, in case module A depends on module B which depends on the changed utility, the certification procedure must begin with module B and then A.)Christian Clausen wrote:Another issue is how to manage dependencies in a production branch of a group of dependent maven projects. Obviously, versions in a production branch must be "real" (x.y.z). [... if you change a utility version ...]That's exactly right, and with good reason. If you change the version of a utility, how do you know that the things which depended upon the previous version still work? Being explicit about dependencies does mean more work, but it pays off in the long run.
all J2EE modules depending on the utility must be patched and released/deployed.
On the other hand, if you have a collection of interdependent projects, can you figure out which ones might need changed if one of them is updated? The answer to this is more likely yes, since the Reactor has to this to figure out the correct order to build projects. I don't know if the reactor produces a dependency cross-reference report for all the projects at the moment, but projects would need updated in exactly the same order as the Reactor builds them.
-Baz
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
