ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Moynihan <>
Subject Re: AW: Using ant as a cross platform java process launcher
Date Tue, 24 Apr 2007 17:24:33 GMT
Steve Loughran wrote:
> 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.

Wrapper looks to be a good piece of software, and one that I have 
considered, though I'm reluctant to throw away the ANT launch scripts I 
am using with commons-launcher.  Commons Daemon:

is another Apache project which aims to do what wrapper does, i.e. start 
daemons/services in a cross platform manner.  Unfortunately it also 
lacks any community to speak of and appears to have a long list of 
unresolved JIRA issues.

At the moment I have no experience with either wrapper or commons-daemon 
as I see no need to take on their extra complexity.  Your use of 
ant-launcher, wrapper, and smartfrog seems like a nice bespoke solution 
to the problem.  What I would love is to be able to start Java software 
with an ANT script at the command line, then later reuse the 
same/(highly-similar) ANT script in combination with something like 
wrapper or Commons Daemon.  In this latter case the ANT script would be 
used in place of wrappers configuration of the classpath.  I think that 
this integration would (if possible) be really nice; it is perhaps also 
a generalisation of the type of system you have implemented.

>> *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

I'm obviously not proposing we adopt (b).  I also use ANT extensively as 
a build tool and would hate to see ANT's role as a build tool adversely 
effected.  I would hope what I am proposing is *EXACTLY* in line with 
(a), though I am rather clueless as to all the issues involved.  Infact 
the use of a -main option is exactly what I had in mind.

>> 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.

I entirely agree on ANT NOT becoming a process for starting 
services/daemons.  What I think I am suggesting is the use of ANT as a 
DSL for setting a Java programs classpath, various properties, and 
perhaps some clean-up or initialisation (think tidying log files, 
creating directories etc).  If this same system could then be used by 
wrapper/commons-daemon then so much the better, as I too strongly felt 
that wrappers configuration was too low level.

>> 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.

Agreed.  I actually have a slightly modified version of commons-launcher 
which allows use of ant <import>'s.

>> 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:

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

View raw message