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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
