Maven for Grouper
Advantages
- Eases dependency management across releases by declaring dependencies
- Makes it easier for users who build grouper to obtain dependencies (in versions that match the grouper release if necessary)
- Makes it easier for other projects which use Maven to declare and use Grouper dependencies
- With a parent/sub project structure for grouper and it's components, would enable dependencies to be declared in the parent and used in sub projects
- Eases management of inter-dependencies between sub-projects, and makes them easier to build
- One build command could build all of Grouper
- Maven plugins can be used to run various quickstart configurations (e.g. HSQL plugin, Tomcat plugin (or Jetty), probably in combination with the AntTask plugin)
- Maven is increasingly integrated into other build tools - e.g. Debian Helper - for building native packages
- Well integrated into IDEs
Disadvantages
- Requires work to configure all parts to be buildable using Maven
- Requires work for components to be packaged and added to the Maven Central repository in correct format (binary, source and docs in their own jar files). We could run our own repository, which in turn would require that users configure their local Maven installations
- Does introduce dependency on Maven Central repository as source of dependencies
- Would require work for quickstart as this is in test/deployment crossover territory and it must be as easy as possible for the user
- Can not have jars that have source included or customizations (we can release and maintain customizations as forks, which is best practise)
- Can not have projects which have circular dependencies (using a parent project with inter-dependencies split into a another sub-project is a standard way around this)
Maven - an overview
Maven is a java project lifecycle management tool .. nuff said?
It includes build functionality like make/gmake
- It will compile code form source where that code is java source
It includes dependency definitions:
- Dependencies (including versions) required at build/runtime are defined in a file
- Maven must have local access to these dependencies to build
It includes dependency downloads from repositories:
- It can search for, download, install and use libraries contained in repositories (it does this by default)
- It can use public and private repositories. A private repository can act as a proxy to public repositories
- Projects can setup their own repository and direct (but not require) clients to use it
It can do more that just build:
- It can run tests
- It can build websites
- It can build documentation
- It can install and start the installed package
It is platform neutral:
- Works on pretty well all platforms
- Means that there are better platform-specific tools available for doing things like starting applications
It promotes best practice:
- Promotes convention over configuration
- Allows configuration where convention has been ignored
What it offers Grouper:
- Opportunity to define the different bits of Grouper as sub projects of a parent project and manage dependencies and inter-dependencies using Maven. This could be done with Ant, but would be harder to achieve and to maintain
- Could move to Maven convention when refactoring build processes, project layout etc.
- Simplify overall build and installation process through the use of a parent project (e.g. every part of Grouper could be built using a single command, with dependencies resolved by Maven)
- Use Maven plugins and configuration to run quickstarts for all parts of Grouper (HSQL plugin, servlet plugin ...)
- Could investigate ways of running tests using Maven
- Introduce Maven incrementally by wrapping existing ant build definitions
Comparison with Ant
Ant is driven by a build.xml file which contains step-by-step instructions as to what to do for each build target |
Maven is declarative - you tell it what you want to happen and it tries to work out how to do it. If you've followed convention then this will be easy, if not then it will need hints in the form of configuration (e.g. if your source code is in a different folder name to that defined by convention) |
Ant is task-based. Each task, and the steps required to achieve it, are defined as a build target |
Maven is lifecycle based. Targets are defined by convention, and fit into an overall lifecycle which will be executed in a series of sequential phases |
Ant doesn't have the concept of a sub-projects and dependency management across them (meaning that developers resort to defining this in the IDEs) |
Maven does, and it works within IDEs and outside them. With Maven you can create parent and sub-projects, manage common dependencies and inter-dependencies. Maven will work out what to do. You can define dependencies in detail in the parent, and refer to these in the sub-projects. |
Ant is easier to use if you want to do things exactly your way |
Maven is hard to use if you consistently work against convention. Maven can, however, invoke Ant tasks as part of a lifecycle |