Bill, Antoine,
thanks for both suggestions. Antoine, I think I like your wrapper idea. It is simple and works with all ide's. I would normally like Bill's batch file idea, but my current team is using ant directly and actually opposes letting me have my normal build.sh and build.bat files. I have usually kept ant hidden from people in the past. Never needed to teach them how to set it up because it was hidden and automatic.
thanks,
Dean

Antoine Levy-Lambert wrote:

Bill,
maybe the solution for you would be, in each project directory to have a
small build file :
so the ant task would be the only thing you really need.
<project name="projectA" default="generic_build">
<target name="generic_build">
<ant antfile="../build.xml">

<property file="projectA.properties"/>
</ant>
</project>
----- Original Message -----
From: "Bill Winspur" <[EMAIL PROTECTED]>
To: "Ant Users List" <[EMAIL PROTECTED]>
Sent: Monday, January 06, 2003 1:17 AM
Subject: Re: one to bind them all-not solvable?



Dean,
We use a few generic builds for many apps on NT. The following
summarizes the approach.

1. My ide and ant share the application source directories.

1a In the root directory of the source, i put a properties file
that contains options used by the build, e.g. where the output
goes, what extensions are needed to permit compilation, etc.
This property file is what permits the central ant builds to be
generic with respect to applications.

2. The ide is used to change code and get clean compiles.

3. A few, centrally controlled ant builds are used to create and
deploy jar, ear, war, and zip files for all projects.
Only when developing a desktop client do we actually execute
the ide-generated class files, and that's just while testing. In
production all executables are in jars.

4. On the NT execition path, I have an nt bat file (runMyBuild)
that starts a central build.

5. I position the NT command window to the shared source
directory and manually execute runMyBuild. Recently I've switched
to starting ant from my IDE (intellij idea), in which case a

generic,

minimal, proxy ant build takes over the role of runMyBuild, i.e.
launching a central build script.

6. runMyBuild copies the central ant build file into the current
(source) directory and calls ant to do the build. During execution,
the build references the property file stashed in the source root.

7. When ant is finished, runMyBuild deletes the copied build file from
the source directory, so that build files dont lie around to be

evolved

ad hoc.

Hope this helps,
Bill.

----- Original Message -----
From: "Dean Hiller" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 04, 2003 9:07 AM
Subject: one to bind them all-not solvable?



I am working on a project with many modules or services developed
independently. We have the same exact build file for every one!!!
Instead of having many, I would like to only have one in the base level
directory. when I do an "ant -find", I would like it to compile the
project of whose directory I am in. I also want the basedir property to
be set to that project. This seems like a stretch and not possible.
Any ideas?

My directory structure
Base
single build.xml for each project
serviceA
src
build
serviceB
src
buil
serviceC
src
build

The baseDir of build.xml should be set to the serviceC if I am executing
"ant -find" from Base/serviceC/src. Possibly, I am going about this the
wrong way. Any out of the box ideas appreciated here too. Has anybody
else run into having so many of the same exact build files? How do you
deal with this? We currently have to copy our changes to each one. I
would much prefer a change that takes affect across the board.
thanks,
Dean


--
To unsubscribe, e-mail:

<mailto:[EMAIL PROTECTED]>

For additional commands, e-mail:

<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Reply via email to