This may or may not apply - We've only recently moved to Maven adoption, and while there have been some problems with the move, the reasons for moving were always very clear - concrete delineation of our dependencies (We have a fairly deep dependency tree, with a lot of older code). That was recognized as a problem across the board, and just having that as a concrete point made a big difference.
We also expended a fairly significant period of time with one or two folks to just learn Maven. Learn it deep, convert builds, try it out - make sure it really worked. We generated internal task-based documentation from that process, and we showed it working in a number of brown-bag kinds of meeting and one on one's. Having someone available to answer questions for anyone attempting to convert was/is crucial. Frustrations have come up around control - Maven has the very definitive life-cycle of builds, but within a phase of the lifecycle things become very undefined in terms of "what goes first" and for our more complex product builds, we need some level of control. Maven is also clearly most beneficial for Java, and more "just another thing to wrap" when it comes to any other style of build. Some of our product uses both java development, C++, and C# all in one combined product suite. We've got it building with Maven - to the heroic effort of some of the devs - but only because they were enthusiastic about the tool set and the potential for both now and into the future. -joe Kalle Korhonen wrote: > I second that. On a large organization, with lesser Java knowledge and > only > very few strong engineering leads, any change meets resistance. I went > through the same converting our project to Maven and there's still > resistance. The most common arguments I hear: > - We have no expertise on Maven (they want somebody to teach them how > to do > things rather than assuming the responsibility of their own learning) Here, the luck of Maven's documentation join the game, if we only had good (and short;-) docs describing what is a life cycle, when and why the local repository should be cleaned up and more and more.... referring the whole team to read "Better Builds With Maven" does not work for engineers looking for the fast and short solution (but, it's a great book). > - Build's no different from Ant (managers don't see the benefits because > proper metrics aren't gathered and they don't give it enough time. All > they > see is an immediate disturbance in way things are done) > - No benefit in Maven related goodies (e.g. Maven site, Continuum - I > set up > both, people don't see the benefit: unofficial, not in use, extra, nobody > looks at reports. I mostly think the organization's as a whole is just > not > at the maturity level they could do software differently, based on > test-driven and continous integration principles) Most of my managers does use the reports, but here comes the other issue, if we have a 50 component project, you can't see the project's status, you can only see the component's status, for example: unit tests summary on a project's level, code coverage rate, even the javadoc aggregation is broken. > > - Builds break of unknown reasons, server down, plugins not found > (somewhat > legitimate. Explain again why my build machine needs http to build? We > resorted to using a file repository only. I think a better way to > solve this > problem is with better maven proxies, like Archiva, and of course setting > the versions of everything you are using) Yep, and add repositories downtime... > - We don't know the plugins and transitive dependencies we are using (I > mostly attribute this to people just being lazy and not bothering to > check > reports and understand the architecture) > - What's a snapshot, how do we version properly (module versioning had > never > before been used - only the product as a whole) so we were not in any > worse > position. But the truth is that release planning and doing it properly > takes > time, even with Maven) So, I think you can find some of Maven's disadvantages from the recent emails, but don't get it wrong, I think Maven is the way to go. Erez. > > Kalle > > On 4/12/07, Erez Nahir <[EMAIL PROTECTED]> wrote: >> >> I assume you did not have the opportunity to convince the old C++/Make >> guys to change their habits... :-) >> >> Erez. >> Barrie Treloar wrote: >> > On 4/12/07, Erez Nahir <[EMAIL PROTECTED]> wrote: >> >> Here in Cisco we use Maven2. >> >> If you can, when your presentation is ready, please share it, we >> still >> >> have some resistance from old make/ant supporters... >> > >> > How can there be resistance? >> > Once you get things up and running m2 is so much more simpler to >> > maintain/manage. >> > >> > Ant still has it's place for scripting things outside the build >> > lifecylce. >> > Make definitely isn't needed anymore. >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
