> Have you tried it? I haven't, but somehow I doubt it will work... That's
> just a guess though. --DD
It works, but I actually use a very different version in practice to achieve
something similar to Ulf's original wish: a way in which projects can
inherit common project behavior and yet still allow for optional extensions
or overrides.
First, some background: My projects generally have a single src subdirectory
where all .java files go. However, some projects use additional
subdirectories to contain the output of code generators. (I don't like to
mix source and generated code because it gets to annoying to figure out
which is which when they are colocated in the same directory.)
Therefore, I needed a way for a project to specify its source directories,
but I wanted to use a common set of targets for building. Let me tell you,
this was not easy to figure out. In much more than just a nutshell, this is
what I do:
Each project contains a build.xml minimally containing the target 'init'
which initializes a number of properties unique to the project: javadoc
name, jar name, version and a couple of other things. In addition, the
'init' target may also specify extensions to the default source and class
paths. By default, projects get default source and class paths of 'src' and
'build/classes:lib/*.jar:lib/*.zip'. For a project that wants to extend its
source path, to include 'gen' for example, then its 'init' target must
initialize a property containing the extended path.
This is achieved by constructing a path, called 'javac.sourcepath', composed
of the default source path (usually just 'src') and an extended source path,
if any.
This gets complicated, but essentially I have an XML fragment called
buildTargets.xml that defines my regular build targets and properties. This
fragment is included (via XML) into each project's build.xml that wants to
use it.
Here are the relevant portions of buildTargets.xml and a project's
build.xml, with an explanation following so you can get an idea how this
works:
buildTargets.xml:
<target
name="buildTargets.setDefaultExtendedCompileSourcepath"
unless="buildTargets.extended.javac.sourcepath">
<property name="buildTargets.extended.javac.sourcepath" value=""/>
</target>
<target name="buildTargets.init"
depends="init,
buildTargets.setDefaultExtendedCompileSourcepath">
<path id="javac.sourcepath" >
<pathelement location="${builtTargets.javac.src.dir}"/>
<pathelement path="${builtTargets.extended.javac.sourcepath}"/>
</path>
</target>
<target name="compile" depends="buildTargets.init">
<javac ... >
<src refid="buildTargets.javac.sourcepath"/>
</javac>
</target>
And here is an clip from one of my project build.xml files showing the
'init' and XML include:
<!DOCTYPE project [
<!ENTITY buildTargets SYSTEM "file:../../ant/script/buildTargets.xml">
]>
<target name="init">
<pathconvert
property="buildTargets.extended.javac.sourcepath"
pathsep="${path.separator}" dirsep="${file.separator}">
<path>
<pathelement location="gen"/>
</path>
</pathconvert>
</target>
&buildTargets;
How it works: Issuing the 'ant compile' command, results in the following
sequence of target being executed:
init
buildTargets.setDefaultExtendedCompileSourcepath
buildTargets.init
compile
As you can see, 'init' defines the extended sourcepath, and the next target
does nothing since the extended sourcepath was defined. 'buildTargets.init'
then merges the default sourcepath and the extended sourcepath into a single
property, ('javac.sourcepath') and 'compile' uses it. It is hopefully clear
then that if 'init' does not define an extension, then only the default
source path is used by 'compile'. (Note that it was necessary to ensure that
'buildTargets.extended.javac.sourcepath' is defined before
'buildTargets.init' is executed otherwise the <path> used to construct
'javac.sourcepath' can choke on an undefined property if the project does
not define an extended sourcepath.)
I've simplified things here a bunch to keep this as brief as possible and on
topic. However, there are a couple of other interesting features that my
scripts do as well:
1. Projects can override any target specified in buildTargets.xml, eg.
compile, clean, build, javadoc, etc. using indirect target references.
2. JDK specific classpaths and build tools are specifiable. This allows me
to easily build the same source against multiple JDK versions that may
require different sets of 3rd party libraries due to incompatibilities with
particular JDK versions.
I'd be happy to share more as people express interest.
didge
> -----Original Message-----
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 20, 2003 6:57 AM
> To: 'Ant Developers List'
> Subject: RE: javac-task and mapper
>
>
>
> > -----Original Message-----
> > From: didge [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 19, 2003 7:14 PM
> > To: Ant Developers List
> > Subject: RE: javac-task and mapper
> >
> > How about this?
> >
> > <path id="sources">
> > <dirset dir="src">
> > <include name="team*"/>
> > </dirset>
> > </path>
> > <javac ...>
> > <src refid="sources"/>
> > </javac>
> >
> >
> >
> > didge
> >
> > > -----Original Message-----
> > > From: Ulf Caspers [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, August 19, 2003 11:06 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: javac-task and mapper
> > >
> > >
> > > On Mon, 18 Aug 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > >
> > > > All you need to do is:
> > > >
> > > > <javac destdir="build">
> > > > <src path="src/team1" />
> > > > <src path="src/team2" />
> > > > </javac>
> > > >
> > > > No need for a mapper. Works like a charm ;-) --DD
> > >
> > > This is true - as long as you know the names and the number of the
> > > "team"s.
> > >
> > > My wish is to create a single build.xml-file that is usable for all
> > > projects - no matter which teams are envolved.
> > >
> > > Ulf
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
