ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Hatton" <khat...@axiomsystems.com>
Subject RE: Platform indepent build environment suggestions
Date Wed, 18 Dec 2002 14:53:12 GMT
What we're trying to do (so I won't pretend for now that it works perfectly) is to put all
the dependencies (libraries, tools, etc.) under SCM, then if you've got the complete set of
files all the paths are defined relatively. This gets around developers having different versions
of the tools, for example.

There was a discussion on this list a week or two ago about whether this was a good idea or
not, I think the conclusion was "if it works for you ..." rather than a definitive good/bad
practice.

Keith


-----Original Message-----
From: David McTavish [mailto:dmctavish@SANDVINE.com]
Sent: 18 December 2002 14:46
To: 'Ant Users List'
Subject: RE: Platform indepent build environment suggestions


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:lch@systematic.dk] 
Sent: Wednesday, December 18, 2002 8:24 AM
To: ant-user@jakarta.apache.org
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:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message