dr2238 wrote:
I have knowledge on ant, but doesn't have any knowledge on
maven. I heard other say ant is kind of procedural language , while maven
is an objected oriented language.
Is that true? Could anyone explain it to me a little bit? It would be great if you can show me some small examples to let me understand what is the difference between them.
They are very different from one another.Ant is effectively a scripting language: you give ant a sequence of tasks to do, and ant will go off and do those tasks for you.
Like any scripting language, ant is entirely useless without a script to run (aka the build.xml file).
And the ant script has to be written by you: ant isn't going to do anything unless you tell ant how to do it.
Way back when, people realised that people were writing the same ant scripts, doing very similar things, over and over again, resulting in incompatible and incomplete behaviour.
Surely if someone wrote just one ant script, and everyone used the same script, life would be much easier for everybody. In fact, life would be even easier if we could write the script in java directly and release it like we do any other java code.
And so maven was born. Maven is not a scripting language. Maven is not a language at all. Maven is like a butler: it knows how to do stuff. "Maven, build my jar file and run the tests." "Certainly sir."Of course, in order to do useful stuff for you, maven needs to know a few details about your project. Before it can build your jar file, it needs to know your project's name and the current version so that it can give your jar file a sensible name.
This is where pom.xml comes in. The POM is the place where everything maven needs to know is stored.The more information you add to your POM file, the more maven can do for you, without expecting you to tell maven how to do it, like you have to do with ant.
If you tell maven what jars your project depends on, maven can automatically download those jars for you. When your project depends on 50 jars, that is one serious timesaver, and 50 less things you have to care about.
Tell maven what kind of test library you use, and maven can run your tests for you as part of the build (mvn test).
If you tell maven that you use eclipse, maven can set up your eclipse environment for you. Getting up and running in your IDE becomes a single simple command, instead of 45 minutes of clicking the mouse (mvn eclipse:eclipse).
You can ask maven to build your javadocs for you. You already told maven where your source was, so maven has everything it needs to build the javadocs, without you having to tell it how (mvn javadoc).
In fact, maven knows how to build lots of different kinds of autogenerated documentation, and package them together into an autogenerated website for you with helpful menu navigation (mvn site).
And if you tell maven where the documentation should be uploaded to, maven can upload your site to your documentation webserver automatically (mvn site:deploy).
At this point you're probably wondering how you will remember all these different maven commands when the time comes to tag a release of your code.
Surely there must be a simple way for maven to sanity check your code to check whether it is properly checked in, test that your test suite runs correctly, tag your release, bump up the version numbers on all the files in source control to the next version number, check out a pristine copy of your tag, build the code, deploy the code to your release repository, build the documentation, upload the documentation for your release to your documentation website, all in one easy and pain free step?
There is: mvn release:prepare release:perform That's it. Seriously.You might start wondering what would happen if you had to tell maven about each and every detail about your project: wouldn't it get out of hand?
Of course it would, which is why maven introduces the concept of sensible defaults.
Some information, like the project name, is mandatory. But other information, like where your source code lives, has a sensible default. Put your source code where maven expects to find it (src/main/java) and you no longer have to tell maven where your source code is, maven already knows.
And if maven already knows where your source code is, then your fellow developers know where your source code is, without them having to look it up.
By sticking to the maven standard way of laying out your project, there is lots of information that you no longer need to tell maven about, or your fellow developers about. That means less work, less confusion, and less documentation.
You have just downloaded a project you have never seen before in your life. The project builds using maven. That means "mvn install" will build and install your code. You didn't need to read any documentation or instructions, you already knew how to build the project, just because it followed the maven standard.
Can maven do absolutely everything you might need it to do?No: but that is why maven can include snippets of ant scripts in the configuration, to allow you to script up any special behaviour you like. Or you could write a new maven plugin that does what you need for you, and in so doing teach maven how to do more stuff.
To sum up: ant is a scripting language, but maven is a butler. If given the choice, choose the butler.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
