I also have multiple versions of Ant installed. If you're runnig cygwin or Ksh/Bash/Z-Shell on Unix put something like this in your .bashrc or .zshrc:
function ant13
{
export ANT_HOME=/c/apps/jakarta-ant-1.3
export JAVA_HOME=/d/jdk1.3
export JAVACMD=$JAVA_HOME/bin/java
$ANT_HOME/bin/ant $*
}
function ant14
{
export ANT_HOME=/c/apps/jakarta-ant-1.4.1
export JAVA_HOME=/d/jdk1.3
export JAVACMD=$JAVA_HOME/bin/java
$ANT_HOME/bin/ant $*
}
etc.
On Cygwin, for the default version of Ant, I put the following scripts in /etc/profile.d. Each time I start a Bash shell they are automatically run.
$ cat /etc/profile.d/ant-1.5.1.sh
#!/bin/sh
echo "Initializing for Ant 1.5.1 ..."
export ANT_HOME=/c/apps/ant-1.5.1
export PATH="$ANT_HOME/bin:$PATH"
To set up the Java SDK:
$ cat /etc/profile.d/sun_sdk_1.3.1_03.sh
#!/bin/sh
echo "Initializing for Java SDK 1.3.1_03 ..."
export JAVA_HOME=/c/jdk1.3.1_03
export PATH="$JAVA_HOME/bin:$PATH"
If you want to stick with Windows .bat files, create the following which works win Win 9x/Me/NT/2K/XP:
@echo off
REM ant.bat - run Ant 1.5.1
set ANT_HOME=C:\apps\ant-1.5.1
set JAVA_HOME=C:\jdk1.3.1_03
call "%ANT_HOME%\bin\ant" %1 %2 %3 %4 %5 %6 %7 %8 %9
@echo off
REM ant13.bat - run Ant 1.3
set ANT_HOME=C:\apps\ant-1.3
set JAVA_HOME=C:\jdk1.3.1_03
call "%ANT_HOME%\bin\ant" %1 %2 %3 %4 %5 %6 %7 %8 %9
Put these ant*.bat scripts in you PATH or C:\WINDOWS / C:\WINNT.
I just don't think proliferating copies of Ant is the solution.
-Bill
Patrick Lightbody wrote:
Bill, My desire to include ant also stems from the fact that sometimes some of us need multiple copies of ant hanging around. For example, I have an old project that MUST be built with ant 1.3 (don't ask, it's a long story). So moving in this direction would be a win. Either way, Like I've said before, you could still work like you always have. The only difference is that an extra 1MB will need to be checked out initially. Not a heavy price in my opinion.-Pat ----- Original Message ----- From: "Bill Burton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "os-dev" <[EMAIL PROTECTED]> Sent: Tuesday, December 17, 2002 8:58 AM Subject: Re: [Opensymphony-developers] Re: [OS-webwork] OpenSymphony build processHello, Patrick Lightbody wrote:If we don't include ant but instead tell people to download ant, I can promise you that the mavenites will be clamoring for maven buildsinstead,since downloading maven or downloading ant are parallels. Besides,build.xmlis there, you can use ant just like you always have.In the "old days" before Ant was the defacto standard Java build tool, including Ant would be okay. But nowdays having Ant installed is a requirement for any Java developer working with Open Source projects. Also, I don't think including Ant is going to make any difference for those who want to use Maven. They will want to use it anyways so including Ant is just extra space and a maintenance issue and will not have any effect. If Ant is not included, there doesn't need to be a build.sh and build.bat.src/java, src/test, src/etc, src/examples.... what can I say? I go both ways, but lately I've been happier about putting everything in subdirsinsrc. Keeps things less-flat.The main reason for a src/java is there can be other kinds of source than Java :) .Coding style: we need it. Live with it. It's nice. Basically, jalopy is REALLY cool and works very well. In this build script, any code that is compiled will be formatted as well. We'll immediately have the samecodingstandard in all our classes, regardless of people's choices for coding.Soyou can write your code your own way, compile, check in, and there is no work on your part to conform to a coding convention. We have failed in trying to enforce a particular coding convention on a per-project basis (look at the OSWorkflow sources, for example).Yeah. It's even a pain when some people are using hard tabs let alone different coding styles.Coverage reports and unit test reports... they should be on the websiteatleast, and I tend to think along the lines of: anything on the website should also be in the distro.Rather, buildable from the distro. However, if this requires various third party jars, they should probably not be included unless they are few and small or maybe a key part of the build.-Pat-Bill----- Original Message ----- From: "Hani Suleiman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "os-dev" <[EMAIL PROTECTED]> Sent: Tuesday, December 17, 2002 8:23 AM Subject: [Opensymphony-developers] Re: [OS-webwork] OpenSymphony build processOn the whole this seems reasonable. Some reservations though: I really hate the src/java, src/blah structure. I'm trying to find a logical reason for this hatred though but not succeeding ;) I'd like src to just contain java. Maybe I'm old fashioned. I am vehemently opposed to build.bat and build.sh. All you need is ant. I'm likewise against checking in ant to every single project. It's a fairly reasonable assumption that people who might need to build a project have ant installed (you don't bundle gnu make with every project that has a Makefile). Likewise, I'm against forcing a particular coding style. the coverage reports and suchlike are just eye candy really, so I'm ambivalent there. Also, I'm not sure there is much point in adding code coverage results or test cases to a distribution. Those are aimed at end users, and huge downloads full of mostly useless cruft do not encourage warm fuzzy happy feelings towards fellow man/developer. On Tuesday, December 17, 2002, at 11:11 AM, Patrick Lightbody wrote:I think we should standardize the OpenSymphony build process. Here is my first cut at it, please comment: - attached is a build script for OSCore, but as you can see, it's very generic. We should use this as a base and not add much more to it, mostly instructions on how to package files like ejb-jar.xml in to the jar itself. -the directory structure of CVS would look like: project/ project/docs project/lib project/lib/build project/lib/build/jalopy project/lib/core project/lib/optional project/src/etc project/src/java project/src/test project/src/example [if needed] There would be build.bat and build.sh scripts to build the project, meaning CVS is self-contained (no ant install needed). So that means that ant and all the optional tasks would be in lib/build. - distribution structure: project.zip/ project.zip/project.jar project.zip/docs/ project.zip/docs/api project.zip/docs/clover project.zip/docs/junit project.zip/docs/lib project.zip/docs/src - if you see in the script, there would be three extra tasks built in to the build script: * jalopy (code formatting) * junit (unit tests) * clover (test coverage reports) - Documentation is assumed to be HTML right now, but pending Ken's final thoughts, this would change. Also, the junit and clover reports could be run through XSLs as well. <build.xml>
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
