| ----- |
| Benefits of using Maven |
| ----- |
| Jason van Zyl |
| ----- |
| 12 October 2005 |
| ----- |
| |
| Benefits of using Maven |
| |
| *John Casey |
| |
| [[1]]standardization |
| |
| [[2]]reuse |
| |
| [[3]]consistency wrt build output |
| |
| [[4]]dependency management |
| |
| [[5]]scalability (lower level of additional info/code to add a new step to the build process) |
| |
| [] |
| |
| *Ashley williams |
| |
| [[1]]Dependency management |
| |
| [[2]]Build lifecycle management |
| |
| [[3]]Large existing repository |
| |
| [[4]]Eclipse aware (sort of) |
| |
| [[5]]Well documented (hopefully soon) |
| |
| [] |
| |
| *Eric Hartmann |
| |
| [[1]]One directory layout, |
| |
| [[2]]A single way to define dependencies, |
| |
| [[3]]Setting up a project is really fast, |
| |
| [[4]]99% of my needs are available out of the box, |
| |
| [[5]]Transitive dependencies ! :-) |
| |
| [] |
| |
| *Vincent Massol |
| |
| [[1]]common build structure |
| |
| [[2]]build best practices enforcement (shared build meme) |
| |
| [[3]]automated build of application, from source code to pre-production platform => fast time to market with reduced risks |
| |
| [[4]]works well with distributed teams ;-) Location doesn't matter. |
| |
| [] |
| |
| Compared to Ant: |
| |
| [[1]]Higher level of reusability between builds |
| |
| [[2]]Faster turn around time to set up a powerful build (once you're used to Maven) |
| |
| [[3]]Less maintenance |
| |
| [[4]]Shared build meme. I know how to build any maven project |
| |
| [[5]]Greater momentum: Ant is now legacy and not moving fast ahead. Maven is forging ahead fast and there's a potential of having lots of high-value |
| tools around Maven (CI, Dashboard project, IDE integration, etc). |
| |
| [] |
| |
| *Emmanuel Venisse |
| |
| [[1]]All artifacts are versionned and store in a repository |
| |
| [[2]]build process is standardized for all projects |
| |
| [[3]]a lot of goals are available so it isn't necessary to develop some specific build process part contrary to ANT |
| we can reuse existing ANT tasks in build process with antrun plugin |
| |
| [[4]]it provide quality project information with generated site |
| |
| [[5]]Easy to learn and use |
| |
| [] |
| |
| *David Jackman |
| |
| [[1]]Dependency management |
| |
| [[2]]Makes the build process much easier at the project level (i.e. don't have to create very much for each project for Maven to build it |
| correctly, and those things you do create are more declarative than functional) |
| |
| [[3]]Automatic project web sites with consistent information about each project |
| |
| [[4]]Recommended standards and best practices for project layout and definition |
| |
| [] |
| |
| *Jesse Mcconnell |
| |
| [[1]] Promotes modular design of code. |
| by making it simple to manage mulitple projects it allows the design to be laid out into muliple logical parts, weaving |
| these parts together through the use of dependency tracking in pom files. |
| |
| [[2]] Enforces modular design of code. |
| it is easy to pay lipservice to modular code, but when the code is in seperate compiling projects it is impossible to |
| cross pollinate references between modules of code unless you specifically allow for it in your dependency management... |
| there is no 'I'll just do this now and fix it later' implementations. |
| |
| [[3]] Dependency Management is clearly declared. |
| with the dependency management mechanism you have to try to screw up your jar versioning...there is none of the classic |
| problem of 'which version of this vendor jar is this?' And setting it up on an existing project rips the top off of |
| the existing mess if it exists when you are forced to make 'unknown' versions in your repository to get things up |
| and running...that or lie to yourself that you know the actual version of ABC.jar. |
| |
| [[4]] strong typed life cycle |
| there is a strong defined lifecycle that a software system goes thru from the initiation of a build to the end... |
| and the users are allowed to mix and match their system to the lifecycle instead of cobble together their own |
| lifecycle.. this has the additional benefit of allowing people to move from one project to another and speak |
| using the same vocabulary in terms of software building |
| |
| [] |
| |
| *Henning |
| |
| [[1]] quick project setup, no complicated build.xml files, just a POM and go |
| |
| [[2]] all developers in a project use the same jar dependencies due to centralized POM. |
| |
| [[3]] getting a number of reports and metrics for a project "for free" |
| |
| [[4]] reduce the size of source distributions, because jars can be pulled from a central location |
| |
| *Roberto Castro |
| |
| [[1]] Consistency in artifact naming |
| |
| [[2]] Use of remote repository |
| |
| [[3]] Web site generation |
| |
| [] |