Hi cvr, I think hostility can exist with any change in general. Sometimes it is really just an attitude thing so you can't use logic to reason with him. What you need is a mandate (whether it is concencus from team members or from someone else).
If you don't have a mandate to use Maven then you might as well give up. If you need his vote to get a mandate then I'd say bribery or blackmail. Seriously, nothing is wrong with anything he objects, everyone is open to an opinion but is he professional and humble enough to try something new and give it an objective assessment. Maven is not perfect, I have a lot of gripes with it but it is better than anything out there I know at the moment. Cheers, rOnn c. Russ Tremain <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 22/10/2008 04:43 PM Please respond to "Maven Users List" <[email protected]> To cvr <[EMAIL PROTECTED]> cc [email protected] Subject Re: Advice on dealing with hostility to Maven 2 have you tried the Maven Kool-Aid on him? It's sort-of purplish and you can buy it at Trader Joe's, but they are often out of stock. :) bottom line, in maven you can see the dependencies of a project, in a clearly specified form. there are even visual tools to help. not so with ant, make, sh, perl, etc. make and ant moved in that direction, but were overcome by our need to be procedural. Clearly written maven specifications, with configuration rules centralized in a few parent poms, can offer great simplicity for developers creating new sub-projects within a build system. You can provide archetypes to make it even simpler. In contrast, go back and read some of the ant files you wrote 4 or 10 years ago and see if you can figure them out. Better yet, look at some of the *generated* ant files coming from IDE's, and try to figure those out. Not to say you can't write spaghetti code in maven; I've seen it. You can replicate cannonical configurations to your hearts content, and generally succumb to the dark forces of entropy, as you can with any language. This can happen on any development team, especially once it grows beyond a certain size (N > 1, I think). But even then, maven is easier to figure out, and it gives rise to an urge, in certain talented developers, to tidy things up. :) And if you can't figure out how to do it in maven, then there is always the antrun plugin, or even the exec plugin. I find that I use 'em less and less, however. BUT, if your friend is really in love with his shell script, then exec it from maven and move on. my 2 cents. /r At 7:16 PM -0700 10/20/08, cvr wrote: >I have a colleague has recently become a very vocal opponent of Maven. The >problem is that we're behind a corporate firewall, and he has had a lot of >difficulty getting Maven to work (I googled "firewall" and created a >~/m2./settings.xml file appropriately). > >His arguments have been: > >- "The build system should be more complicated (harder to run, harder to >configure) than the software" >- "Why all this configuration for a glorified WGET?" >- "Why do you need a shared repository (~/.m2/repository)? Disk space is >really cheap" >- "What's wrong with just checking the jars in to source control under lib" >- "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. >However, I can't seem to get this across. His mind is (angrily) closed. > >I'm just wondering if others on this forum have encountered similar >hostility and you coped with it. >-- >View this message in context: http://www.nabble.com/Advice-on-dealing-with-hostility-to-Maven-2-tp20082277p20082277.html >Sent from the Maven - Users mailing list archive at Nabble.com. > > >--------------------------------------------------------------------- >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] ###################################################################### DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ######################################################################
