You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jose Alberto Fernandez <JF...@viquity.com> on 2000/09/20 01:34:05 UTC
A new field for ANT
Up to now we have been using ANT for builds.
Now I am thinking on using ANT as a configuration and starter of
applications, in particular server/side apps that ussually need to run with
a large set of parameters and such.
The idea here is that ANT will prepere things appropriatelly and then just
call <java> with the correct arguments given the configuration. All running
on the same JVM and so on.
We may never return from this call (System.exit()).
One of the things it seem to be necessary is ways to create multiple
concurrent processes that work in the background, like starting
"rmiregistry" before starting the application, and so on.
Any ideas/concerns on how to do this, what would be needed, etc...
Jose Alberto
RE: A new field for ANT
Posted by Conor MacNeill <co...@ebinteractive.com.au>.
Jose Alberto,
Another one of my long dormant patches provided the ability to run
concurrent processes within a target. I used this for running Junit tests of
EJBs running in a weblogic server.
I think I can include this soon. It just added an "async" attribute to all
tasks.
We currently use ant to run server processes in our development environment.
We generally run one copy of ant per server, however.
Conor
--
Conor MacNeill
conor@cortexebusiness.com.au
Cortex eBusiness
http://www.cortexebusiness.com.au
-----Original Message-----
From: Jose Alberto Fernandez [mailto:JFernandez@viquity.com]
Sent: Wednesday, 20 September 2000 10:34
To: Ant Project List (E-mail)
Subject: A new field for ANT
Up to now we have been using ANT for builds.
Now I am thinking on using ANT as a configuration and starter of
applications, in particular server/side apps that ussually need to run with
a large set of parameters and such.
The idea here is that ANT will prepere things appropriatelly and then just
call <java> with the correct arguments given the configuration. All running
on the same JVM and so on.
We may never return from this call (System.exit()).
One of the things it seem to be necessary is ways to create multiple
concurrent processes that work in the background, like starting
"rmiregistry" before starting the application, and so on.
Any ideas/concerns on how to do this, what would be needed, etc...
Jose Alberto