Menu
▾
▴
#4 ideas for continuing the refactoring of ant tasks
Some suggestions to continue the refactoring of the
SSH Ant tasks would include the following.
I know the refactoring is just a matter of having lots of
things on the go at once, but these would be my
preferred features after making heavy use of these tasks
(about 1000 lines in my build.xml are concerned with
using these tasks for various deployment activities)
1. Allowing <sftp> to be a child of <ssh>
A typical pattern of use for deployment would be to
upload and EAR file, and then invoke a script against it
to deploy it. Having seperate <ssh> and <sftp> base
tasks does not cause any functional problems, but it
means that I need to make two seperate connections to
the server to accomplish this, instead of using the one
channnel.
2. Creating an "exec" sub task of the current <sftp> task
On similar lines, a typical deployment for me involves
uploading an EAR part, a seperate JAR part (for another
related product on the server), and a JAR bundle
containing scripts that I will use to install the EAR file.
These are all located in different parts of my distribution
tree, and will end up in different parts of the target
environment. The current arrangement requires that
there are three seperate uses of <sftp>. It would be
easier if <sftp> (or <ssh>) contained the action
information, and a nested <exec> tasks contained the
action i.e.
<sftp ....>
<exec action="put" remotedir="/product1/ear">
<includes dir="/product1/dist" includes"blah.ear">
</exec>
<exec action="put" remotedir="/product1/scripts">
<includes dir="/product1/dist" includes"blah.jar">
</exec>
<exec action="put" remotedir="/product2/dist">
<includes dir="/product2/dist" includes"blah.jar">
</exec>
</sftp>
3. Adding an "echo" property to the <read> sub-task
The <shell> subtask has been incredibly useful to
overcome some really wierd hangs I was getting with F-
Secure, and makes it a lot easier to see what is going
on. I previously was invoking exec with massively long
composite commands i.e. <exec cmd="command1;
command2; command3; command4 .... "/> that made it
really hard to work out where something was breaking.
A quick win for this would be to add an echo attribute to
the <read> task. If echo was set to false, the use of
the "read" subtask would not dump out the contents of
the input stream buffer when it found a match. The
immediate win for me would be that I could avoid
showing the greeting message associate with the login
profile I'm using. Unfortunately I do not have the power
to make sweeping changes to the user profile, so the
only way I can stop a huge message appearing in my
Ant output is be not echoing it.
Thanks, a lot
M.
Logged In: YES
user_id=600074
I think all these requests have been addressed?