We use cygwin/windows cmd/freebsd here and have been using ant for
everything. Mind you, most of our team has their tools installed locally
(java and ant respectively), but we do provide a means for people to be
'lazy' and just run everything from the server if they choose. In this
event, I've found that ant can pretty much do anything you need as long as
your path is properly constructed first. We use a lot of the same tools
you've mentioned (jalopy, checkstyle, junit), however, I'm using the
ant-based binaries for all of these.
We try to keep our environment clean as we've found problems where altering
the classpath can cause unexpected compile issues (ie: you may have forgot
to include certain libraries but ant already has them so things work, but
not when you deploy ;). Anyway, in this spirit, we've minimized our
environment to only include the following:
JAVA_HOME=x:\...
ANT_HOME=x:\...
CLASSPATH=.;%JAVA_HOME%\lib\tools.jar
PATH=%JAVA_HOME%\bin;%ANT_HOME%\bin;%PATH%
All users manage this on their own, but it would be fairly simple to
abstract this into a script. After 2 years of heavy development, we haven't
had to change this once, and everything works great.
We've taken two approaches.
1. place all commonly used executables and third-party applications in a
centrally managed server that has a relative path to your source.
root
|
+-- sw <development>
|
+-- tools <third-party products>
This means that you can always define a relative path to any
tool/application that you wish to use, and the ant script can take care of
things. The only gotchya is that you will have to build platform-logic into
your build scripts when you want to execute a binary that may only operate
on a specific platform.
We've setup our ant directory to reside under the /tools folder and have
added a "custom" folder in which we store all of the ancillary ant tasks we
pick up (including jalopy and checkstyle). We then create a new <path> in
ant that picks these files up as we need them.
<property name="root" location="../../"/>
<property name="lib.ant" location="${root}/ant"/>
<path id="ant.classpath">
<path location="${lib.ant}/custom/ant-junit.jar"/>
<path location="${lib.ant}/custom/checkstyle.jar"/>
<path location="${lib.ant}/custom/jalopy.jar"/>
</path>
<taskdef name="checkstyle"
classname="com.puppycrawl.tools.checkstyle.CheckStyleTask"
classpathref="ant.classpath"/>
OR, instead of using ant tasks, you could use executables with the same
logic:
<exec executable="${root}/clearcase/bin/cleartool.exe" dir=".">
<arg line="co -c 'check out file' myfile.java"/>
</exec>
BUT, make sure you check for OS and platform to ensure you call the
executable that is appropriate.
2. we allow everybody to use whatever "shell" they wish, so long as they
have bash in their path. This means that we can write all of our scripts as
.sh scripts, which greatly minimizes the overhead of managing script files.
The nice thing is you can even integrate these shell scripts with your ant
scripts if necessary.
example:
<exec executable="bash" dir="${whereever}">
<arg line="yourscript.sh"/>
</exec>
regards,
d.
-----Original Message-----
From: Lars Chr. Hausmann [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 8:24 AM
To: [EMAIL PROTECTED]
Subject: Platform indepent build environment suggestions
Hey,
At my work I am in the middle of refactoring the build enviroment/build
system (referred to as build environment in the rest of this mail)
consiting of ant scripts, shell scripts etc. I was thinking that some of
you might have had a similar task or done something, which can be of use
to me. So I was hoping that I could get some good ideas.
I will try to sketch the current solution, and then the solution that I
think would be the most optimal one, and maybe some of you could provide
some input to whether that is feasible or you might have some other
suggestions. (References would be fine as well).
Besides ant we use a lot of tools/utilies like jalophy, checkstyle,
junit etc.
Currently, the developer does not need to setup anything on his machine,
it is all done by one script. I.e. before running ant, a script is
run that sets up classpath and other relevant environment variable for
developer _including_ classpath to the tools that are being used. When
the script has been run, the develop is free to use ant to compile and
test his work.
The catch is that we're currently developing under windows (some under
solaris) but it all has to be tested under solaris, so we have the ant
files and we have two sets of scripts that sets up the environment (one
set for windows and one set for solaris). It has (of course) turned out
to be a nightmare to maintain these two sets and keep the synced.
Futhermore some developers run the standard windows cmd.exe others run
cygwin. So this all leads to a lot of files having to be maintained.
Therefore ...
I was wondering/hoping if it would be possible to just have to set
ANT_HOME and then the all the rest could be handled by ant. I somehow
doubt that it is doable since I figure that the classpath can not be
modified when ant is running, so the classpath to our tools have to be
set before running ant, or have I missed something ?
That is it would be ideal for me if I could scrap the setup files (.bat
and unix shell scripts) and do it all with ant. Ant would then have to
set up classpath and enviroment variables as the first thing it does. I
have looked into .antrc and ant_{pre|post).bat, but I'd rather only have
the ant XML files if it is possible.
Any comments/ideas ?
Best,
Lars Chr. Hausmann
--
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]>
