The Maven site would be best. This site is intended for speed in getting past the evaluation period, and the inevitable humps.
| [top] |
In this demo we will follow the basic steps of a maven tutorial, right off the site. Go here, and follow the steps.
Once built, let's open that same project in eclipse and run see what it looks like.
| [top] |
Following the Maven tutorial again, we'll see for ourselves just how easy it is.
If you can, start out at the main maven site, drill down through the plugins to get to the archetype plugin so you'll know how you got there, then look up the webapp how to, which happens to also be linked from here .
Once again, take it out and drive it after you build it, to see how you like it.
| [top] |
Let's run something right from the tutorial again, but this time, after we finish the boilerplate, we'll skip over to an already developed site. Run this one against one of your previously built sites, and see how it builds the docs Then change one of the docs, check it out, etc.
| [top] |
Subversion, Eclipse, Maven
Watch how long it takes to pull down a totally new and unfamiliar project, and get to work immediately knowing where every single thing is.
| [top] |
Go to the external tools menu.
Right click on the Program button at left to get a new one.
Then fill out the form as at right, using the browse button to take you to wherever your mvn.bat file (or mvn.sh if *nix) lives.
The working directory is easy to fill in from the variables button.
I usually name it (top text box) to match the
argument I put in at the bottom, but that's whatever
your preference dictates.
Again this is a personal preference, but it makes it nice to go to the Common tab and check the button for "Display in external favorites menu"
Always go the "Refresh" tab and check the "Refresh resources upon completion" box. Otherwise you'll have to F5 the target directory after it runs to see your changes.
From this point forward you won't have to do most of these again if you just start by taking an existing mvn task and right click on it, then "duplicate"
That way all you will have to do is change the name and the arguments, and you can have 5 or 10 or even more of your favorite maven tasks right there in your eclipse IDE
| [top] |
Remember, your Maven pom.xml is THE MAIN SOURCE FOR EVERYTHING CLASSPATH RELATED. This is a bit of a headscratcher at first, but once you get it, makes everything else a lot easier.
In other words, your web-app/lib files, assembled jars if it's a rich client or something, everything that you normally have to maintain with some difficulty is now placed in one single source, and Maven is the guy responsible for keeping it all straight.
To re-create your eclipse .classpath file every time
you change your pom.xml, run this command
mvn eclipse:eclipse
| [top] |
Every plugin will come with "usage" instructions that instruct you how to paste the appropriate xml into your pom.xml file. It's about that simple.
Some plugins require additional tweaks to the configuration xml, which is where maven's documentation can get a bit lame at times. But eventually, you can usually get it to work.
| [top] |
Maven runs every test with every build, unless you tell it not to.
| [top] |
Right Now ! Canvas your friends, you'd be surprised how many of us are around, ready to help.
| [top] |
If you don't know this one already, you may not even be a candidate for Maven. If you haven't fumbled with various copies of xerces.jar or servlet.jar or servlet-api.jar to try and find the one that works with the code that you are using, then you may not understand why the creators of Maven spent time creating an alternative.
| [top] |
Go here for the apache maven sponsored plugins , and here for the codehaus sponsored plugins , and here for the codehaus sponsored plugins that are still in the sandbox .
The nice thing is that every maven plugin is also a maven project, so at least you have a chance at a half-way start at documention and project structure. Of course, sometimes that's all you get - halfway...
| [top] |
