How to import properties and targets from ant build file properly?

Question

I want to make project with two modules. App and server. Server depends on app. When I compile server I want to include class files from app into the build. But it resolves clas

Answer 1

Multi module builds are difficult because there are no standards, each build author have his own approach to solving this problem.

My personal preference is to emulate how Maven does it. Each module creates and publishes a jar file to the "local" repository. This jar file is then a dependency of the other modules that consume its classes. This approach creates clean separation between modules and means you don't need to build the entire project when working on one sub-module.

So how is this done using ANT? Well you'll need to embrace another Maven concept, dependency management. The ivy plugin provides this feature to ANT.

Example

My dummy project. A single module called "app" which is dependency of the "server" module

├── build.xml         <-- Builds all modules in correct order
├── app
│   ├── build.xml
│   ├── ivy.xml       <-- Describes module dependencies
│   └── src
|         ..
└── server
    ├── build.xml
    ├── ivy.xml       <-- Dependency on the "app" module
    └── src
          ..

Unless you customize locations, ivy uses the following directories to store files:

~/.ivy2/cache   <-- Downloaded 3rd party dependencies go here
~/.ivy2/local   <-- Repository which is private to the user. 

Creating alternative storage locations and leveraging Maven repository managers is beyond the scope of this question.

After running this example by build produces the following explicitly versioned files:

~/.ivy2/local/com.myspotontheweb/demo-app/1.0.0/jars/demo-app.jar
~/.ivy2/local/com.myspotontheweb/demo-server/1.0.0/wars/demo-server.war

build.xml

Builds all modules in the correct order. This is determined by the module dependencies documented in each module's ivy.xml file (See ivy buildlist task). This is a very useful feature when you have a large number of interdependent modules.

Notes:

• Contains logic to ensure the ivy jar dependency is installed if missing
• Ivy will cache downloaded 3rd party dependencies. The "clean-all" task is useful for ensuring the build is sweaky clean :-)

app/ivy.xml

Lists the 3rd party dependencies that the module has. This is a very useful Maven feature. Dependencies get downloaded automatically from Maven Central. No need to commit them into your source code repository.

Note:

• Ivy configurations are used to classify and group dependencies. Used later to populate classpaths

app/build.xml

Pretty standard build process. Code is compiled tested and packaged. Note how ivy configurations are used to control the classpaths.

The "publish" target is worthy of special note it pushes the built jar into a local location where it can be picked up by other module builds.

Notes:

• The ivy buildnumber task is really useful for ensuring your build number is properly incremented each time you run a build. It looks at the files previously published.

server/ivy.xml

This module has a single dependency on the latest version of the "app" module. The actual revision number is determined at build time based on the files present in the local repository.

server/build.xml

This build just packages up the libraries into a WAR file. What makes it noteworthy is it's use of the ivy retrieve task. It will pull the "app" module dependency and all its transitive dependencies. It can be difficult to keep track of these manually.