ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: AW: Using ant as a cross platform java process launcher
Date Tue, 24 Apr 2007 15:12:32 GMT
Rick Moynihan wrote:

> Obviously I understand that ANT is a critically important piece of 
> infrastructure for a huge number of projects, and I understand that 
> ANT's primary focus is and always will be as a build tool.
> My only point is that *MAYBE* if it is not too much work, ANT can be 
> adapted to also fill this role.  I have looked at other projects such as:
> *
> *
> However I personally feel that reusing ANT build files for this sort of 
> thing is a more elegant solution, as it can leverage knowledge of ANT 
> for configuration of classpaths, properties, etc...

I actually use <wrapper> and do think its file format is a bit 
low-level. FWIW, the way we use it is to bridge up to somehing that is 
derived from Ant's launcher code, from which we jump out to the 
smartfrog deployment stuff.

Here is why I did it this way
  -wrapper works, is fully debugged, tested against various JDKs and 
versions of windows
  -smartfrog is somewhat debugged, uses reflection tricks to catch java 
signal handlers on the Unix+Sun JVM combination, and handles shutdown.

Ant launcher does one thing nicely: loads directories of JARs, in a 
single classloader that you can't then discard. It doesnt do cleanup 
when terminated aggressively.

> *If* the ant-launcher could be modified to support this use-case without 
> any external dependencies etc, I feel it would nicely fill a need in the 
> Java community.  Obviously adopting ANT to a task it was not designed 
> for is not a decision that should be taken lightly, but I feel it would 
> be valuable, and can't see why it should impact ANT's use as a build tool.

Well, there's varions types of changes.

(a) small tweaks (e.g the -main) option, that let people do interesting 
things that keep ant a build too.
(b) big changes with unpredictable maintenance costs that either
   -stop ant building from the ground up or
   -increase test and maintenance costs

> At the end of the day, I like commons launcher and would be completely 
> happy with it, if it had a community behind it, willing to fix the few 
> bugs I have encountered and drive some more features.
> So, my current options appear to be either:
> 1. Suggest the ANT project adopts the use-case of an application launcher.

Remember that "wrapper" is far more complex than Ant's launcher, as it 
starts from NT services and linux daemons. We dont want to go there.

Also up and coming is more dynamic ways of setting up the classpath, 
like Ivy, OSGi, etc. Making a good command line and daemon launcher for 
that would be interesting.

> 2. Patch commons-launcher myself (which I may well do) and persuade the 
> project maintainers to accept my patches (unlikely given the projects 
> lack of developers/community).

actually, an inactive project is often the one most willing to take on 
warm bodies

> 3. Fork commons-launcher and maintain it outside of Apache.

Given that I have a copy of some of ant's launcher code inside our own 
codebase, this is the easiest option for a single-use project, but 
avoids a lot of the feedback that a proper, live community can do.

> The first suggestion is the lowest cost to me, as it means others can 
> maintain, run and manage the project.  I appreciate that many factors 
> are likely to prevent this.  If ANT can be modified in the manner you 
> suggest, what are the barriers?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message