You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niklas Gustavsson <ni...@protocol7.com> on 2005/08/01 13:15:04 UTC
[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
niklas@protocol7.com
http://www.protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] Design of commons-exec
Posted by Eric Pugh <ep...@upstate.com>.
Jerome Lacoste wrote a proposal a couple months ago to the
CruiseControl mailing list talking about the same basic idea. His
proposal is here: http://www.coffeebreaks.org/blogs/?p=8. I will
forward this thread to him as he might be very interested in
contributing.
At any rate, something like this in Jakarta Commons would be great, I
know I am using at least three different implementations of the same
basic functionality!
Eric Pugh
On Aug 1, 2005, at 7:04 PM, Kev Jackson wrote:
>
>
>>
>> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] Design of commons-exec
Posted by Kev Jackson <ke...@it.fts-vn.com>.
>
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] Design of commons-exec
Posted by Jason van Zyl <ja...@maven.org>.
On Tue, 2005-08-02 at 16:18 +0200, Niklas Gustavsson wrote:
> 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.
The folks developing Continuum would certainly like to help work on
something that is usable in a server environment. We use some command
line utilities to call various build tools and we'd love to be able to
use the tool developed here instead of maintaining our own (which we
borrowed from CruiseControl -- some other people that might want to help
contribute to this cause).
> Thanks!
>
> /niklas
>
> ------------------
> Niklas Gustavsson
> niklas@protocol7.com
> http://www.protocol7.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
Three people can keep a secret provided two of them are dead.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] Design of commons-exec
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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
niklas@protocol7.com
http://www.protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] Design of commons-exec
Posted by Tomasz Pik <to...@gmail.com>.
On 01/08/05, Niklas Gustavsson <ni...@protocol7.com> wrote:
...
> This is a very short description of the cleaned up Ant exec task design:
...
> * 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.
Regards,
Tomek
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Brett Porter <br...@apache.org>.
Thanks! I'll add it to the sandbox shortly and see if there is anything
I can do.
- Brett
Niklas Gustavsson wrote:
> 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
> niklas@protocol7.com
> http://www.protocol7.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Kev Jackson <ke...@it.fts-vn.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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
niklas@protocol7.com
http://www.protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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
niklas@protocol7.com
http://www.protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Brett Porter <br...@apache.org>.
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)
>
I've autogenerated the Ant build script for you. You'll need m2 to do
the site at this point.
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/
Pushed up build #1:
http://cvs.apache.org/repository/org.apache.commons/jars/
Ok, I'll take a closer look and provide more feedback.
Thanks!
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Kev Jackson <ke...@it.fts-vn.com>.
>
>
> (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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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
niklas@protocol7.com
http://www.protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Brett Porter <br...@apache.org>.
I can confirm that Niklas' CLA has been received and recorded by the ASF.
Cheers,
Brett
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. Otherwise, a Software Grant would cover substantial contributions.
>The route of attaching patches to bugzilla/mailing list/JIRA is best for
>small patches to existing code, not substantial changes or entire new
>packages.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [exec][patch] commons-exec initial contrib
Posted by "Noel J. Bergman" <no...@devtech.com>.
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. Otherwise, a Software Grant would cover substantial contributions.
The route of attaching patches to bugzilla/mailing list/JIRA is best for
small patches to existing code, not substantial changes or entire new
packages.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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
niklas@protocol7.com
http://www.protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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
niklas@protocol7.com
http://www.protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Brett Porter <br...@apache.org>.
Noel J. Bergman wrote:
>Brett Porter wrote:
>
>
>>"A copy of several classes from the Apache Ant codebase, restructured
>>into a reusable library without dependence on Ant itself."
>>
>>
>
>Sounds fine. Now that we know the history, even the original commit comment
>makes sense, but when you put the original against the e-mail archives
>(which talk about "initial contribution") and you don't know the history, it
>isn't as clear as your revision.
>
>
>
Done (yay SVN - would have required an admin in CVS).
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [exec][patch] commons-exec initial contrib
Posted by "Noel J. Bergman" <no...@devtech.com>.
Brett Porter wrote:
> "A copy of several classes from the Apache Ant codebase, restructured
> into a reusable library without dependence on Ant itself."
Sounds fine. Now that we know the history, even the original commit comment
makes sense, but when you put the original against the e-mail archives
(which talk about "initial contribution") and you don't know the history, it
isn't as clear as your revision.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Brett Porter <br...@apache.org>.
Noel J. Bergman wrote:
>>Ok, do I need to edit the commit message?
>>
>>
>
>If you don't mind, yes thanks.
>
>
Ok, I could use some guidance on this. The original message was:
r230452 | brett | 2005-08-05 22:21:46 +1000 (Fri, 05 Aug 2005) | 3 lines
Submitted by: Niklas Gustavsson
initial import of refactored code from the Ant Exec tasks.
------------------------------------------------------------------------
What areas did you find this deficient that I can improve it?
How about:
"A copy of several classes from the Apache Ant codebase, restructured
into a reusable library without dependence on Ant itself."
>
>>Is a CLA from Niklas (and CCLA if necessary) plus modification
>>of the original commit message to indicate origin sufficient?
>>
>>
>
>Seems so. From what you seem to have tracked down, everything is turning
>out to be really patches to a variety of Ant packages.
>
>
Thanks, I'll follow up on this, and post to Jakarta PMC when it is
received in iclas.txt.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [exec][patch] commons-exec initial contrib
Posted by "Noel J. Bergman" <no...@devtech.com>.
Brett Porter wrote:
> Noel J. Bergman wrote:
> > I re-read the commit messages, and no it was not entirely
> > clear, at least not in terms of the clarity I'd want for
> > IP clearance. The concern is tracking provenance.
> Ok, do I need to edit the commit message?
If you don't mind, yes thanks.
> Is [re-doing everything starting with svn cp] necessary
> if Niklas has a CLA on file?
Probably not worth it. Just make the comments clear. :-)
> > 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.
:-) See, this is why we really want to make provenance clear.
> Is a CLA from Niklas (and CCLA if necessary) plus modification
> of the original commit message to indicate origin sufficient?
Seems so. From what you seem to have tracked down, everything is turning
out to be really patches to a variety of Ant packages.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Brett Porter <br...@apache.org>.
Noel J. Bergman wrote:
>I re-read the commit messages, and no it was not entirely clear, at least
>not in terms of the clarity I'd want for IP clearance. The concern is
>tracking provenance.
>
>
Ok, do I need to edit the commit message?
>Ant is in Subversion. If these are patched versions of Ant code, why didn't
>you use `svn cp` to initially populate the tree, with appropriate comments,
>then apply the patches?
>
>
Only some new components are in there, but according to their dev list
they have voted on moving the main repository (that includes this code)
in the next couple of weeks.
Is this necessary if Niklas has a CLA on file?
>
>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.
So, the question now is what is necessary to clear this up? Is a CLA
from Niklas (and CCLA if necessary) plus modification of the original
commit message to indicate origin sufficient? On reading the IP
clearance document, it appears so.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [exec][patch] commons-exec initial contrib
Posted by "Noel J. Bergman" <no...@devtech.com>.
Brett Porter wrote:
> The "contribution" comes almost entirely from the Ant codebase. Sorry if
> I didn't make that clear from the commit message.
I re-read the commit messages, and no it was not entirely clear, at least
not in terms of the clarity I'd want for IP clearance. The concern is
tracking provenance.
Ant is in Subversion. If these are patched versions of Ant code, why didn't
you use `svn cp` to initially populate the tree, with appropriate comments,
then apply the patches?
> Niklas is not a yet a committer, so doesn't have a CLA. I was under the
> impression his contribution was goverened by the same rules as any patch
> submitted to the mailing list.
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.
> I was also under the impression that the sandbox was equipped to house
> code in the same way as the incubator as official releases are not made
> from there.
Absolutely not. The sandbox is not a substitute incubator.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec][patch] commons-exec initial contrib
Posted by Brett Porter <br...@apache.org>.
The "contribution" comes almost entirely from the Ant codebase. Sorry if
I didn't make that clear from the commit message.
The exceptions:
- changed structure (merged classes such as ExecTask and Exec,
refactored out environment).
- addition of the o.a.c.e.launcher package which was created by Niklas.
I gave it a once over before committing it.
Niklas is not a yet a committer, so doesn't have a CLA. I was under the
impression his contribution was goverened by the same rules as any patch
submitted to the mailing list. I have asked that he use bugzilla in future.
I was also under the impression that the sandbox was equipped to house
code in the same way as the incubator as official releases are not made
from there.
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?
- Brett
Noel J. Bergman wrote:
>Re: http://svn.apache.org/repos/asf/jakarta/commons/sandbox/exec/trunk/
>
>Whoa, hello!
>
>This thing is labeled as an initial contribution, and the SVN tree was just
>created for it in July. It doesn't matter if it is a sandbox project or
>not. New codebases *MUST* be imported through the Incubator, at least in
>terms of recording the IP clearance.
>
>Where is the CLA for Niklas Gustavsson? Where is the Software Grant for the
>codebase? What are the origins of this codebase, since that isn't clear
>from the e-mail archives.
>
>Please explain what I am missing or correct this situation immediately.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [exec][patch] commons-exec initial contrib
Posted by "Noel J. Bergman" <no...@devtech.com>.
Re: http://svn.apache.org/repos/asf/jakarta/commons/sandbox/exec/trunk/
Whoa, hello!
This thing is labeled as an initial contribution, and the SVN tree was just
created for it in July. It doesn't matter if it is a sandbox project or
not. New codebases *MUST* be imported through the Incubator, at least in
terms of recording the IP clearance.
Where is the CLA for Niklas Gustavsson? Where is the Software Grant for the
codebase? What are the origins of this codebase, since that isn't clear
from the e-mail archives.
Please explain what I am missing or correct this situation immediately.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[exec][patch] commons-exec initial contrib
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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
niklas@protocol7.com
http://www.protocol7.com
--
------------------
Niklas Gustavsson
niklas@protocol7.com
http://www.protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] Design of commons-exec
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] Design of commons-exec
Posted by Brett Porter <br...@apache.org>.
Hi Niklas,
> * Do you think this fits with what you would find appropriate and
> useful for commons-exec?
This sounds pretty good to me. Thanks for jumping o nthis, I was about
to start one today when I saw your mail.
One thing I'd like to see is the interfaces for CommandLauncher,
CommandLine and Execute
> * 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.
> * Should I put this on the wiki for further discussions?
I'm fine with keeping it on the ML, or using the wiki - either way.
Probably not subscribed to the right pages so let me know if you do
create something there.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org