Un"bat"ing development: how to realize a forked ant

[Stefan Schulz <sc...@ivs.tu-berlin.de>]

Hi,

the goal of my actions is to have a set of scripts, so I can develop and
deploy a java system with ant using windows as well as unix/linux.

By now, I have batch files to set several environment variables and
options for ant, jvm, and thirdparty java-tools. Of course, this is
awful to maintain, as the environment setting is at least duplicated
(.bat and .sh).

Unfortunately, in ant one cannot reset properties or environment
variables. Hence, I was going to use a "Meta"-build file, which sets the
needed variables 
and then calls the real build file by using the java-task with ant.
Doing so, the new ant task does not find javac anymore. JAVA_HOME is
incorrect, and setting JAVA_HOME with the java-task is ignored.

What I would actually need is something like this:
<ant fork="true" ...><env key="some" value="thing"/></ant>

Has anyone tried to do something similar or has anyone an idea, why my
approach fails?

Hope this is somewhat understandable :)

Thanks in advance
Stefan

RE: Un"bat"ing development: how to realize a forked ant

[Stefan Schulz <sc...@ivs.tu-berlin.de>]

Hi,

this seems to be another good approach.

I now made ant to execute ant by the application of the java task. That
is, I have an extra build.xml (could also be a target in the project's
build.xml) that sets up the environment and calls a "local" ant. What I
learned from past projects is, that having 10 developers results in
different tool versions installed for each of them. That is ant, java,
and others. Hence, my project always includes the tool versions it
relies on. So, ant and at least the jre are local. I don't think the
multiplication of this tools' files by each project matters at nowadays
storage prices. The meta-build file will call the local ant, so the
versions of ant and needed extension or java libraries are guaranteed.

The major problem I had with starting ant was, that ant did not care
about setting JAVA_HOME. Including the java path directly finally helped
to find the required jdk libraries. The alternative would be to use the
<exec>-task, as described by Dominique.

My target looks somewhat like appended below. Maybe it is of use to
anyone or someone has a smarter idea.

Regards
Stefan


<target name="buildproject" description="Executes ant with a redefined
environment.">
  <!-- Define custom environment variables -->
  <dirname property="project.home" file="${ant.file}"/>
  ...
  <!-- Define the local homes and paths -->
  <property name="project.ant.home" location="ant"/>
  <path id="project.ant.path">
    <fileset dir="${project.ant.home}">
      <include name="lib/*.jar"/>
    </fileset>
  </path>
  <property name="project.java.home" location="java"/>
  <path id="project.java.path">
    <fileset dir="${project.java.home}">
      <include name="lib/*.jar"/>
    </fileset>
  </path>
  <property name="project.thirdparty.home" location="thirdparty"/>
  <path id="project.thirdparty.path">
    <fileset dir="${project.thirdparty.home}">
      <include name="**/*.jar"/>
    </fileset>
  </path>
  <!-- construct the class path to use -->
  <path id="local.class.path">
    <path refid="project.java.path"/>
    <path refid="project.ant.path"/>
    <path refid="project.thirdparty.path"/>
  </path> 
  <!-- Execute ant on the property build file -->
  <java classname="org.apache.tools.ant.Main"
        failonerror="yes"
        fork="yes"
        maxmemory="128m"
        dir="develop">
    <classpath refid="local.class.path"/>
    <jvmarg value="-Dant.home=${project.ant.home}"/>
    <jvmarg value="-Dbasedir=${project.home}"/>
    <jvmarg value="-DCUSTOM_ENV_VAR=${custom.env.var}"/>
    <arg line="${ant.arguments}"/>
  </java>
</target>

Re: Un"bat"ing development: how to realize a forked ant

[Matt Quail <ma...@cortexebusiness.com.au>]

I have had a similar problem to you; I'm sure many people do.

One approach I have used successfully is to have an ant target that generates 
your ".sh" and ".bat" files. I've always put that target inside my main 
build.xml file, but you could put it in a "meta" file if you like.

So, when I do a "fresh checkout", I do this:

$ ant setup

This produces two files; ./build.bat and ./build.sh. And then I never call 
"ant" again, I do this:

$ ./build.sh code

So, ./build.bat might look like this (it sets up paths and calls Ant):

---
@echo off
@setlocal
set PATH=BLAHBLAH;%PATH%
set CLASSPATH=BLAHBLAH1;BLAHBLAH2
call ant.bat -f new-build.xml %*
@endlocal
---

And the "setup" target may look like this:
> ---
>     <target name="setup"
>             description="Setup the build.bat front end script">
>         <pathconvert property="win32.oracle.home" targetos="windows">
>             <path>
>                 <pathelement location="${oracle.home}"/>
>             </path>
>         </pathconvert>
>         <pathconvert property="win32.clover.classpath" refid="clover.classpath"
>                      targetos="windows"/>
>         <echo file="./build.bat">@echo off
> @setlocal
> set PATH=${win32.oracle.home}\bin\${oci.version};%PATH%
> set CLASSPATH=${win32.clover.classpath}
> call ant.bat -f new-build.xml %*
> @endlocal
>         </echo>
>         <echo>Created ./build.bat</echo>
>     </target>
> ---

You can see that I've used previously defined properties to set up the PATH and 
CLASSPATH, and that I've made sure those properties are in "win32" mode. Those 
previously defined properties can be made developer-specific because we have 
this at the top of the build file:

     <property file="${user.home}/developer-locations.properties"/>


I'd be interested in what other ant users think of the scheme, and other 
schemes they have used.

On reason I find this scheme particularly useful is that it means I can avoid 
putting 3rd party tool-jars in my ANT_HOME/lib directory, since they are in the 
classpath instead. The reason I dislike putting things in ANT_HOME/lib is that 
I often get a version clash (for example, I might be working on two different 
projects that are using different version of clover.jar).

I also think this is somewhat easy to maintain, because it becomes part of the 
maintainance of the build.xml script... it's not some "extra" set of files. (I 
put build.bat and buid.sh in the .cvsignore).

=Matt

Stefan Schulz wrote:
> Hi,
> 
> the goal of my actions is to have a set of scripts, so I can develop and
> deploy a java system with ant using windows as well as unix/linux.
> 
> By now, I have batch files to set several environment variables and
> options for ant, jvm, and thirdparty java-tools. Of course, this is
> awful to maintain, as the environment setting is at least duplicated
> (.bat and .sh).
> 
> Unfortunately, in ant one cannot reset properties or environment
> variables. Hence, I was going to use a "Meta"-build file, which sets the
> needed variables 
> and then calls the real build file by using the java-task with ant.
> Doing so, the new ant task does not find javac anymore. JAVA_HOME is
> incorrect, and setting JAVA_HOME with the java-task is ignored.
> 
> What I would actually need is something like this:
> <ant fork="true" ...><env key="some" value="thing"/></ant>
> 
> Has anyone tried to do something similar or has anyone an idea, why my
> approach fails?
> 
> Hope this is somewhat understandable :)
> 
> Thanks in advance
> Stefan
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 
> 
>