Hi; a few thoughts of a happy maven2 user who also sees _some_ of the issues while using it internally...:
cvr schrieb: > - "The build system should be more complicated (harder to run, harder to > configure) than the software" Is this really what he means, and you're sure you didn't accidentially omit a "not" somewhere in this statement? To me this does not make any sense, actually... what is his rationale for that? Why have a tool hard (impossible) to operate when you can have an easy, straightforward one? > - "Why all this configuration for a glorified WGET?" Yeah... like "why cut that tree using a chainsaw when we eventually could do with a rusty knife?"... > - "Why do you need a shared repository (~/.m2/repository)? Disk space is > really cheap" Before switching to maven2/NetBeans, I used Eclipse "default" projects along with a vast load of projects referring to jars somewhere on my drive. After checking out some _old_ code off our SVN I learnt to know what makes a sane, structured artifact repository a rather good thing... :) > - "What’s wrong with just checking the jars in to source control under lib" Honestly I think this is not too bad an idea if working on internal code with an internal SVN repository, as this way one eventually could avoid some additional infrastructure (like maven2, archiva, ...). But that doesn't still help dealing automatically with transitive dependencies, different library versions et al... > - "I just have a build script that I run to compile my project, what's so > hard about that?" (ed. note: it's a bash script) [...] > Having struggled with projects that had *no* build script (from the README: > "step 1: open up Eclipse and click compile"), projects with undocumented > dependencies (yay, ClassNotFoundException at runtime), and having fought > multi-module ant builds for two years - Maven has worked out wonderfully. A way to get around this seems rather easy: Establish documentation guidelines, and force developers into getting at the very least basic documentation done allowing an arbitrary developer to pull the project from some local versioning repository, modify some code and get it built within a few moments. As soon as this is part of the requirements, he won't have much fun anymore using his self-made build scripts and undocumented dependencies as this would drastically increase his documentation work to be done. That's what in my opinion is the biggest "pro-maven2" reason from a non-technical point of view: You don't have to explain too much - no custom build scripts, no custom modified build.xml files including all sorts of "black magic", just a rather straightforward mechanism pretty easily usable by anyone who manages to build a maven2 project... Just my $0.02 of course... Kristian -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 "One dreaming alone, it will be only a dream; many dreaming together is the beginning of a new reality." (Hundertwasser) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
