[exec] use of commons-logging
Hi, I've been looking at the use of commons logging in exec. Coming from ant dev, it would be nice to refactor ant to use the commons-exec package, but Ant has it's own logging mechanism (using logging listeners), and I'm pretty sure that the ant code base will not change to using commons-logging throughout except as the listener, and as far as I'm aware the ant team want to keep the ant bootstrap as minimal as possible (require nothing but an xml parser and a jdk). [1] There's also the problem of the minimum version of Java supported by commons-exec, though this looks like it will be less of a problem. Still it would be nice to use these components in more than one place so that changes/fixes don't have to be copied about, I'm just not too sure that it will happen anytime soon [1]http://marc.theaimsgroup.com/?l=ant-devm=112729258826251w=2 Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[exec][patch] basic ant file + properties
Just in case you don't want to use Maven ;). Eventually got some time
to play with OS dev again (w00t).
Kev
?xml version=1.0 encoding=UTF-8?
!--
===
Apache Commons-Exec build file
Copyright (c) 2005 The Apache Software Foundation. All rights
reserved.
===
--
project name=exec default=test basedir=.
!-- basic shared properties --
property file=${basedir}/build.properties/
!-- jars required for compilation --
path id=compile-time-jars
fileset dir=${basedir}/${lib.dir}/junit/${junit.version}
includes=junit.jar /
fileset dir=${basedir}/${lib.dir}/log4j/${log4j.version}
includes=*.jar /
/path
target name=clean
description=Removes previously built artefacts
delete dir=${build.dir} /
/target
target name=init
depends=clean
description=Sets up working dirs and other tasks
mkdir dir=${basedir}/${build.dir} /
/target
target name=compile
depends=init
description=Compiles application
javac srcdir=${src.dir}
debug=${debug}
optimize=${optimize}
deprecation=${deprecation}
failonerror=${failonerror}
destdir=${build.dir}
classpath
path refid=compile-time-jars /
/classpath
/javac
/target
target name=test
depends=init
description=Runs unit tests
/target
/project#compiler
build.compiler=jikes
#dirs
lib.dir=lib
src.dir=src
build.dir=build
#javac options
debug=true
optimze=false
deprecation=true
failonerror=true
#dependencies
log4j.version=1.2.8
junit.version=3.8.1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec][patch] basic ant file + properties
Brett Porter wrote: Hi Kev, Glad you've got some time to play :) I had a look at this and all the functionality except for parameterisation of the debug/deprecated/optimize variables seems to be included in the build.xml file I created - what was the reason for replacing it? Sorry I was using the initial contribution patch as my baseline - I didn't checkout the repo - didn't even realise that there was a build file available! Please use Bugzilla (with an [exec] prefix) for patches - I think they are easier to track and won't clog up the list as much. ok, bugzilla from now on. Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec][patch] commons-exec initial contrib
Niklas Gustavsson wrote: Kev Jackson wrote: I'm not a fan of maven, so I'll write up a quick build file for it, I'll also look into javadoc/unit tests as soon as I have some time (perhaps tomorrow) Great! With regards for the unit tests I personally think that the first step should be to refactor the launcher so that they do not directly call Runtime.exec(). That currently makes unit testing hard. Ok, when I have time I'll look into it - I'm currently bogged down with some very dull development for 10+ hours a day, so I've neither the time nor inclination to spend on re-factoring etc right now (I thought I'd get time this weekend - I was wrong :( ) Sorry for no contributions, I'll try and get something to you as soon as I've reduced my workload a little Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec][patch] commons-exec initial contrib
(This email with a .zip attachment does not seem to get through to the list. And since there's no component for exec in bugzilla, I've uploaded the file to http://www.protocol7.com/tmp/commons-exec-initial-20050802.zip instead. If I should send it somehow different, please enlighten me.) Attached is the initial contribution, I've zipped it since it's largish. Note that there are tons of problems with this code (e.g. design issues, dependency on JCL, lack of unit tests/javadoc) but IMHO it's a good enough starting point. It uses maven2 for building and builds with the latest SVN version of maven2. If you have any issues with the code, maven2 setup, patch or anything, please tell me and I'll get it fixed! I'm not a fan of maven, so I'll write up a quick build file for it, I'll also look into javadoc/unit tests as soon as I have some time (perhaps tomorrow) Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
This is a very short description of the cleaned up Ant exec task design: * Exec: the former Ant task class used to create and configure Execute instances. Now mainly a convience class for starting new Execute instances. * Execute: the main class for running one process. Handles creation and configuration of the necessary objects (stream pump, watchdog, process destroyer). Can wait for the full execution time to enable synchronous return of the process return code or spawn a process to run async. * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. * WatchDog: used to time out a running process. After a given time has passed, the process is checked if it's still running and there after destroyed. * CommandLauncher: a family of classes for actually starting the processes. Implementations exist for e.g. Java 1.1, Java 1.3, WinNT, Mac, VMS and so on. These classes handles the platform specifics. * Environment: used to retrive the current environment as well as setting new environment variables. Reading the current environment is done using platform specific commands (e.g. cmd /c set, env, /bin/env) and parsing the result. This could of course be improved on J2SE 5.0 to use System.getenv() instead. * StreamPumper: used to read/write the three stream (in, out, error) simultaniously. * CommandLine: class for handling (e.g. parsing, quoting) command lines. It might be worth extracting the interface from Ant, creating an implementation (using the interface) and then using this in a branch of Ant just to test that we've extracted all the necessary functionality. IIRC Environment is really derived through JavaEnvUtils (though I'll have to check source). A common interface for a commandLine would allow us to create platform specific commandLines depending on environment 2c Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Commons Exec
Scope of the package The package shall create and maintain a process execution package written in the Java language to be distributed under the ASF license. The Java code might also be complemented with scripts (e.g. Perl scripts) to fully enable execution on some operating systems. The package should aim for supporting a wide range of operating systems while still having a consistent API for all platforms. I'm interested in this too, from a couple of messages on the Ant list, some way of accessing symlinks/NT junctions (sorry can't find the post right now)? in a platform independent manor would be good. I'd be happy to help out with code contributions etc Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
