Amsterdam - build instructions

Amsterdam consists of several subproject. The design of the project hierarchy and dependency resolution is however designed so that all projects must be checked out and build together. It is in most cases not possible to check out a single sub project and build it. Its also important to know that each sub-projects hold its own artifacts and rules what to do during a build. Once the complete project is build, it is also possible to do most types of builds in each subproject.

Building from source

Begin by checking the complete amsterdam cvs module out or unpack a src distribution. At the topmost directory do a:

	  maven amsterdam:build

This will build all projects in correct order. It is very much like running jar:jar apart from that any non jar artifacts will also be build.

If the build fail, it might be that the maven-amsterdam-plugin was not properly installed, then begin the build by:

	  cd maven-plugins/amsterdam
	  maven plugin:install

Once built each sub-projects artifacts will be in its target directory. To clean up all projects run:

	  maven amsterdam:clean

If clean fails because of missing dependencies, put this is front of the command -Dmaven.multiproject.ignoreFailures=true

In each sub.project the normal maven targets are then available (dependning on project type), such as:

	  maven build
	  maven java:compile
	  maven jar:jar
	  maven site
	  maven plugin

To generate the complete documentation/site one should run multiproject from the top-level directory

	  maven multiproject:site

To create a distribution run:

	  maven amsterdam:dist

This will take a very long time to complete due to mavens fucked up dependency handling and our inabilities to work around it!

For developers

The build system for amsterdam is based on a few pillars:

  • Dependencies between projects is resolved through the file system and the use of maven.jar.override and not trough installation of artifacts in the local repository. This means that it is OK to make local changes in a project to several sub-projects without having them pollute the repository, it however also means that one must assure that the local jar-files are up to date.
  • Amsterdam depends on several jar:s that are not available in an external maven repository. Theses are all includes in the thirdparty directory.
  • During build each sub-projects goal build will be invoked. The default for build is to do a jar:jar. If one needs to do additional things one could override the build goal in maven.xml or define pre/post goals for it. Normally it is also possible to invoke maven build in a subproject to get it to build all artifacts.
  • The distribution is build with the dist module and the reactor. This means that if a subproject needs to to any special processing during dist it most define pre/post goals for the dist module. There is however one constraint: one is not allowed to redefine any of the default dist properties (see maven.xml for an explanation).
  • Al versions are handled globally in the top most project.properties file: 
    	      amsterdam.utils.version=3.0
	      amsterdam.jmx.version=3.0
	      amsterdam.qcron.version=1.0
	      amsterdam.server.version=3.0
	      amsterdam.plugins.version=1.0
	      amsterdam.demo.version=1.0
	      amsterdam.demo.axisdemo.version=1.0
	      amsterdam.demo.simplejms.version=1.0
	      amsterdam.alert.version=2.0
	      amsterdam.xindice.version=1.0
	      amsterdam.maven.plugin.version=1.0