maven's documentation is either scarce and what doc i see doesnt seem to follow a logical progression 1st step is to create a repository where is this located ..what are the consquences of already having a local repo? now download the necessary distro from repository to local repos (how is this achieved offline and online scp/sftp/rcp?) then create plugin then install plugin publish the plugin now use the plugin the dependency generation tools (i'm assuming plugin's coalesce around group-ID) are ok but hard to follow for someone getting into a build environment for the first time (someone who only used NB or eclipse) I would advise them to use ant first so they get a firm grounding on what a build cycle is 'supposed to accomplish' e.g.
extract_from_repository (BTW if maven cant contact the repository all kinds of misdirected error messages show up) precompile jsp compile run_test_scripts (junit/httpunit) jar war ear deploy the strongest feature of maven ensuring version specific integrity..the last place I worked at did'nt have that and the build engineer would'nt use maven because it was 'too complicated' which was too bad as it would've solved the multitude of version mismatch scenarios we saw. If you look at the ant site http://ant.apache.org and steve loughran's ant-in-anger http://ant.apache.org/ant_in_anger.html anyone will be able to get to use Ant in any build environment in 1 day..probably also the reason why NB and Eclipse and JDeveloper will import/export ONLY to build.xml..although I hear of a plugin for eclipse but havent tested it out yet.. Thanks, Martin ______________________________________________ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > To: [email protected] > From: [EMAIL PROTECTED] > Subject: Re: Advice on dealing with hostility to Maven 2 > Date: Tue, 21 Oct 2008 11:37:42 +0200 > > 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] > _________________________________________________________________ When your life is on the go—take your life with you. http://clk.atdmt.com/MRT/go/115298558/direct/01/
