The main pattern for having a project depend on another is as follows:
Code Block |
---|
define 'problematic' do define 'foo' do package :jar end define 'bar' do compile.with project('foo') end end |
The above works perfectly, but it would fail to compile if project 'foo' was packaged as war instead of jar. You might solve the problem with
Code Block |
---|
define 'problematic' do define 'foo' do package :war end define 'bar' do compile.with project('foo').compile.target end end |
This solves the problem in the compilation task, but fails in the eclipse task, because the generated .classpath would contain an incorrect entry. (This is a bug in the Eclipse task as of 1.4.6). To solve this problem you might do
Code Block |
---|
define 'problematic' do define 'foo' do package :war end define 'bar' do compile.with project('foo'), project('foo').compile.target eclipse.exclude_libs += [project('foo').compile.target] end end |
You interpret this like this: in the compile.with, the first element "project('foo')" is used by the eclipse task to set up the project dependency correctly. The second element is used by the compile task to make foo's classes available. The eclipse.exclude_libs options fixes the bug in the Eclipse task by removing the defective .classpath entry.
If you also want to depend on foo's test classes you might write
Code Block |
---|
define 'problematic' do define 'foo' do package :war end define 'bar' do compile.with project('foo'), project('foo').compile.target, project('foo').test.compile.target eclipse.exclude_libs += [project('foo').compile.target, project('foo').test.compile.target] end end |
that can be made clearer with
Code Block |
---|
define 'problematic' do define 'foo' do package :war end define 'bar' do foo_src = project('foo').compile.target foo_test = project('foo').test.compile.target compile.with project('foo'), foo_src, foo_test eclipse.exclude_libs += [foo_src, foo_test] end end |