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