Hi Peter, Peter Horlock wrote: > Okay, > > one last thing - this conversation has helped me a LOT > already, but, to > catch it all, I need some more: > > 1) You say your version ranges wouldn't break a build - but what about > transitive dependencies that these new versions might have (in case > they are overwriting depd. mgmt for example)? What about new 3rd > party dependencys, what if they have new third party dependencies? > When I moved > our project > from maven to maven 2, with the transitive dependencies the > jars /wars of > the sub projects each got some new jars, that were not > included before, and > this sometimes made the project fail at runtime - sometimes > even in the most > obscure and hidden places, hard to find - same thing could > happen with new > dependency versions, couldn't it? I am therefore not yet > totally convinced > of transitive dependencies - it hides things, and then when > you don't expect > it, it might fail in a productive environment, if a test > didn't catch it > before.
That's Michael's point 8. If you upgrade a 3rd party dep, you should really have a look at the dependency tree to see, what has changed. > 2) When you are talking about composition, I know finally > understood you are > talking about using poms as a container to combine > dependencies. But how > soon will you start making such a combine pom? If you got 2 > similar jars? > 10? 20? What's the best ratio from your expierence? It depends on your use case how you use a dependency normally. Michael's example was Hibernate. It's more or less always if you recognize that you have to add the same dependencies (and exclusions) in several places only because you like to use framework X in a special way. Checkout also the scope import introduced with M209. > 3) Will those "composition poms" not clutter your project > structure even > more? > With maven 1 you had one pom to maintain and to understand - > now with maven > 2 you already got 2. Now when using "composition poms", you > will end up with > 3,4,5....10 Poms just got one single project... ??! Our developers are > already grumping about having to maintain the parent pom AND > their project > pom - I mean it has all its nice vantages, but on the other hand, it > increases the projects complexity, in some way, too, you have > to admit, > don't you?! Managing dependencies *is* complex. Managing them in M1 was worse. Synchronizing a dozen of your projects to use the dependencies in the same versions was horrible (even with entities). The composition poms allow you to have specialists for a framework, who define what is really needed, while all the others simply use the composition pom and can expect that it works. > 4) I don't yet completly get the vantage of having all those > seperate jars > in a single project, instead of one hugh block of code - I > mean, yes, when > someone breaks something in "his own code region", the others > may still work > on their code without it influencing them - but what about > runtime errors - > when you are using separate jars its all nice and divided, > but this somehow > may only delay the error from happening in another remote > code region. I > mean, imagine > everyone is happily working with dependency 1.2.3, now > someone releases > 1.2.4. To find an obscure bug, it often needs a certain time > for ppl to find > it, and > when everyone is still working with 1.2.3, noone will > actually find this > error until finally they will change to 1.2.4. I mean, when > no separate jars > are used, this might sometimes cause the entire project to break - but > doesn't that also drastically show everyone that this class / > this external > jar has influences on all sorts of other code regions? > Compare it with teams > that are closely working together - the more closer, the more > often they > might quarrel over something - but as soon as this dispute is > resolved, afterwards they will have grown an even better community - > where's with > closed doors, when they don't see or talk to each other, they > won't have > problems in the short run, but when they finally meet and > talk about things > it might bang much stronger.... > Do you get my point? It's hard to explain, I hope you get my > analogy. A > colleague pointed this out to me, and I didn't know how to > answer it - imho > it is a valid argument, isn't it??? That's what Michael solves declaring the ranges and we by using SNAPSHOTs. However, it is no automatism for detecting runtime incompatibilities. So write your unit and integration tests ;-) > Last but not least - we have about 10 sub projects, but in > one of those sub > projects, there are between 1-4 people working. So you still > got the problem > if you break something in a sub project, you will influence > up to 3 other > developers.... It's policy. While sub project 3 is working with the latest stuff of sub project 1, sub project 5 might decide not to switch and wait for a stable release and do their integration then. Maven simply helps you to support both scenarios. > Please, bring some light in my confusion! :-) Hope this helps :) - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
