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. 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? 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?! 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??? 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.... Please, bring some light in my confusion! :-) Thanks, Peter
