John Casey
standardization
reuse
consistency wrt build output
dependency management
scalability (lower level of additional info/code to add a new step to the build process)
Ashley williams
Dependency management
Build lifecycle management
Large existing repository
Eclipse aware (sort of)
Well documented (hopefully soon)
Eric Hartmann
One directory layout,
A single way to define dependencies,
Setting up a project is really fast,
99% of my needs are available out of the box,
Transitive dependencies ! :-)
Vincent Massol
common build structure
build best practices enforcement (shared build meme)
automated build of application, from source code to pre-production platform => fast time to market with reduced risks
works well with distributed teams ;-) Location doesn't matter.
Compared to Ant:
Higher level of reusability between builds
Faster turn around time to set up a powerful build (once you're used to Maven)
Less maintenance
Shared build meme. I know how to build any maven project
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
All artifacts are versionned and store in a repository
build process is standardized for all projects
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
it provide quality project information with generated site
Easy to learn and use
David Jackman
Dependency management
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)
Automatic project web sites with consistent information about each project
Recommended standards and best practices for project layout and definition
Jesse Mcconnell
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.
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.
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.
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
quick project setup, no complicated build.xml files, just a POM and go
all developers in a project use the same jar dependencies due to centralized POM.
getting a number of reports and metrics for a project "for free"
reduce the size of source distributions, because jars can be pulled from a central location
Roberto Castro
Consistency in artifact naming
Use of remote repository
Web site generation
standardization
reuse
consistency wrt build output
dependency management
scalability (lower level of additional info/code to add a new step to the build process)
Ashley williams
Dependency management
Build lifecycle management
Large existing repository
Eclipse aware (sort of)
Well documented (hopefully soon)
Eric Hartmann
One directory layout,
A single way to define dependencies,
Setting up a project is really fast,
99% of my needs are available out of the box,
Transitive dependencies ! :-)
Vincent Massol
common build structure
build best practices enforcement (shared build meme)
automated build of application, from source code to pre-production platform => fast time to market with reduced risks
works well with distributed teams ;-) Location doesn't matter.
Compared to Ant:
Higher level of reusability between builds
Faster turn around time to set up a powerful build (once you're used to Maven)
Less maintenance
Shared build meme. I know how to build any maven project
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
All artifacts are versionned and store in a repository
build process is standardized for all projects
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
it provide quality project information with generated site
Easy to learn and use
David Jackman
Dependency management
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)
Automatic project web sites with consistent information about each project
Recommended standards and best practices for project layout and definition
Jesse Mcconnell
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.
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.
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.
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
quick project setup, no complicated build.xml files, just a POM and go
all developers in a project use the same jar dependencies due to centralized POM.
getting a number of reports and metrics for a project "for free"
reduce the size of source distributions, because jars can be pulled from a central location
Roberto Castro
Consistency in artifact naming
Use of remote repository
Web site generation
扫一扫
958
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
