Download Maven2 and add to path
- <SAKAI_SORUCE> is your Sakai source directory
- <TOMCAT_HOME> is the tomcat home directory
The Maven2 build runs allongside the Maven1 build using m2-target. It uses a plugin, which for the moment needs to be built and installed from source. So you can use Maven 1 or Maven 2 at the same time. The build is defined in pom.xml files and unlike maven 1, the build structure and dependencies is defined in these files rather than by virtue of the position in the file system. Once the first build is complete you can go to whereever there is a pom.xml file and perform a build.
The master pom.xml is the parent of all pom.xml files in the maven build, due to a bug in 2.0.4 sakai will not build with a parent of a parent, however this file defines all the necessary buiild environment and only needs the setting of tomcat home.
In maven 1 we had deploy.types, in maven 2 we are using the standard packaging concept that is used by al maven2 project. The Sakai plugin added a nunber of special packaging types
- component - this is a war that deploys to components by unpacking the war
- shared - this is pom.xml containing dependencies that are deployed to the shared lib
- common - this is a pom.xml that contains dependencies that are deployed to the commoon lib
- server - this is a pom.xml that contains dependencies that are deployed to the server lib
All deployment to shared/lib common/lib server/lib are now controlled within a seperate poms with a packaging type as mentioed above. This means that we dont specify deployment targets as a side effect of the packaging to building of other types. In maven 1 we added deploy.target into the dependency tag of the project.xml, now this is achieved by creating a new pom.xml, specifying the packaging type as shared, common or server and listing all the dependencies that we want to deploy to that space within that pom. There can be, and are a number of poms for shared/common/server throughout the sakai build.
Maven 2 has the concept of transitive dependencies. That means if you depend on a jar, it will also include the jars that it depends on. When you build a webapp, you may find jars appearing int WEB-INF/lib that you have directly defiend as dependencies. Unfortunately there are some limitations in the maven 2 transtive dependency resolution that dont allow you to specify that a dependency and its own dependencies are provided within a specific scope. The means that you have to explicityl list the shared dependencies and give them a scope of provided, to prevent them from being packaged with a war or jar. Annother area that is slightly broken is that the a dependency that is provided is not transitive within that target of the pom.... confused.... I still am.
Since the poms define the modules that are built, rather than the modules being built because they are part of the project tree we can do custom deployments just using a modified top level pom. For instance if you wanted a cut down deployment, you coudl simple comment out the unwanted modules from the root pom.xml file, and they would not be built or deployed. If you irst cleared your repository, the build would also tell you what was missing. However the list or projects output at the end of the build is listed in dependency order, so you can comment out all modules below a certain point to reduce the size of the deployment.