Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <user@ant.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <462E3D51.4030908@calicojack.co.uk>
Date: Tue, 24 Apr 2007 18:24:33 +0100
From: Rick Moynihan <rick@calicojack.co.uk>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Ant Users List <user@ant.apache.org>
Subject: Re: AW: Using ant as a cross platform java process launcher
References: <EF39D77A486C234B9D9933091CE6D21E24F311@z011034.bk.fin.local>
 <462DE615.9030207@calicojack.co.uk> <462E1E60.8060101@apache.org>
In-Reply-To: <462E1E60.8060101@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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:
>>
>> * http://classworlds.codehaus.org/launchusage.html
>> * http://wrapper.tanukisoftware.org/doc/english/introduction.html
>>
>> 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:

http://jakarta.apache.org/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

True.

>>
>> 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: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org