On Thu, April 12, 2007 5:53 pm, Kalle Korhonen wrote: > - 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)
Hear this a lot as well. At the core is the question "what decision can I make that will involve the least amount of work for me personally?". Often the management decision is based on what's best for the manager, not what's best for the organisation or the development team. > - 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) The key here is to identify what in the ant build is broken, and use the corresponding non-brokenness in maven to sell as a solution. As most ant build scripts are half hearted solutions at best, it is usually not hard to find breakage. In our case, ant scripts had been set up such that everybody shared the same jar repository, meaning that the first person to build a broken jar, broke the build for everybody. They had to go. > - 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) In our case the key driver behind it all was continuous integration, it's all in the way you sell it. By far and away the biggest problem on our team was undisciplined developers checking in broken code. Everyone else does an update, and boom - no more work until the original person fixed their code. Unfortunately the best advert for continuous integration happens _after_ you have continuous integration - people suddenly find the build remains fixed. And when it breaks, everyone gets emailed about it, so everyone knows exactly who to moan at if the build does break for them. We pointed out what broken builds was costing the project, suddenly all resistence melted away. > - 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) When provisioning new people, we always start them off with a clean slate. The very first build downloads half the internet, and the new maven users sit wide eyed going "what is all this stuff it's doing?". Our answer is a smooth "it's doing lots of stuff for you automatically, see how you don't need to do this stuff yourself, and see how it doesn't download everything the second time". "Wow..." they exclaim with wide eyes, and they're usually pretty sold from that point on. > - 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) We sold this on one support incident. Production had a bug, and they didn't have the source code for that version of production. While they were running around like headless chickens we said "there is a solution you know...". The first time we showed them the release procedure, it sealed the deal: mvn release:prepare mvn release:perform And you are done. Regards, Graham -- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
