Re: Status of the Sandbox?
Henri Yandell wrote: exec - Niklas did some work last July, but nothing's happened since. Anyone know if the future holds anything for exec? I hope to be able to spend some more time on exec pretty soon. Mostly to move to the new M2 build and then maybe get a 1.0-RC1 out (is that appropriate for a sandbox project?). And I plan to maintain it after that, but probably not add a lot of functionality. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Latest 2.0 RC Ready
Rory Winston wrote: (Resending as I left out commons-user) Hi all I have cut a new RC, with some changes and fixes, many of which were distribution-related and suggested by Niall earlier (thanks Niall). RC (minus MD5s etc for now) is here: http://people.apache.org/~rwinston/commons-net-2.0/ Some users have been testing out this 2.0 branch for a while, so I'm going to kick off a vote pretty soon. Any comments welcome. * I ran all our unit tests in FtpServer using both the full JAR and the FTP-only JAR. Both works as expected. * commons-net-ftp-2.0.0-SNAPSHOT.jar got the LICENSE.txt file in the root of the JAR rather that in META-INF as would be expected * commons-net-ftp-2.0.0-SNAPSHOT.jar is missing NOTICES.txt * Having release notes in the bin and src distributions would be nice * The bin distribution contains a readme about how to build, this would not be that interesting in with the binaries. * Signing would of course be needed for the release, but you already noted that :-) I'm really happy that this will be released, right now we build it on out own for FtpServer. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTP reply list never cleared
Hi When using the net Java 5 branch, the replies returned from the server is stored in a list that is not emptied between commands. This means that when for example printing the replies with a ProtocolCommandListener you will get the full history of replies rather than the last one. The following patch seems to work: Index: src/main/java/org/apache/commons/net/ftp/FTP.java === --- src/main/java/org/apache/commons/net/ftp/FTP.java (revision 497851) +++ src/main/java/org/apache/commons/net/ftp/FTP.java (working copy) @@ -266,7 +266,7 @@ int length; _newReplyString = true; -//_replyLines. setSize(0); +_replyLines.clear(); String line = _controlInput_.readLine(); /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Statistics for ftp
Susanne Lefvert wrote: Do you know if there's a command line version for the statistics page shown in the ftpd_ui? I'd like to get statistics for an always running ftp server without having to open the gui or restart the ftp server. Ideally, I'd like to view stats in a web page. Please ask this question over at ftpserver-dev@incubator.apache.org as FtpServer is not part of commons. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS client auth required
Niklas Gustavsson wrote:
Rory Winston wrote:
Hi Niklas
Done. Thanks
Thanks! The build seems broken at the moment as
org.apache.commons.net.PrintCommandListener is missing. COuld you fix
this or do you produce binaries somewhere?
The attached patch fixes the broken build (still can't get tests to run
but I could build myself a binary :-).
For some reason the PrintCommandListener was deleted in rev 437767 so it
you don't want it in the code, please ignore this patch :-)
/niklas
Index: src/main/java/examples/nntp/ExtendedNNTPOps.java
===
--- src/main/java/examples/nntp/ExtendedNNTPOps.java(revision 480955)
+++ src/main/java/examples/nntp/ExtendedNNTPOps.java(working copy)
@@ -18,12 +18,13 @@
import java.io.IOException;
import java.io.PrintWriter;
-import org.apache.commons.net.PrintCommandListener;
import org.apache.commons.net.nntp.Article;
import org.apache.commons.net.nntp.NNTPClient;
import org.apache.commons.net.nntp.NewsgroupInfo;
+import examples.PrintCommandListener;
+
/**
* Simple class showing some of the extended commands (AUTH, XOVER, LIST
ACTIVE)
*
Index: src/main/java/examples/nntp/post.java
===
--- src/main/java/examples/nntp/post.java (revision 480955)
+++ src/main/java/examples/nntp/post.java (working copy)
@@ -23,13 +23,14 @@
import java.io.PrintWriter;
import java.io.Writer;
-import org.apache.commons.net.PrintCommandListener;
import org.apache.commons.net.io.Util;
import org.apache.commons.net.nntp.NNTPClient;
import org.apache.commons.net.nntp.NNTPReply;
import org.apache.commons.net.nntp.SimpleNNTPHeader;
+import examples.PrintCommandListener;
+
/***
* This is an example program using the NNTP package to post an article
* to the specified newsgroup(s). It prompts you for header information and
Index: src/main/java/examples/nntp/MessageThreading.java
===
--- src/main/java/examples/nntp/MessageThreading.java (revision 480955)
+++ src/main/java/examples/nntp/MessageThreading.java (working copy)
@@ -20,13 +20,14 @@
import java.io.PrintWriter;
import java.net.SocketException;
-import org.apache.commons.net.PrintCommandListener;
import org.apache.commons.net.nntp.Article;
import org.apache.commons.net.nntp.NNTPClient;
import org.apache.commons.net.nntp.NewsgroupInfo;
import org.apache.commons.net.nntp.Threader;
+import examples.PrintCommandListener;
+
public class MessageThreading {
public MessageThreading() {
}
Index: src/main/java/examples/PrintCommandListener.java
===
--- src/main/java/examples/PrintCommandListener.java(revision 0)
+++ src/main/java/examples/PrintCommandListener.java(revision 0)
@@ -0,0 +1,49 @@
+/*
+ * Copyright 2001-2006 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package examples;
+
+import java.io.PrintWriter;
+import org.apache.commons.net.ProtocolCommandEvent;
+import org.apache.commons.net.ProtocolCommandListener;
+
+/***
+ * This is a support class for some of the example programs. It is
+ * a sample implementation of the ProtocolCommandListener interface
+ * which just prints out to a specified stream all command/reply traffic.
+ * p
+ ***/
+
+public class PrintCommandListener implements ProtocolCommandListener
+{
+private PrintWriter __writer;
+
+public PrintCommandListener(PrintWriter writer)
+{
+__writer = writer;
+}
+
+public void protocolCommandSent(ProtocolCommandEvent event)
+{
+__writer.print(event.getMessage());
+__writer.flush();
+}
+
+public void protocolReplyReceived(ProtocolCommandEvent event)
+{
+__writer.print(event.getMessage());
+__writer.flush();
+}
+}
\ No newline at end of file
Property changes on: src\main\java\examples\PrintCommandListener.java
___
Name: svn:eol-style
+ native
Index: src/main/java/examples/FTPExample.java
===
--- src/main/java/examples/FTPExample.java (revision 480955)
+++ src/main/java/examples/FTPExample.java (working copy)
@@ -22,7 +22,6 @@
import java.io.OutputStream;
import
Re: [net] FTPS client auth required
Thanks, making that settable makes a lot of sense. Would you mind doing
the same thing for the KeyManager as that would make client auth
possible? At least I'm not able to get it working without one :-)
I'm attaching the patch I use for the client auth tests in FtpServer.
/niklas
Rory Winston wrote:
Niklas
The current FTPSTrustManager implementation is a little bit sketchy -
maybe we could default to a more comprehensive validity check. I have
added the facility to plug in a custom trust manager to the FTPSClient,
as follows:
FTPSClient client = new FTPSClient();
client.setTrustManager(new X509TrustManager() {
public void checkClientTrusted(X509Certificate[] chain,
String authType) throws CertificateException {
...
}
public void checkServerTrusted(X509Certificate[] chain,
String authType) throws CertificateException {
...
}
public X509Certificate[] getAcceptedIssuers() {
...
}
});
Thanks for the patch, by the way.
Cheers
Rory
Niklas Gustavsson wrote:
Hi
I'm trying to create tests for client authentication for Apache
FtpServer. For this I'm using commons-net as the client but is running
into problems with the client auth support in FTPSClient. I'm setting
setNeedClientAuth(true) but still get problems due to FTPSClient
sending a null certificate chain. How should I set up my keystore so
that FTPSClient finds it and can use it to send the correct
certificate to the server for authentication? I've tried with the
javax.net.ssl.keyStore system property but to no avail.
Also, if I understand the current implementation of FTPSClient and
FTPSTrustManager. From what I can understand, the implementation only
checks if the service certificate is valid, not if it's trusted. Is
this correct? If so, this would probably be a security issue in that a
fake server serving up any valid certificate would be trusted by the
client. Is this the intended behavior?
/niklas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: src/main/java/org/apache/commons/net/ftp/FTPSClient.java
===
--- src/main/java/org/apache/commons/net/ftp/FTPSClient.java(revision
479111)
+++ src/main/java/org/apache/commons/net/ftp/FTPSClient.java(working copy)
@@ -23,6 +23,7 @@
import java.security.KeyManagementException;
import java.security.NoSuchAlgorithmException;
+import javax.net.ssl.KeyManager;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLException;
import javax.net.ssl.SSLServerSocketFactory;
@@ -80,6 +81,9 @@
/** The FTPS [EMAIL PROTECTED] TrustManager} implementation. */
private TrustManager trustManager = new FTPSTrustManager();
+/** The [EMAIL PROTECTED] KeyManager} */
+private KeyManager keyManager;
+
/**
* Constructor for FTPSClient.
* @throws NoSuchAlgorithmException A requested cryptographic algorithm
@@ -194,10 +198,10 @@
planeSocket = _socket_;
try {
- context.init(null, new TrustManager[] {
getTrustManager() } , null);
- } catch (KeyManagementException e) {
- e.printStackTrace();
- }
+context.init(new KeyManager[] {keyManager}, new TrustManager[] {
getTrustManager() } , null);
+} catch (KeyManagementException e) {
+e.printStackTrace();
+}
SSLSocketFactory ssf = context.getSocketFactory();
String ip = _socket_.getInetAddress().getHostAddress();
@@ -479,6 +483,22 @@
this.trustManager = trustManager;
}
+/**
+ * Get the currently configured [EMAIL PROTECTED] KeyManager}.
+ *
+ * @return the keyManager
+ */
+public KeyManager getKeyManager() {
+return keyManager;
+}
+
+/**
+ * Set a [EMAIL PROTECTED] KeyManager} to use
+ *
+ * @param keyManager The KeyManager implementation to set.
+ */
+public void setKeyManager(KeyManager keyManager) {
+this.keyManager = keyManager;
+}
-
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS client auth required
Rory Winston wrote: Hi Niklas Done. Thanks Thanks! The build seems broken at the moment as org.apache.commons.net.PrintCommandListener is missing. COuld you fix this or do you produce binaries somewhere? /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CODEC-52) Digest on InputStreams
[ http://issues.apache.org/jira/browse/CODEC-52?page=comments#action_12447320 ] Niklas Gustavsson commented on CODEC-52: Certainly not from my part :-) Digest on InputStreams -- Key: CODEC-52 URL: http://issues.apache.org/jira/browse/CODEC-52 Project: Commons Codec Issue Type: Improvement Reporter: Niklas Gustavsson Attachments: CODEC-52-patch.diff When calculating digests on large amount of data (for example large files) the current methods that takes a byte array or String in not sufficient. MessageDigest supports getting a digest for a stream. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTPS client auth required
Hi I'm trying to create tests for client authentication for Apache FtpServer. For this I'm using commons-net as the client but is running into problems with the client auth support in FTPSClient. I'm setting setNeedClientAuth(true) but still get problems due to FTPSClient sending a null certificate chain. How should I set up my keystore so that FTPSClient finds it and can use it to send the correct certificate to the server for authentication? I've tried with the javax.net.ssl.keyStore system property but to no avail. Also, if I understand the current implementation of FTPSClient and FTPSTrustManager. From what I can understand, the implementation only checks if the service certificate is valid, not if it's trusted. Is this correct? If so, this would probably be a security issue in that a fake server serving up any valid certificate would be trusted by the client. Is this the intended behavior? /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLS for FTP
Rory,
Niklas Gustavsson wrote:
Niklas Gustavsson wrote:
Rory Winston wrote:
The FTPSClient needs the have a SSL enabled ServerSocketFactory set, e.g.:
client.setServerSocketFactory(SSLServerSocketFactory.getDefault());
I believe that the following patch which sets the server socket factory
to one that is SSL enabled solves the bug where commons-net FTPSClient
will fail on entering PROT P mode in active mode.
If you rather would like this as a JIRA issue, please tell me and I'll
create an issue.
/niklas
Index: src/main/java/org/apache/commons/net/ftp/FTPSClient.java
===
--- src/main/java/org/apache/commons/net/ftp/FTPSClient.java(revision
468975)
+++ src/main/java/org/apache/commons/net/ftp/FTPSClient.java(working copy)
@@ -25,6 +25,7 @@
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLException;
+import javax.net.ssl.SSLServerSocketFactory;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.TrustManager;
@@ -380,8 +381,10 @@
throw new SSLException(getReplyString());
if (DEFAULT_PROT.equals(prot)) {
setSocketFactory(null);
+setServerSocketFactory(null);
} else {
setSocketFactory(new FTPSSocketFactory(context));
+setServerSocketFactory(SSLServerSocketFactory.getDefault());
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLS for FTP
Susanne Lefvert wrote: Ok, I'll give this a try. Just fyi, I'm running the client in passive mode but I still get this error. These are the commands I'm using: FTPSClient ftps = new FTPSClient(true); ftps.addProtocolCommandListener(new PrintCommandListener(log)); ftps.connect(host, port); ftps.login(user, password); ftps.enterLocalPassiveMode(); ftps.execPROT(P); ftps.setFileType(FTP.BINARY_FILE_TYPE); ftps.storeFile(file.getName(), input); ftps.logout(); ftps.disconnect(); What's the error you're seeing? The major difference between my code and yours is that you running with implicit security. If I turned that on and configure FtpServer to use a SSLFtpSocketFactory it does work for me. This is still in my Eclipse environment. The passive mode however, also works in my Maven build. I've added a new test case which uses implicit security and commited into our SVN. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLS for FTP
Rory Winston wrote: Susanne It may be possible that there is a bug in the FTPSClient impl - can you post a transcript of the FTP commands and responses sent over the wire? I've now tested this with FtpServer and I think I got a clue as to what is going on. But, I would like to confirm my suspicions with you :-) I'm CCing the FtpServer list on the discussion. When using the PROT P command in active mode, the FTP server will try to connect using SSL to the client. In this case the server acts as the SSL client. However, this seems to fail and we get a cleartext data connection. My feeling is that this is because the commons-net SSLContext does not set a keystore it can't act as a SSL server. However, I haven't tested patching FTPSClient yet so I'm not sure. If I run in passive mode (where the FTPSClient will act as a SSL client and FtpServer as a SSL server also for the data connection) everything seems to work as expected. You can find my simple test case here: http://svn.apache.org/repos/asf/incubator/ftpserver/ssl-tests/trunk/src/test/org/apache/ftpserver/ssl/DataConnectionTest.java Note that this tests differs from what Susanne described as I get a into problems on a single STOR. This might be because I have some basic misconfiguration, is so feel free to point me the right way :-) /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLS for FTP
Niklas Gustavsson wrote: Rory Winston wrote: Susanne It may be possible that there is a bug in the FTPSClient impl - can you post a transcript of the FTP commands and responses sent over the wire? I've now tested this with FtpServer and I think I got a clue as to what is going on. But, I would like to confirm my suspicions with you :-) I'm CCing the FtpServer list on the discussion. When using the PROT P command in active mode, the FTP server will try to connect using SSL to the client. In this case the server acts as the SSL client. However, this seems to fail and we get a cleartext data connection. My feeling is that this is because the commons-net SSLContext does not set a keystore it can't act as a SSL server. However, I haven't tested patching FTPSClient yet so I'm not sure. If I run in passive mode (where the FTPSClient will act as a SSL client and FtpServer as a SSL server also for the data connection) everything seems to work as expected. You can find my simple test case here: http://svn.apache.org/repos/asf/incubator/ftpserver/ssl-tests/trunk/src/test/org/apache/ftpserver/ssl/DataConnectionTest.java Note that this tests differs from what Susanne described as I get a into problems on a single STOR. This might be because I have some basic misconfiguration, is so feel free to point me the right way :-) With some additional testing I was able to get everything to work. Not sure if it's the optimal solution but anyways, here's how I did it. The FTPSClient needs the have a SSL enabled ServerSocketFactory set, e.g.: client.setServerSocketFactory(SSLServerSocketFactory.getDefault()); Since we're now using the standard SSL socket implementation, it will look the the regular system properties for the key and trust stores. So I created a keystore for the client, containing a key pair for the client and I then imported the certificate for the server (exported from the server keystore). I then set the system properties and everything now seems to works as expected. The test case referred to above as been updated with these fixes. I should also say that I got this working within my Eclipse environment, not yet in the Maven build. Still not sure why but I'm looking into it. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLS for FTP
Susanne Lefvert wrote: With the help from Rory, I got the FTPSClient to work with the apache ftp server, thanks! I only ran into one issue: I'd like to also secure the data channel, so I used ftps.login(user, password) ftps.execPROT(P); It works fine the first time I upload a file to the server, however, the server hangs so that any other uploads I try after that fails and I have to restart the server. If I remove the execPROT(P) command, this issue does not occur. Any ideas??? Is Apache Ftp Server in this case the Java one in the Incubator (http://incubator.apache.org/ftpserver/)? If so, feel free enter a bug in our Jira and we'll be happy to have a look at it. https://issues.apache.org/jira/browse/FTPSERVER /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release [net] version 2.0
Rory Winston wrote: 1) Yes, there will be two separate branches of development. At the moment, the trunk is the 1.x branch, whereas there is a separate branch for JDK 5.0 dev. We can keep this the way it is, or swap the trunk and branch at some stage. Will you be backporting new features from the 2.x to the 1.x branch? I'm thinking of for example the FTPS support. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CODEC-52) Digest on InputStreams
Digest on InputStreams -- Key: CODEC-52 URL: http://issues.apache.org/jira/browse/CODEC-52 Project: Commons Codec Issue Type: Improvement Reporter: Niklas Gustavsson When calculating digests on large amount of data (for example large files) the current methods that takes a byte array or String in not sufficient. MessageDigest supports getting a digest for a stream. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-52) Digest on InputStreams
[ http://issues.apache.org/jira/browse/CODEC-52?page=all ] Niklas Gustavsson updated CODEC-52: --- Attachment: CODEC-52-patch.diff Attaching patch that implements this request Digest on InputStreams -- Key: CODEC-52 URL: http://issues.apache.org/jira/browse/CODEC-52 Project: Commons Codec Issue Type: Improvement Reporter: Niklas Gustavsson Attachments: CODEC-52-patch.diff When calculating digests on large amount of data (for example large files) the current methods that takes a byte array or String in not sufficient. MessageDigest supports getting a digest for a stream. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r377094 - in /jakarta/commons/sandbox/exec/trunk/src: main/java/org/apache/commons/exec/ main/java/org/apache/commons/exec/environment/ main/java/org/apache/commons/exec/la
Sorry, my bad. With a newborn around I've lost track of most of my life :-) I will try to put some time into this project ASAP. /niklas Brett Porter wrote: Sorry, lost track of this thread. Where did we get to here? - Brett Brett Porter wrote: StringBuffer is kind of like it, but don't take that too literally. Please reuse the code from plexus-utils if you can! It would make porting *much* easier. - Brett Niklas Gustavsson wrote: Let me rethink this a little bit. For now I'll revert the changes and work on a simpler CommandLine implementation, something in line with StringBuffer. Thanks for the feedback! :-) /niklas - 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]
Re: svn commit: r377094 - in /jakarta/commons/sandbox/exec/trunk/src: main/java/org/apache/commons/exec/ main/java/org/apache/commons/exec/environment/ main/java/org/apache/commons/exec/la
Sorry, my bad. With a newborn around I've lost track of most of my life :-) I will try to put some time into this project ASAP. /niklas Brett Porter wrote: Sorry, lost track of this thread. Where did we get to here? - Brett Brett Porter wrote: StringBuffer is kind of like it, but don't take that too literally. Please reuse the code from plexus-utils if you can! It would make porting *much* easier. - Brett Niklas Gustavsson wrote: Let me rethink this a little bit. For now I'll revert the changes and work on a simpler CommandLine implementation, something in line with StringBuffer. Thanks for the feedback! :-) /niklas - 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]
Re: svn commit: r377094 - in /jakarta/commons/sandbox/exec/trunk/src: main/java/org/apache/commons/exec/ main/java/org/apache/commons/exec/environment/ main/java/org/apache/commons/exec/launch
Let me rethink this a little bit. For now I'll revert the changes and work on a simpler CommandLine implementation, something in line with StringBuffer. Thanks for the feedback! :-) /niklas Brett Porter wrote: This sounds fine. I have to admit I still haven't gotten my head around the current state of things as much as I'd like. Will it still be possible to construct a command line in the way I've illustrated? If not, is it possible this class could take both types of arguments? - Brett Niklas Gustavsson wrote: I don't think your missing anything. The idea was to get closer in line to how the JDK does this. The quote handling would with this design be done within the implementation of the command runner (e.g. Execute), that's why the commit message said I was coming back to that. That default implementation would use the Ant code. However, if you do not think this is a good idea, I'll be happy to back it out. /niklas Brett Porter wrote: Maybe I'm missing something, but are you sure you want this? At least in plexus-utils, constructing a command line with cl.addArg().setLine(), cl.addArg.setValue(), etc is *much* friendlier than creating a string array. Also, the quote handling is one of the most key things to this library. Are you sure it will get back to the well tested state that Ant had this code in? It's really the only problem I have with the plexus-utils version of the library. - Brett [EMAIL PROTECTED] wrote: Author: ngn Date: Sat Feb 11 16:14:47 2006 New Revision: 377094 URL: http://svn.apache.org/viewcvs?rev=377094view=rev Log: Replacing the CommandLine class with String[] to work more like the JDK classes. Note that for now this also removes the special handling of quotes. Get back to this later. -- --- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r377094 - in /jakarta/commons/sandbox/exec/trunk/src: main/java/org/apache/commons/exec/ main/java/org/apache/commons/exec/environment/ main/java/org/apache/commons/exec/launcher/
I don't think your missing anything. The idea was to get closer in line to how the JDK does this. The quote handling would with this design be done within the implementation of the command runner (e.g. Execute), that's why the commit message said I was coming back to that. That default implementation would use the Ant code. However, if you do not think this is a good idea, I'll be happy to back it out. /niklas Brett Porter wrote: Maybe I'm missing something, but are you sure you want this? At least in plexus-utils, constructing a command line with cl.addArg().setLine(), cl.addArg.setValue(), etc is *much* friendlier than creating a string array. Also, the quote handling is one of the most key things to this library. Are you sure it will get back to the well tested state that Ant had this code in? It's really the only problem I have with the plexus-utils version of the library. - Brett [EMAIL PROTECTED] wrote: Author: ngn Date: Sat Feb 11 16:14:47 2006 New Revision: 377094 URL: http://svn.apache.org/viewcvs?rev=377094view=rev Log: Replacing the CommandLine class with String[] to work more like the JDK classes. Note that for now this also removes the special handling of quotes. Get back to this later. -- --- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] API sketch?
Brett Porter wrote: Niklas Gustavsson wrote: /* * StreamHandlers are used for providing input, * retriving the output. Also used for logging. */ StreamHandler getStreamHandler(); void setStreamHandler(StreamHandler streamHandler); My only comments on these is that I don't see the point of the setters in the interface - is it a requirement of the use of the library, or is it an implementation detail? (eg, I use plexus which instantiates objects implementations with private field injection, some use setters through reflection, some through a constructor - I'm not sure the interface requires it). As for the stream handler - what is the contents of that interface? Does it have an input, output and error stream? In this sketch, the StreamHandler provide the streams for in, out and err. There are some examples of StreamHandlers in the current code. In one way or another this functionality would be required in the API. You have commit access now, so if you want to start writing some example code (or create a fresh branch, even), you're welcome to. Yeah, I know. Just wanted to get some input here before getting going :-) /niklas --- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] API sketch?
Brett Porter wrote: Niklas Gustavsson wrote: /* * StreamHandlers are used for providing input, * retriving the output. Also used for logging. */ StreamHandler getStreamHandler(); void setStreamHandler(StreamHandler streamHandler); My only comments on these is that I don't see the point of the setters in the interface - is it a requirement of the use of the library, or is it an implementation detail? (eg, I use plexus which instantiates objects implementations with private field injection, some use setters through reflection, some through a constructor - I'm not sure the interface requires it). As for the stream handler - what is the contents of that interface? Does it have an input, output and error stream? In this sketch, the StreamHandler provide the streams for in, out and err. There are some examples of StreamHandlers in the current code. In one way or another this functionality would be required in the API. You have commit access now, so if you want to start writing some example code (or create a fresh branch, even), you're welcome to. Yeah, I know. Just wanted to get some input here before getting going :-) /niklas --- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] design goals, API sketch, etc.. next step?
jerome lacoste wrote: Niklas, Brett, Trygve all, So here's what I propose to do: - decide which requirements are important. What is the problem we are trying to solve? How do we position us compared to the official's API? etc... Someone using SDK 1.4 or 1.5 should find a compelling reason to migrate to commons-exec. The migration should be intuitive. Benefits for migrating clear. I think I exposed my ideas in the thread about the library's vision. Agreed, lets got through the requirements gathered so far (these are more of less copied from your's and Bretts email with some additions by myself). * Provide an equivalent to ProcessBuilder working in older JREs * Process and Stream management, allowing flexible reuse of this functionality * be able to run an external command in a small number of lines, capturing or streaming output and pass in my own input handler. Have it actually work on Windows and Unix et al when there are quotes, spaces, etc in the binary, arguments, etc. * be able to run a process in the background, find out when it finished, kill it if necessary. * wire it up in an IoC container so I can do even less code to configure it * Provide an API for retrieving the current environment Would you like anything else in there? I think those listed above are covered by the current code, albeit behind an ugly API. - we compare the clean API sketch to the refactoring I made in September. We focus on making this API easy to use and remember without compromise on flexibility. Agreed, I will check out your refactoring next. - we then take a decision on how to reach an implementation that satisfies this API (Either start from the API sketch, or from the refactorings I made 4 months ago). I don't care on the approach as long as we get things moving and that efforts are not wasted. Niklas you said you could coordinate. I offered my help for coding, documentation and tests. There's already a lot of work done on that. Who else is interested? How do we proceed? Niklas I let you answer those questions. Yeap, I'll try my best to coordinate the efforts. First of all, I would like us to agree on the initial requirements. From what I gather, I think our basic requirements are very similar so I don't expect this to be any problem. I will also have a look at the refactoring you've made and get back with comments on that tomorrow. Let's try not to loose the momentum. I just don't want my efforts to be wasted (so far they haven't been productive enough to my taste). Agreed. I would really like this library to be in early alpha by end of February. So I can get it off the list of things I said I would do. I think that is a reasonable goal. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] API sketch?
Hi jerome lacoste wrote: I had some changes in mind compared to my original design proposal, to make it simpler. So I am willing to help you design test this API/implementation and make sure it works with CruiseControl. Great! I don't want to duplicate efforts so I would prefer a coordinator on that. Should I take back my original proposal and clean it up? Should we start from scratch? I'll be happy to coordinate the efforts here. Did you have time to look at the quick draft I sent out last week in this thread? When it comes to designing the API I would be happy to start from scratch if that makes it any easier for the users of the library. I think we should strive for a simple API, in line with the XOM design principles [1]. I especially would like us to follow As simple as it can be and no simpler, There’s exactly one way to do it and Do not allow clients to do bad things. I don't think the current code fits with any of these so there is some work to be done. Whatever the proposal, I want to see code examples to see how it would work in practise. Agreed, what would be the requirements for use within CC? /niklas [1] http://www.xom.nu/designprinciples.xhtml --- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] API sketch?
Hi jerome lacoste wrote: I had some changes in mind compared to my original design proposal, to make it simpler. So I am willing to help you design test this API/implementation and make sure it works with CruiseControl. Great! I don't want to duplicate efforts so I would prefer a coordinator on that. Should I take back my original proposal and clean it up? Should we start from scratch? I'll be happy to coordinate the efforts here. Did you have time to look at the quick draft I sent out last week in this thread? When it comes to designing the API I would be happy to start from scratch if that makes it any easier for the users of the library. I think we should strive for a simple API, in line with the XOM design principles [1]. I especially would like us to follow As simple as it can be and no simpler, There’s exactly one way to do it and Do not allow clients to do bad things. I don't think the current code fits with any of these so there is some work to be done. Whatever the proposal, I want to see code examples to see how it would work in practise. Agreed, what would be the requirements for use within CC? /niklas [1] http://www.xom.nu/designprinciples.xhtml --- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] access for Niklas Gustavsson to the sandbox
Henri Yandell wrote: karma granted. Thanks :-) /niklas --- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] API sketch?
Hi Brett Porter wrote: Hi, Back in September 05 (wow, is it really 2006 already? :) Jerome sent a comprehensive vision for exec. I found myself agreeing with most everything in there (I'll reply to a couple of specifics shortly). Message ID from then: [EMAIL PROTECTED] However, it was long and wordy. I think the key part was that we should have a minimal exposed API. Maybe a good step forward is to sketch that API, then write implementations that reuse existing code, then refactor code behind the scenes later? With this, we could get something up and working *reasonably* quickly that is *reasonably* stable. Jerome, Niklas, Trygve - anyone interested in picking this up? In some ways the above email described it and this is just an interface sketch. I think getting a very clear and simple API working would be an excellent next step. Given such an API, we can refactor Execute and Exec to fit the API. Here's a quick stab at a first proposal for a new Execute class: /* * StreamHandlers are used for providing input, * retriving the output. Also used for logging. */ StreamHandler getStreamHandler(); void setStreamHandler(StreamHandler streamHandler); /* * Watchdog is used to kill of processes running, * typically, to long time. */ ExecuteWatchdog getWatchdog(); void setWatchdog(ExecuteWatchdog watchDog); File getWorkingDirectory(); void setWorkingDirectory(File dir); /* * Methods for starting synchronous execution. * Returns process exit value */ int execute(String[] command) throws ExecuteException; int execute(String[] command, Map environment) throws ExecuteException; /* * Methods for starting asynchronous execution. Result provided to callback handler */ void execute(String[] command, ExecuteResultHandler handler) throws ExecuteException; void execute(String[] command, Map environment, ExecuteResultHandler handler) throws ExecuteException; Besides this API, I think we should provide utility classes for retrieving the current Environment. I also think we should get rid of the current environment classes and use a Map instead. This simplifies working with our API and gets us inline with the Java 1.5 environment support. /niklas --- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transactions] No detection of failed deletion of file
Hi actually it would help with our original case (that was caused by incorrect file rights on a Unix box). However, the test case I wrote do not use access rights but instead just keeps the open for writes as I didn't want to fiddle with the access rights from the unit test :-) /niklas Oliver Zeigermann wrote: Might actually work for this special case, but I would not want to make the code more complicated unless really needed. As you say that it does not really help with your problem I would rather vote against introducing it. Thoughs? Oliver 2005/11/15, Niklas Gustavsson [EMAIL PROTECTED]: If that test (File.canWrite()) was executed during deleteResource() and if failing it would directly throw an Exception. That would mean that we get the exception before the commit. Now, this won't fix my test case as canWrite() doesn't detect write-locked files but I guess it could work for cases where you do not have the necessary file access. What do you think? /niklas Oliver Zeigermann wrote: Yes, I think so. But if you tried it would not fail before commit. Oliver 2005/11/13, Niklas Gustavsson [EMAIL PROTECTED]: Hi well, I'm not sure how to do this either. Could File.canWrite() be an indication? /niklas Oliver Zeigermann wrote: You are right. It would be desirable to make it fail as soon as possible. This would mean, however, that you touch the original file as soon as you try to delete it and not only when you commit the transaction. But the philosophy if this transactional implementation is not to touch the original file before commit. There are other implementations imaginable that make all the modifications on the original file but keep a backup for rollback, though. Thus, in short, the answer is that I do not know how to check this earlier given this implementation, but with others it would be possible. But, maybe, I am just not smart enough to find a solution ;) Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transactions] No detection of failed deletion of file
Hi actually it would help with our original case (that was caused by incorrect file rights on a Unix box). However, the test case I wrote do not use access rights but instead just keeps the open for writes as I didn't want to fiddle with the access rights from the unit test :-) /niklas Oliver Zeigermann wrote: Might actually work for this special case, but I would not want to make the code more complicated unless really needed. As you say that it does not really help with your problem I would rather vote against introducing it. Thoughs? Oliver 2005/11/15, Niklas Gustavsson [EMAIL PROTECTED]: If that test (File.canWrite()) was executed during deleteResource() and if failing it would directly throw an Exception. That would mean that we get the exception before the commit. Now, this won't fix my test case as canWrite() doesn't detect write-locked files but I guess it could work for cases where you do not have the necessary file access. What do you think? /niklas Oliver Zeigermann wrote: Yes, I think so. But if you tried it would not fail before commit. Oliver 2005/11/13, Niklas Gustavsson [EMAIL PROTECTED]: Hi well, I'm not sure how to do this either. Could File.canWrite() be an indication? /niklas Oliver Zeigermann wrote: You are right. It would be desirable to make it fail as soon as possible. This would mean, however, that you touch the original file as soon as you try to delete it and not only when you commit the transaction. But the philosophy if this transactional implementation is not to touch the original file before commit. There are other implementations imaginable that make all the modifications on the original file but keep a backup for rollback, though. Thus, in short, the answer is that I do not know how to check this earlier given this implementation, but with others it would be possible. But, maybe, I am just not smart enough to find a solution ;) Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transactions] Empty directories being deleted
Hi
when deleting a file, FileResourceManager will automatically delete any
empty directories up to the store root on comiit. This would in many
cases not be the expected behavior. Would it be okay to make this
optional? The following test case shows the behavior:
public void testDeleteOfEmptyDirs() throws Exception {
File storeDir = new File(test-store);
File subDir = new File(storeDir, 1/2/3);
File workDir = new File(test-work);
File testFile = new File(subDir, foo.txt);
subDir.mkdirs();
workDir.mkdirs();
testFile.createNewFile();
FileResourceManager rm = new FileResourceManager(
storeDir.getPath(),
workDir.getPath(),
false, new Log4jLogger(Logger.getLogger(logger)));
rm.start();
String txId = rm.generatedUniqueTxId();
rm.startTransaction(txId);
rm.deleteResource(txId, 1/2/3/foo.txt);
rm.commitTransaction(txId);
assertFalse(testFile.exists());
assertTrue(storeDir.exists());
assertTrue(subDir.exists());
assertTrue(workDir.exists());
}
/niklas
---
Niklas Gustavsson
http://www.protocol7.com
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transactions] No detection of failed deletion of file
If that test (File.canWrite()) was executed during deleteResource() and if failing it would directly throw an Exception. That would mean that we get the exception before the commit. Now, this won't fix my test case as canWrite() doesn't detect write-locked files but I guess it could work for cases where you do not have the necessary file access. What do you think? /niklas Oliver Zeigermann wrote: Yes, I think so. But if you tried it would not fail before commit. Oliver 2005/11/13, Niklas Gustavsson [EMAIL PROTECTED]: Hi well, I'm not sure how to do this either. Could File.canWrite() be an indication? /niklas Oliver Zeigermann wrote: You are right. It would be desirable to make it fail as soon as possible. This would mean, however, that you touch the original file as soon as you try to delete it and not only when you commit the transaction. But the philosophy if this transactional implementation is not to touch the original file before commit. There are other implementations imaginable that make all the modifications on the original file but keep a backup for rollback, though. Thus, in short, the answer is that I do not know how to check this earlier given this implementation, but with others it would be possible. But, maybe, I am just not smart enough to find a solution ;) Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transactions] No detection of failed deletion of file
Hi
well, I'm not sure how to do this either. Could File.canWrite() be an
indication?
/niklas
Oliver Zeigermann wrote:
You are right. It would be desirable to make it fail as soon as
possible. This would mean, however, that you touch the original file
as soon as you try to delete it and not only when you commit the
transaction. But the philosophy if this transactional implementation
is not to touch the original file before commit. There are other
implementations imaginable that make all the modifications on the
original file but keep a backup for rollback, though.
Thus, in short, the answer is that I do not know how to check this
earlier given this implementation, but with others it would be
possible.
But, maybe, I am just not smart enough to find a solution ;)
Oliver
2005/11/10, Niklas Gustavsson [EMAIL PROTECTED]:
Hi
thats the exact patch I did in our application as well.
After I sent the first email I've been thinking some more on this. I
would expect it to fail already during deleteResource(), not on
commit(). In our case we commit multiple sources and failing on a commit
means that we might be duplicating data. Would it be possible to change
deleteResource() so that it fails directly?
/niklas
Oliver Zeigermann wrote:
Hi Niklas!
This sounds like a bug. An exception and error condition should indeed
be the reasonable behavior. The test case looks suspicious, however.
Doesn't it manually insert something into the managed directories?
Anway, added a fix like this now:
if (!targetFile.delete()) {
throw new IOException(Could not delete
file + removeFile.getName()
+ in directory targetDir);
}
Hope you are satisfied with this?!
Cheers
Oliver
2005/11/10, Niklas Gustavsson [EMAIL PROTECTED]:
Hi
when using commons-transations we found an unexpected behavior when the
application did not have access rights to delete a file. This is not
detected by the FileResourceManager that happily reports the transaction
as successfully commited. The file still remains on the file system.
The following test case shows the same behavior, but for keeping a file
open:
public void testFailedDelete() throws Exception {
LoggerFacade logger = new Log4jLogger(Logger
.getLogger(FailDeleteTest.class));
String storeDir = test-store;
String workDir = test-work;
String testFile = foo.txt;
new File(storeDir).mkdirs();
new File(workDir).mkdirs();
FileResourceManager resMan = new FileResourceManager(storeDir,
workDir, false, logger);
resMan.start();
File file = new File(storeDir, testFile);
// hold on to the file
FileOutputStream fos = new FileOutputStream(file);
String txId = resMan.generatedUniqueTxId();
resMan.startTransaction(txId);
// no try to delete it
resMan.deleteResource(txId, testFile);
resMan.commitTransaction(txId);
// the file will remain even though we successfully
// commited the delete
assertTrue(file.exists());
}
I've tracked this down to the folliowing snippet in FileResourceManager:
if (removeFile.isFile()) {
if (targetFile.exists()) {
targetFile.delete();
}
// indicate, this has been done
removeFile.delete();
I think a check that targetFile.delete() actually succeeds would fix
this problem. I'll be happy to write up a patch if you agree that this
should be fixed.
/niklas
---
Niklas Gustavsson
http://www.protocol7.com
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
---
Niklas Gustavsson
http://www.protocol7.com
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
---
Niklas Gustavsson
http://www.protocol7.com
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[transactions] List files
Hi would it be possible to add a method for listing the files in a directory (the eqivilent of File.listFiles) that includes the changes made within the transaction? If you can give me some pointers I would be happy to help out if you want to. /niklas --- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transactions] No detection of failed deletion of file
Hi
thats the exact patch I did in our application as well.
After I sent the first email I've been thinking some more on this. I
would expect it to fail already during deleteResource(), not on
commit(). In our case we commit multiple sources and failing on a commit
means that we might be duplicating data. Would it be possible to change
deleteResource() so that it fails directly?
/niklas
Oliver Zeigermann wrote:
Hi Niklas!
This sounds like a bug. An exception and error condition should indeed
be the reasonable behavior. The test case looks suspicious, however.
Doesn't it manually insert something into the managed directories?
Anway, added a fix like this now:
if (!targetFile.delete()) {
throw new IOException(Could not delete
file + removeFile.getName()
+ in directory targetDir);
}
Hope you are satisfied with this?!
Cheers
Oliver
2005/11/10, Niklas Gustavsson [EMAIL PROTECTED]:
Hi
when using commons-transations we found an unexpected behavior when the
application did not have access rights to delete a file. This is not
detected by the FileResourceManager that happily reports the transaction
as successfully commited. The file still remains on the file system.
The following test case shows the same behavior, but for keeping a file
open:
public void testFailedDelete() throws Exception {
LoggerFacade logger = new Log4jLogger(Logger
.getLogger(FailDeleteTest.class));
String storeDir = test-store;
String workDir = test-work;
String testFile = foo.txt;
new File(storeDir).mkdirs();
new File(workDir).mkdirs();
FileResourceManager resMan = new FileResourceManager(storeDir,
workDir, false, logger);
resMan.start();
File file = new File(storeDir, testFile);
// hold on to the file
FileOutputStream fos = new FileOutputStream(file);
String txId = resMan.generatedUniqueTxId();
resMan.startTransaction(txId);
// no try to delete it
resMan.deleteResource(txId, testFile);
resMan.commitTransaction(txId);
// the file will remain even though we successfully
// commited the delete
assertTrue(file.exists());
}
I've tracked this down to the folliowing snippet in FileResourceManager:
if (removeFile.isFile()) {
if (targetFile.exists()) {
targetFile.delete();
}
// indicate, this has been done
removeFile.delete();
I think a check that targetFile.delete() actually succeeds would fix
this problem. I'll be happy to write up a patch if you agree that this
should be fixed.
/niklas
---
Niklas Gustavsson
http://www.protocol7.com
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
---
Niklas Gustavsson
http://www.protocol7.com
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] vision for the library
Hi Your mail was very insightful! I'm going to focus on a few points and will probably get back on other parts later. jerome lacoste wrote: [snip] There's a certain legacy in the current commons-exec and it shows a lot. The main issue is the following: commons-exec as today was written to solve a particular problem within ant and not as a reusable library. In particular, reusing it forces any client to reuse many classes that a client should not necessarily care about. In comparison ProcessBuilder (SDK 5.0) (which solves only a small subset of what commons-exec solves), is much cleaner in its approach. It relies much more on SDK classes: no need for a CommandLine class, no need for an Environment class, etc... Agreed. Like you, I think we can do a lot of work on getting exec into a cleaner state by refactoring the current code. [snip] Vision architecture: --- - Execute (or Executor?): Flexible, we use it to tie together the various concepts in the execute() call (stream management, process management, process building, etc...) - Exec (or ??) makes it easy to use Execute/or. I think we should aim for removing Exec and instead focus on getting the other classes, particulary Execute, easy enough to use without having a helper class like Exec. Detailed changes: - EnvironmentVariable. Too bad there's no real interface for key/value container in SDK (apart from Map.Entry whose definition makes me want to avoid using it outside of a Map). Otherwise I would have scrapped it... I think we can scrap it anyways. Environment. 1st remove Process Environment out. It's got nothing to do in there. Environment becomes mainly practical for clients who already use the EnvironmentVariable as for internal building of the ProcessEnvironment class. So let's make it a Map so that users don't need it to use the other classes. Also make it map key-value instead of key-(key, value) Agreed. ProcessEnvironment: We don't need a real class. What is the most needed is a getenv() call that builds an Environment (like System.getenv()). Could maybe just return a Map. But I don't see an issue with returning the Environment itself which maybe helps us. We see that as implementation goes. Agreed. Where would you like to put the method for retriving the current environment? [snip] We regard to my other patches, they can be discarded if we go for a rewrite (through refactorings). Trygve: in particular the serializable patch is not critical. Was just there to maintain the functionality of the old API, as I thought it as critical as that time I started looking at the project. Would it be possible to break your refactorings down into a set of patches that each fix on of the issues you outlined above? I don't mind this process taking several months as long as there's a good feedback from the potential users. I am not in a hurry to finish, just in a hurry to get started :) Again, agreed :-) /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[exec] Outstanding patches
Hi Is there a commiter out there with enough spare cycles to have a look at the outstanding patches for exec? I belive this list covers all active: http://shorl.org/fanivajuhiva /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
jerome lacoste wrote: 1. Full support for 1.1+ 2. Limited support for 1.1-1.2, full support for 1.3+ 3. No support for 1.1-1.2, full support 1.3+ go for 3 'oldest' I really meant not SDK 5.0 only. Great, no 3 seems to be the favorite. I'll remove the stuff needed for 1.1 support (like the script-based CommandLaunchers) and send a new patch. /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec][patch] commons-exec initial contrib
Hi I was was writing a reply to Noel's message but Brett beat me to it. Brett Porter wrote: What have I missed and how do we need to correct it? In the worst case, I can svn cp from Ant (as they are soon going to SVN), and stepwise refine it to include these improvements. Do we still need a CLA/grant from Niklas? Should a CLA/grant be needed, I would of course be happy to work that out. Would a CLA be needed for future patches or would attaching them to a Bugzilla entry be acceptable? /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec][patch] commons-exec initial contrib
Brett Porter wrote: Grey areas, but the larger the contributions that more important that we get a CLA. And, as you noted, the o.a.c.e.launcher package was created by him, and is not just a set of patches. Actually, I thought originally this was an original contribution, but on closer inspection I've found that it is also derived from another set of Ant classes. That's true. The only new code in my patch are the unit tests and the pom.xml. Everything else is more or less refactored Ant code. /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec][patch] commons-exec initial contrib
Noel J. Bergman wrote: Niklas Gustavsson wrote: Should a CLA/grant be needed, I would of course be happy to work that out. Would a CLA be needed for future patches or would attaching them to a Bugzilla entry be acceptable? If you are going to contribute on an on-going basis, as CLA would be best, yes. Happy to oblige :-) I'll sign the agreement (http://www.apache.org/licenses/icla.txt) and fax it to ASF. Should I also get the CCLA signed while I'm at it? Contributions I make to Apache projects are not part of my job, but I understand that the CCLA might be required anyway. /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[exec][patch] commons-exec initial contrib
Brett Porter wrote: * Would it be a good starting point (if so I'll create a patch for the code I've cleaned up and removed the Ant specifics from)? I think so. (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! /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com -- -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec][patch] commons-exec initial contrib
Brett Porter wrote: Niklas, I made a couple of small structural changes, fleshed out the POM, and added a front page on the site: http://jakarta.apache.org/commons/sandbox/exec/ Yeah, the POM was a bit... limited :-) Excellent, I'll sync up right away so that I can get going on the development. /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec][patch] commons-exec initial contrib
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. /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Hi Jerome Thanks for a lot of really good feedback and ideas! I will come back to some of the other stuff later on, but first I think we need to discuss on of the points you bring up: jerome lacoste wrote: * run on the oldest SDK possible I think there are three ways to go: 1. Full support for 1.1+ 2. Limited support for 1.1-1.2, full support for 1.3+ 3. No support for 1.1-1.2, full support 1.3+ Runtime.exec(String[] cmd, String[] env, File workingDir) was added in 1.3. A lot of the Ant trickery going on the the current code is to handle working directories on older (pre 1.3) JVMs. This include most of the CommandLaunchers and the shell/Perl scripts. The middle road would be to only support execution in the current directory only on 1.1. So, what do you all think? I'm personally lucky enough to mostly be on 1.3 and 1.4 these days, but I'm fine with either choice here. If you think we should aim for 1.1, I would prefer option 2 to ease our pains a little bit. If we make the CommandLaunchers pluggable (and I think we should), someone who would really need working directory support on 1.1 could potentially write their own CommandLauncher. /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Brett Porter wrote: * Would it be a good starting point (if so I'll create a patch for the code I've cleaned up and removed the Ant specifics from)? I think so. Cool, I'll get you a SVN patch tonight to get started. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Tomasz Pik wrote: * 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. I'm sure it works in Ant but I'm worry about using such solution in server-side applications where JVM (in therory) do not stop - just application is being redeployed over and over. I agree. Right now everything is tuned for Ant-type applications (quick runs). In the case of long-runnings JVMs a Watchdog is more appropriate. In the current code I got the ProcessDestroyer is not optional but I'll make a note of fixing that. Thanks! /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[exec] Design of commons-exec
Hi Lets start the discussions on the design of commons-exec. I'll start by describing the Ant implementation that I think is the most mature out there. I also think it contains the bits that would be approriate for this package. 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. There are additional classes but the list above are those of main interest. * Do you think this fits with what you would find appropriate and useful for commons-exec? * Would it be a good starting point (if so I'll create a patch for the code I've cleaned up and removed the Ant specifics from)? * Should I put this on the wiki for further discussions? /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Commons Exec
Some comments inline. Brett Porter wrote: Thanks for this Niklas, I'll get it kickstarted. I have some feedback: Niklas Gustavsson wrote: 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 would like to avoid the need for such scripts if possible, but it's definitely a thought. I agree, however, since Ant uses them it might be for a good reason so just to be sure I added this statement. One possibility for not having to distribute them would be to generate the scripts on he fly from Java but I think we can discuss and test this later on. Interaction with other packages This package will using Commons Logging for logging debug and error information. I'd prefer not. Both Ant and Maven have other ways to log information, so if it is to be incorporated back into them it might be an issue. In addition, this will need to be capturing and streaming sys.out and err which will need more functionality than c-l provides, so we need to have an output interface anyway. I'm perfectly fine with this. * Ant 2.X contains a new exec implementation, especially targeted for reusability (see http://ant.apache.org/ant2/actionlist.html#exec). Actually, I don't know if Ant2 exists - that page was a proposal from quite some time ago IIRC. I don't think so either (at least I haven't been able to find any code) but the exec refactoring is said to be 80% done. I'll check with Peter Donald if this code is available somewhere. Identify the initial set of committers to be listed in the Status File Brett Porter Stefan Bodewig As requested I'll add Trygve to this list too. He is an Apache committer. Niklas Gustavsson (I'm not currently an Apache commiter so I don't know if this is possible) The same rules apply as to other Apache projects - it is based on merit: http://www.apache.org/foundation/how-it-works.html#meritocracy http://www.apache.org/foundation/how-it-works.html#roles So, if you show continued commitment to contributing in regards to this and/or other commons components, that you are willing to work with others and to help people on the users mailing list, then it is possible you will be invited to move from being a contributor to a committer. Sounds good! Thanks again! I can set up the component in the sandbox - do you have some code to start it with already, or shall we start talking about where to start? While I got some code I would prefer to discuss the high-level requirements and design first. For example I would be very interested in Tryves ideas. /niklas Cheers, Brett -- - Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Commons Exec
Dion Gillard wrote: Is the scope going to include remotely executing processes via ssh or something similar? I would not think so but I'm very interested in others opinions. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Commons Exec
Kev Jackson wrote: 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. With accessing symlinks/NT junctions, do you mean in the general sense (like in JSR-203) or specific for execution of external processes? If the former, while an excellent idea (I sure would need it) IMHO it would fit better in Commons IO. If the later, could you please explain what would be needed? I'd be happy to help out with code contributions etc Great! /niklas - Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] using Maven2 for a new component?
+1 /niklas Brett Porter wrote: Hi, I wanted to get feedback on whether anyone has an issue with using Maven 2 as the primary build system for the commons-exec component. Conditions: - that I will setup the infrastructure that mimics the existing Maven behaviour for the site and common build - that it still generates an Ant build.xml file (which it should using the current plugin, I think). This will give folks a chance to see it in action and since it is only in the sandbox should not do any harm. Any objections? Cheers, Brett -- - Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Commons Exec
Dion Gillard wrote: My reason for asking, is that it's a common requirement to execute various commands either locally or on a remote box, preferably by just providing a host name and access method (e.g. ssh). It's very useful sometimes to abstract away the location of the executed commands. Ant has a concept of CommandLaunchers which implements different ways of executing commands based on the environment. For example, the WinNTCommandLauncher prepends on the cmd.exe /c before executing the command. Possibly, remote execution could supported in a similar way. However, with the current implementation there is no way of configuring the CommandLauncher (like providing the hostname or cipher spec). /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[proposal] Commons Exec
Proposal for Exec Package Rationale Executing external processes from Java is a well-known problem area. It is inheriently platform dependent and requires the developer to know and test for platform specific behaviors, for example using cmd.exe on Windows or limited buffer sizes causing deadlocks. The JRE support for this is very limited, albeit better with the new Java SE 1.5 ProcessBuilder class. Reliably executing external processes can also require knowledge of the environment variables before or after the command is executed. In J2SE 1.1-1.4 there is not support for this, since the method, System.getenv(), for retriving environment variables is deprecated. The are currently several different libraries that for their own purposes has implemented frameworks around Runtime.exec() to handle the various issue outlined above. The proposed project should aim at coordinating and learning from these initatives to create and maintain a simple, reusable and well-tested package. Since some of the more problematic platforms are not readily available, it is my hope that the broad Apache community can be a great help. 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. Interaction with other packages This package will using Commons Logging for logging debug and error information. Identify the initial source for the package Several implementations exists and should be researched before finalizing the design: * Ant 1.X contains probably the most mature code within the exec task. This code has been stripped of the Ant specifics and cleaned up by Niklas Gustavsson and can be donated under the ASF license. * Ant 2.X contains a new exec implementation, especially targeted for reusability (see http://ant.apache.org/ant2/actionlist.html#exec). * plexus-utils has a similar but slimmer implementation than Ant and has also indicated interest through Trygve Laugstøl the particate in the development. Identify the base name for the package org.apache.commons.exec Identify the coding conventions for this package Sun conventions. Identify any Jakarta-Commons resources to be created * Mailing list Until traffic justifies, the package will use the Jakarta-Commons lists for communications. * SVN repositories A new SVN directory under Commons Sandbox * Bugzilla The package should be listed as a component of under the Jakarta-Commons Bugzilla entry. * Integration test builds If possible, some form of integration test builds on various platforms (like the SourceForge compile farm) would be invaluable. I'm unsure of what for example Gump and the current Apache infrastructure has to offer in this area. Identify the initial set of committers to be listed in the Status File Brett Porter Stefan Bodewig Niklas Gustavsson (I'm not currently an Apache commiter so I don't know if this is possible) /niklas - Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] exec support in commons
Hi again, I never got any reply to the answers below so I'll try again :-) If you still exec support of interest, what would be the appropriate way to proceed to either: 1. donate the code to an existing Commons project (possibly as a biggish patch) 2. create a new project (exec) using the code as a starting point. 3. some other way I'm not a Apache commiter but would of course be happy to work by commiting patches. /niklas Niklas Gustavsson wrote: Stefan and Brett, great that you like the proposal! I'll read up on plexus-utils and will also take a look at Peters work with Ant2. Now, given that you are both busy and I'm not an Apache commiter, how do you propose we move forward on this? I'm aware of the process for contributing patches (as per http://jakarta.apache.org/site/source.html#Patches),would this be the best way for me to contribute my existing code and future updates? /niklas Stefan Bodewig wrote: On Wed, 08 Jun 2005, Niklas Gustavsson [EMAIL PROTECTED] wrote: I very much like the support for this in Ant and have extracted that code and removed all Ant specifics for some of my other projects. I would be happy to contribute and maintain this code should you be interested. +1 sounds like a good idea. I'm willing to help porting any improvements made to this code over to Ant and vice-versa. But like Brett I'm swamped at the moment, so don't expect any immediate help. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] exec support in commons
Excellent, thanks! I'll write up a proposal and sen it to the list. I'll also work on getting the code in shape for a donation (donation seems like an overstatement since it's merely cleaned up Ant code). /niklas Brett Porter wrote: Well, both our replies did say we were swamped :) At some point we will want this, so I will create an empty sandbox project. You might like to read http://jakarta.apache.org/commons/charter.html (you may already have) Basically to start we need to send an email to this list with a proposal, similar to what you've done already but with a bit more details: - name (commons-exec?) - rationale (this is really what you've already said, so include that) - scope (the goals we'd like to achieve: feature X, Y, incorporate functionality from Ant's exec and plexus-utils) That should be all. List Stefan (I'll dob him in since he seemed interested, he can always change his mind) and myself as initial committer. Next, we can discuss the design choices and goals here using an [exec] prefix on emails (or whatever is chosen). I'll be happy to import any code from your patches. Please let me know if you obtained it from another project such as Ant, plexus-utils or somewhere else as I'll need to be checking that. Thanks! - Brett Niklas Gustavsson wrote: Hi again, I never got any reply to the answers below so I'll try again :-) If you still exec support of interest, what would be the appropriate way to proceed to either: 1. donate the code to an existing Commons project (possibly as a biggish patch) 2. create a new project (exec) using the code as a starting point. 3. some other way I'm not a Apache commiter but would of course be happy to work by commiting patches. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP sends incorrect type for EBCDIC
Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Niklas Gustavsson writes: Fair enough, but if it is treated as binary, shouldn't the type be I? That's what I get for not doing my homework :) Okay, so I have no idea why it is sending B (other than it being a mistake). I'm not even sure why I thought the spec required ASCII/EBCDIC translation, since it says: For transmission, the data are represented as 8-bit EBCDIC characters. I'll change it to E whenever the source repository is accessible again. Great, thanks! /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP sends incorrect type for EBCDIC
Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Niklas Gustavsson writes: When issuing ftp.type(FTP.EBCDIC_FILE_TYPE), FTP will send TYPE B. This is not correct according to RFC 959 where the EBCDIC type is specified as E. I'm pretty sure sending B is intentional since we do not perform automatic translaton between EBCDIC and ASCII. Therefore, EBCDIC is treated as a binary file not subject to the automatic translation required by the FTP spec. It's probably not useful to make a change unless the character translation is implemented. However, I'm speaking purely from memory and not from revisiting the code and RFC. Fair enough, but if it is treated as binary, shouldn't the type be I? /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTP sends incorrect type for EBCDIC
Hi When issuing ftp.type(FTP.EBCDIC_FILE_TYPE), FTP will send TYPE B. This is not correct according to RFC 959 where the EBCDIC type is specified as E. The attached patch should resolve this issue. /niklas Index: C:/Zystems/workspaces/RAS/commons-net/src/java/org/apache/commons/net/ftp/FTP.java === --- C:/Zystems/workspaces/RAS/commons-net/src/java/org/apache/commons/net/ftp/FTP.java (revision 219066) +++ C:/Zystems/workspaces/RAS/commons-net/src/java/org/apache/commons/net/ftp/FTP.java (working copy) @@ -220,7 +220,7 @@ * with [EMAIL PROTECTED] #setControlEncoding setControlEncoding}. */ public static final String DEFAULT_CONTROL_ENCODING = ISO-8859-1; -private static final String __modes = ABILNTCFRPSBC; +private static final String __modes = AEILNTCFRPSBC; private StringBuffer __commandBuffer; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] exec support in commons
Stefan and Brett, great that you like the proposal! I'll read up on plexus-utils and will also take a look at Peters work with Ant2. Now, given that you are both busy and I'm not an Apache commiter, how do you propose we move forward on this? I'm aware of the process for contributing patches (as per http://jakarta.apache.org/site/source.html#Patches),would this be the best way for me to contribute my existing code and future updates? /niklas Stefan Bodewig wrote: On Wed, 08 Jun 2005, Niklas Gustavsson [EMAIL PROTECTED] wrote: I very much like the support for this in Ant and have extracted that code and removed all Ant specifics for some of my other projects. I would be happy to contribute and maintain this code should you be interested. +1 sounds like a good idea. I'm willing to help porting any improvements made to this code over to Ant and vice-versa. But like Brett I'm swamped at the moment, so don't expect any immediate help. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[proposal] exec support in commons
Hi all, I would like to propose for Commons to include support for executing processes (Runtime.exec() on steroids) in a simple way. I very much like the support for this in Ant and have extracted that code and removed all Ant specifics for some of my other projects. I would be happy to contribute and maintain this code should you be interested. What do you think? /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
