maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Horlock" <peter.horl...@googlemail.com>
Subject Re: Proper Dependency Management - HowTo?
Date Fri, 04 Jul 2008 06:11:39 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message