ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject Re: SSHSession design (was: Re: First-time contributor - advice needed)
Date Thu, 09 Aug 2007 19:21:33 GMT
On 8/9/07, <> wrote:
> Steve Loughran said:
> >2. I'd put the nested commands into a <sequence>, the way we did in
> ><macrodef>. This makes it clear it is sequential, and it leaves room to
> >add new things alongside <localtunnel>.

> I'd like to discuss further your suggestion of incorporating <sequence>
> (<sequential>, according to 1.7.0 doc??) into sshsession to hold the
> nested tasks.  Please explain further why this is prefereable.

Forward compatibility. Right now you allow:

<sshsession ...>
  <LocalTunnel ... />
  any tasks...

So someone somewhere use <foo/> in "any tasks...", and later on you
want to enhance <sshsession> with a new <foo/> element. That someone's
build would now break with your new enhanced version.

Contrast this with this model:

<sshsession ...>
  <LocalTunnel ... />
    any tasks...

Now you are free to add new elements directly under <sshsession>
without potentially breaking any builds.

Code-wise, composing a Sequential instance is better/simpler IMHO than
inheriting TaskContainer (or Sequential).

An alternative in line with your proposed extension is to move the
inheritance away from <sshsession> and into <localtunnel> and
<remotetunnel>, to allow:

<sshsession ...>
  <LocalTunnel ...>
    any tasks...
  <RemoteTunnel ...>
    any tasks...

Here as well, there's no possible conflict with a user script using an
element name you'd want to add to <sshsession> itself.

I hope this helps. --DD

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message