1 Maven and Ant comparison
First: Every time I say maven, many people will think is a new thing and refuse to give up Ant. In fact, Ant scripts can run directly in Maven.
If there is a difference between maven and ant, I think the biggest difference is that there is a foundation of Maven's compilation and all scripts, that is, POM (Project Object Model). This model defines all aspects of the project, then a wide variety of scripts work on this model, and Ant is completely defined, apparently Maven more winning.
Second: Maven has a clear definition of the rendered package. If you use that package, the version is much, and it will be. And Ant is usually a simple INCLDE all JAR. The resulting result is that you can't determine which version of the common-logging under the LIB in JBoss is the only way to open the Meta-Inf directory manifest.mf. It is estimated that JBOSS will turn to Maven sooner or later.
Third: Maven is based on the compilation of the central repository, ie the resources needed to compile in a central warehouse, such as Jar, TLD, POM, and so on. When compiled, Maven will automatically find the corresponding package in the repository. If the local warehouse is not, download it from the set remote repository to the local. All this is automatic, and Ant needs to be defined by himself. The result of this benefit is that the project compiled with Maven is only issued when published, and it is very small, and vice versa, the release of Ant will release all the packages, obviously Maven wins again.
Fourth: Maven has a large number of reuse scripts that can be utilized, such as generating websites, generating Javadoc, Sourcecode Reference, and so on. And Ant needs you to write yourself. Try the effect of the Maven Site.
Fifth: The place where Maven is currently not like Ant is a mature GUI interface, but Mavengui is working hard. The best way to use MAVEN is still the order line, and it is fast and convenient.
Finally, summarize, turn to Maven will save you more time.
2. Build.Properties and Project.properties
Build.Properties is better than compilation information, and Project.properties is used to put project information is better.
BUILD.PROPERTIES instance, put him in the user directory (C: / Documents and Settings / User), you can share this information using all items.
Maven.repo.local = f: / java / repository
Maven.repo.remote = http://mirrors.sunsite.dk/maven/
# maven.proxy.host = 127.0.0.1
# maven.proxy.port = 80
Maven.compile.target = 1.4
Maven.Compile.Source = 1.4
3 How to develop multiple projects.
When there are multiple sub-projects developed with Maven, it is often used to be MULITPROJECT scripts
For example, the following picture is a subproject in a project. There are two sub-projects in the subproject, as long as inheritance is defined in Project, 1.0 can put the scripts in Maven.xml and Project.Properties and build.properties. The property propagates to the child project, this feature seems to be not fully implemented in the RC version. Know these features of Maven, you can write a lot of common scripts in maven. In XML, the child can be easily called.
ClassName = "xdoclet.modules.hibernate.hibernatedoclettask" ClasspathRef = "maven.dependency.classpath" /> MergeDir = "$ {project.xdoclet.hibernate.mergedir}" ExcludedTags = "$ {project.xdoclet.hibernate.excludedtags}" addedtags = "$ {project.xdoclet.hibernate.addedTags}" Force = "$ {project.xdoclet.hibernate.force}" Verbose = "$ {project.xdoclet.hibernate.verbose}"> fileset>
TransactionsTrategy = "$ {project.xdoclet.hibernate.jbossservice.transactionstrategy}" UserTransactionName = "$ {project.xdoclet.hibernate.jbossservice.usertransactionname}" ServiceName = "$ {project.xdoclet.hibernate.jbossservice.serviceName}" JNDINAME = "$ {project.xdoclet.hibernate.jbossservice.jndiname}" DataSource = "$ {project.xdoclet.hibernate.jbossservice.datasource}" Diagect = "$ {project.xdoclet.hibernate.jbossservice.diaalect}" Showsql = "$ {project.xdoclet.hibernate.jbossservice.showsql}" TemplateFile = "$ {project.xdoclet.hibernate.jbossservice.templatefile}" /> -> TransactionManagerLookup = "$ {project.xdoclet.hibernate.cfg.transactionmanagerlookup}" Transactionstrategy = "$ {project.xdoclet.hibernate.cfg.transactionstrategy}" UserTransactionName = "$ {project.xdoclet.hibernate.cfg.usertransactionname}" JNDINAME = "$ {project.xdoclet.hibernate.cfg.jndiname}" DataSource = "$ {project.xdoclet.hibernate.cfg.datasource}" Diagect = "$ {project.xdoclet.hibernate.cfg.diaalect}" Showsql = "$ {project.xdoclet.hibernate.cfg.showsql}" /> hibernatedoclet> goal> In any subproject, you can call the Project: hibernate-xdoclet script directly. You can INCLUDES = "Portal / Project.xml, Common / Project.xml" Goals = "Project: Deploy" Banner = "deploying service:" ignorefailures = "false" /> Originally, I want to make Portal compiled as Common, but Reactor actually compiles Common, and recompile Portal. Because he decides to compile the order in the name, it is obviously not good, because there is often a relationship between multiple sub-projects. The method of solving is to define multiple Reactors. 4 Define your own Maven.xml template. Maven scripts are based on AOP, that is, you can insert your own code before and after any Goal, so Maven's script is not fixed. Here have a Maven template I wrote. XML Version = "1.0" encoding = "GB2312"?> XMLns: j = "jelly: core" xmlns: util = "jelly: util"> pregoal> goal> goal> goal> goal>
-> goal> provject> 5 Many public scripts are not normal This is a normal thing, in fact, many scripts XDoclet, MiddleGen, etc. have certain problems. If this happens, the most direct way is to pack their scripts yourself and make the script suitable for you. For example, the script before XDoclet 1.2 is not very easy to use. I will go to Maven's cache directory (c: / documents and settings / user / .maven / cache) to find the plugin directory you want to modify, there will be plugin.jelly, It is an XML file, which is a script, and then COPY can be called directly in your own Maven.xml. Here, it is a web xdoclet script I have written. ClasspathRef = "maven.dependency.classpath" /> MergeDir = "$ {project.xdoclet.web.mergedir}" ExcludedTags = "$ {project.xdoclet.web.excludedtags}" AddedTags = "$ {project.xdoclet.web.addedtags}" Force = "$ {project.xdoclet.web.force}" Verbose = "$ {project.xdoclet.web.verbose}"> fileset> Destdir = "$ {project.xdoclet.web.webxml.dir}" XmlenCoding = "$ {project.xdoclet.web.xmlencoding}" TemplateFile = "$ {project.xdoclet.web.templatefile}" /> destdir = "$ {project.xdoclet.web.strutsconfigxml.dir}" XmlenCoding = "$ {project.xdoclet.web.strutsconfigxml.xmlencoding}" Version = "$ {project.xdoclet.web.strutsconfigxml.version}" TemplateFile = "$ {project.xdoclet.web.strutsconfigxml.templatefile}" /> destdir = "$ {project.xdoclet.web.jsptaglib.dir}" ShortName = "$ {project.xdoclet.web.jsptaglib.shortname}" Validatexml = "$ {project.xdoclet.web.jsptaglib.validatexml}" Xmlencoding = "$ {project.xdoclet.web.jsptaglib.xmlencoding}" Filename = "$ {project.xdoclet.web.jsptaglib.filename}" TemplateFile = "$ {project.xdoclet.web.jsptaglib.templatefile}" />
MergeDir = "$ {project.xdoclet.web.jbosswebxml.dir}" /> -> WebDoclet> goal> This script can generate web.xml struts-config.xml TLD JBOSS-Web.xml, you can make it easy to modify as needed. In fact, it is not difficult to see that these are Ant scripts. So, if there is no suitable plugin, the best way is to write one yourself. 6 Unable to run Maven, an error is missing to miss the root component. This error is because the editor (such as: UltraEdit) has added extra characters before XML, causing the XML parser unable to process XML files, this error is often encountered. The method is to put the content Copy, re-Paste to the new file, and override the old file. Or remove the extra character with another editor. to be continued. . .