Invoking an Ant task using a specific JVM

Sometimes you’d like to invoke Ant using a specific JVM, maybe because you want to compile using a well specified JDK implementation.

I solved this problem with a task like this:

<macrodef name="ant-jvm">

   <attribute name="target" />
   <attribute name="jvm" />
   <attribute name="antfile" default="build.xml"/>
   <attribute name="basedir" default="."/>
   <attribute name="args" default="-Dsample.value=xxx"/>
   <attribute name="taskname" default="ant"/>

   <sequential>

      <java classname="org.apache.tools.ant.launch.Launcher"
            fork="true"
            jvm="@{jvm}"
            failonerror="true"
            dir="@{basedir}"
            timeout="99999999"
            taskname="@{taskname}">

        <classpath>
            <pathelement location="${ant.home}/lib/ant-launcher.jar"/>
        </classpath>

        <arg value="-buildfile"/>
        <arg file="@{antfile}"/>
        <arg value="@{args}"/>
        <arg value="@{target}"/>
        <arg value="-Dbasedir=@{basedir}"/>
      </java>

    </sequential>

</macrodef>

You may use it instead of <ant> task and allows you to specify the jvm to use, something like this:

    <ant-jvm target="-do-ejbdoclet" jvm="${java-1.3}/bin/java" />

Quick and dirty, but it works

A usecase is an object.

It seems naive, doesn’t it? It seems to be that sort of thing that everyone know, right? Well, get into your code and, please, find the object representing a usecase. You didn’t find it, did you? Object Oriented is far away from being adopted, neither understood.

In these days I’m working on some code developed by one my fellow colleague, who’s absolutely a master in technology: he knows the very everything about each framework, tool and library… such a cool boy to work with! But it lacks OO, he always thinks in term of “how” and never of “what”, and its code is always “code”.

In my opinion, each usecase should be present in form of an object into your code, every system interaction should be present in form of a method exposed by the usecase object, the state of your system is the state of the usecase object. And, yes, this is not enogh, more to come. But start thinking about this, please, before switching to the next framework or tecnique. Please do business logic.