On Fri, 04 Jul 2008 18:11:39 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 ... > 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. Nope you release the same artifact into dev, staging, and production... once you release a war then its made ( i also use the generate release pom flag for the release plugin but only for war/ear/assembly projects
> > 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? use standard refactoring techniques to evolve them... i tend to not usea number like that but rather compose again by implementation e.g. web service, logging, xml, jaxb, axis > > 3) Will those "composition poms" not clutter your project structure even > more? ... > 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?! it does yes, but then mvn dependency:tree makes it all very clear... my ratio is 1:10 at the moment composition to real artifacts > > 4) I don't yet completly get the vantage of having all those seperate jars ... > 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??? this in an integration problem that always has to be addressed and it is solved by 1 communicaiton 2 process 3 continuous integration The ultimate goal it to manage the deliverable and write code. So if it did happen to break you can filter at an appropriate level of the resolution tree by either making a stricter range e.g. [1,2-!) to [1.5,1.19-!) So the point is things break, deal with it... don't make process so hard that you stiffle your ability to work. > > 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.... I reckon your projects are too big... make them smaller. It means your units tests get more specific and its way easier to refactor adjust and often avoids the need to branch and merge. > > Please, bring some light in my confusion! :-) i think there is very little left now, I am quite delighted -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
