You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Chun Ji <CJ...@pro-unlimited.com> on 2006/07/29 01:26:01 UTC
email a html file
I want to insert a html file in my email, not an attachment.
Does someone know how to do it in ant.
-CJ
-----Original Message-----
From: Jamie Jackson [mailto:myspamb8@gmail.com]
Sent: Friday, July 28, 2006 11:31 AM
To: Ant Users List
Subject: Re: Trying to do things the "Ant way"
Importance: Low
I've translated your pseudo-code into Ant (see bottom), and I see that it
does seem to remove the need for <antcall>. However, unless *I* have
misunderstood your reply, I think you've misunderstood what I intended the
"build-all" task to mean.
Each server in my case has one preferred transfer type; therefore, it
wouldn't make sense in my case to deploy to the same server via different
mechanisms, at least not consecutively.
Therefore, I think the *deploy-all tasks are spurious, but the rest is on
target, thanks!
Alternatively, it seems Andrew understood where I was going with the
"deploy-all" when he advised the following, so I think I've got the full
solution. :-D
<target name="deploy-all">
<ant antfile="mydeploymentscript.xml" inheritAll="false">
<property name="envname" value="stage" />
</ant>
<ant antfile="mydeploymentscript.xml" inheritAll="false">
<property name="envname" value="integ" />
</ant>
... etc
</target>
Here's Dominique's pseudo-code fleshed out, for posterity:
<?xml version="1.0"?>
<project name="cwig" default="deploy">
<description>Trying it without antcall.</description>
<property file="$environment}.properties" />
<taskdef name="svn" classname="org.tigris.subversion.svnant.SvnTask" />
<taskdef resource="net/sf/antcontrib/antcontrib.properties" />
<target name="deploy-nfs" if="deploy-type==nfs">
<echo>I'm doing the NFS deployment</echo>
</target>
<target name="deploy-ssh" if="deploy-type==ssh">
<echo>I'm doing the SSH deployment</echo>
</target>
<target name="deploy" depends="-check-deploy, deploy-nfs, deploy-ssh">
<echo>I'm pretty sure I don't do anything, and that only my
"depends"
are important.</echo>
</target>
<target name="deploy-all" depends="-deploy-all, deploy">
<echo>I think I, as a task make sense, since i wouldn't want
to transfer files to the exactly the same destination twice
(albeit via different mechanisms).</echo>
</target>
<target name="-check-deploy">
<echo>I'm about to figure out which transfer type to use</echo>
<condition property="deploy-type==nfs">
<equals arg1="${deploy-type}" arg2="nfs" />
</condition>
<condition property="deploy-type==ssh">
<equals arg1="${deploy-type}" arg2="ssh" />
</condition>
</target>
<target name="-deploy-all">
<echo>I don't think I make sense, for the same reasons as
"deploy-ant"'s</echo>
<property name="deploy-type==nfs" value="doesn't matter" />
<property name="deploy-type==ssh" value="doesn't matter" />
</target>
</project>
Thanks!,
Jamie
On 7/28/06, Dominique Devienne <dd...@gmail.com> wrote:
>
> BTW, in -deploy-all, I usually set these properties as
>
> <property name="deploy-type==A" value="doesn't matter" />
>
> To emphasis the fact that it's the properties existence that matters,
> not it's value (because that's what target's if/unless check). --DD
>
> On 7/28/06, Dominique Devienne <dd...@gmail.com> wrote:
> > You can do something like:
> >
> > target deploy-A if "deploy-type==A"
> > target deploy-B if "deploy-type==B"
> >
> > target deploy depends -check-deploy, deploy-A, deploy-B, etc...
> > target deploy-all depends -deploy-all, deploy
> >
> > target -check-deploy
> > condition ${deploy-type} equals "A" set property "deploy-type==A"
> > condition ${deploy-type} equals "B" set property "deploy-type==B"
> > etc...
> >
> > target -deploy-all
> > set property "deploy-type==A"
> > set property "deploy-type==B"
> > etc...
> >
> > This avoid's <antcall>, and follows Ant's canonical way to control
> > target execution using properties. --DD
> >
> > On 7/28/06, Andrew Goktepe <an...@gmail.com> wrote:
> > > There is a loss of performance when you use antcall in large,
> > > complex builds. It also makes target dependencies less clear. But it's
> the
> > > only way I know of to call a specific target based on a value obtained
> at
> > > runtime. In most other cases, it's much better to use the 'depends'
> > > attribute of 'target' with the exact target names.
> > >
> > > To achieve a deploy-all case, you could have a separate target
> (optimally in
> > > a separate script) that makes 'ant' calls into the main deployment
> script:
> > >
> > > <target name="deploy-all">
> > > <ant antfile="mydeploymentscript.xml" inheritAll="false">
> > > <property name="envname" value="stage" />
> > > </ant>
> > > <ant antfile="mydeploymentscript.xml" inheritAll="false">
> > > <property name="envname" value="integ" />
> > > </ant>
> > >
> > > ... etc
> > > </target>
> > >
> > > -Andrew
> > >
> > > On 7/28/06, Jamie Jackson <my...@gmail.com> wrote:
> > > >
> > > > Thanks for the quick response. I have a couple of follow-ups.
> > > >
> > > > I've gotten the impression from reading other posts that <antcall>
> is to
> > > > be
> > > > avoided, so I'm wondering about its use here.
> > > >
> > > > The other question I have is: How would I satisfy the deploy-all use
> case
> > > > while reusing as much of the script as practical?
> > > >
> > > > Thanks again,
> > > > Jamie
> > > >
> > > > On 7/28/06, Andrew Goktepe <an...@gmail.com> wrote:
> > > > >
> > > > > Oops. s/<properties file/<property file/
> > > > >
> > > > > On 7/28/06, Andrew Goktepe <an...@gmail.com> wrote:
> > > > > >
> > > > > > We use a separate properties file for each environment, and
> have
> > > > common
> > > > > > property names. Instead of integ.transfertype,
> stage.transfertype,
> > > > etc,
> > > > > I
> > > > > > would just have 'transfertype' and it would have different
> values in
> > > > the
> > > > > > different files. Then the Ant script has targets based on the
> possible
> > > > > > values of the property, and one generic parent target that calls
> them.
> > > > > >
> > > > > > Example:
> > > > > > <properties file="${envname}.properties" />
> > > > > > <target name="deploy">
> > > > > > <antcall target="deploy-${transfertype}" />
> > > > > > </target>
> > > > > > <target name="deploy-nfs"> ... </target>
> > > > > > <target name="deploy-ssh"> ... </target>
> > > > > >
> > > > > > envname determines which environment-specific properties file
> needs to
> > > > > be
> > > > > > read.
> > > > > >
> > > > > > This is a more scalable solution. Adding a new environment is as
> > > > simple
> > > > > as
> > > > > > creating a new properties file.
> > > > > >
> > > > > > This assumes the build has already occurred and you can make run
> the
> > > > > > deployment Ant script separately for each environment.
> > > > > >
> > > > > > -Andrew
> > > > > >
> > > > > > On 7/28/06, Jamie Jackson <my...@gmail.com> wrote:
> > > > > > >
> > > > > > > I'm having a problem trying to grok the "ant way" to do things
> (i.e
> > > > .,
> > > > > > > without conditionals). I just got started with Ant a couple
> days
> > > > ago,
> > > > > so
> > > > > > >
> > > > > > > take that into consideration.
> > > > > > >
> > > > > > > I'm trying to produce a well-factored script to handle code
> > > > deployment
> > > > > > > to
> > > > > > > remote servers.
> > > > > > >
> > > > > > > Tasks:
> > > > > > > * deploy-integ
> > > > > > > * deploy-stage
> > > > > > > * deploy-prod
> > > > > > > * deploy-all (all of the above)
> > > > > > >
> > > > > > > Here's the problem: Depending on the set of servers, some are
> > > > > available
> > > > > > > via
> > > > > > > SSH, others are available via NFS, and I'd like the script to
> be
> > > > > > > generalizable enough to specify the transfer type in the
> properties
> > > > > > > file,
> > > > > > > along with the (potentially) varying paths among servers.
> > > > > > >
> > > > > > > Here's a stab at the properties file:
> > > > > > > -----------------------------------
> > > > > > > svn.url=http://myhost/myrepos/myproj
> > > > > > >
> > > > > > > integ.transfertype=nfs
> > > > > > > stage.transfertype=ssh
> > > > > > > prod.transfertype=ssh
> > > > > > >
> > > > > > > # a nfs basepath would look like //webdev/websites
> > > > > > > # an ssh basepath would look like username@hostname
> :/path/to/docroot
> > > > > > > integ.basepath=//devserver/docroot
> > > > > > > stage.basepath=username@hostname :/path/to/docroot
> > > > > > > prod.basepath=username@hostname:/path/to/docroot
> > > > > > >
> > > > > > > integ.proj.wwwroot=childwelfare
> > > > > > > stage.proj.wwwroot=childwelfare
> > > > > > > prod.proj.wwwroot=childwelfare
> > > > > > > ---------------------------------
> > > > > > >
> > > > > > > Here are a couple of the salient tasks (see inline comments):
> > > > > > >
> > > > > > > <target name="deploy-integ">
> > > > > > > <deploy basepath="integ.basepath" proj.wwwroot="
> > > > > > > integ.proj.wwwroot"
> > > > > > > transfertype="integ.transfertype" />
> > > > > > > </target>
> > > > > > >
> > > > > > > <macrodef name="deploy">
> > > > > > > <attribute name="args" />
> > > > > > > <attribute name="basepath" />
> > > > > > > <attribute name="proj.wwwroot" />
> > > > > > > <attribute name="transfertype" />
> > > > > > > <!-- I'd like to do it the "right way, and avoid "if",
> but
> > > > > don't
> > > > > > > know how -->
> > > > > > > <!-- Not to mention that I can't even put the "if" in
> > > > macrodef,
> > > > > > > so
> > > > > > > it doesn't work anyway -->
> > > > > > > <if>
> > > > > > > <equals arg1="@{transfertype}" arg2="ssh" />
> > > > > > > <then>
> > > > > > > <property name="@{args}" value="-e ssh -Cacvz
> @{
> > > > > > > local.buildDir}/* @{basepath}/@{proj.wwwroot}" />
> > > > > > > </then>
> > > > > > > <else>
> > > > > > > <property name="@{args}" value="-av @{
> local.buildDir
> > > > }/
> > > > > > > @{basepath}/@{proj.wwwroot}/" />
> > > > > > > </else>
> > > > > > > </if>
> > > > > > > <echo message="rsync ${args}" />
> > > > > > > <exec executable="rsync">
> > > > > > > <arg line="${args}" />
> > > > > > > </exec>
> > > > > > > </macrodef>
> > > > > > >
> > > > > > > What's the right approach?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Jamie
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: email a html file
Posted by Petar Tahchiev <pa...@gmail.com>.
On 29/07/06, Chun Ji <CJ...@pro-unlimited.com> wrote:
>
> I want to insert a html file in my email, not an attachment.
> Does someone know how to do it in ant.
>
> -CJ
>
>
> -----Original Message-----
> From: Jamie Jackson [mailto:myspamb8@gmail.com]
> Sent: Friday, July 28, 2006 11:31 AM
> To: Ant Users List
> Subject: Re: Trying to do things the "Ant way"
> Importance: Low
>
>
> I've translated your pseudo-code into Ant (see bottom), and I see that it
> does seem to remove the need for <antcall>. However, unless *I* have
> misunderstood your reply, I think you've misunderstood what I intended the
> "build-all" task to mean.
>
> Each server in my case has one preferred transfer type; therefore, it
> wouldn't make sense in my case to deploy to the same server via different
> mechanisms, at least not consecutively.
>
> Therefore, I think the *deploy-all tasks are spurious, but the rest is on
> target, thanks!
>
> Alternatively, it seems Andrew understood where I was going with the
> "deploy-all" when he advised the following, so I think I've got the full
> solution. :-D
>
> <target name="deploy-all">
> <ant antfile="mydeploymentscript.xml" inheritAll="false">
> <property name="envname" value="stage" />
> </ant>
> <ant antfile="mydeploymentscript.xml" inheritAll="false">
> <property name="envname" value="integ" />
> </ant>
>
> ... etc
> </target>
>
> Here's Dominique's pseudo-code fleshed out, for posterity:
> <?xml version="1.0"?>
> <project name="cwig" default="deploy">
> <description>Trying it without antcall.</description>
> <property file="$environment}.properties" />
> <taskdef name="svn" classname="org.tigris.subversion.svnant.SvnTask" />
> <taskdef resource="net/sf/antcontrib/antcontrib.properties" />
>
> <target name="deploy-nfs" if="deploy-type==nfs">
> <echo>I'm doing the NFS deployment</echo>
> </target>
>
> <target name="deploy-ssh" if="deploy-type==ssh">
> <echo>I'm doing the SSH deployment</echo>
> </target>
>
> <target name="deploy" depends="-check-deploy, deploy-nfs, deploy-ssh">
> <echo>I'm pretty sure I don't do anything, and that only my
> "depends"
> are important.</echo>
> </target>
>
> <target name="deploy-all" depends="-deploy-all, deploy">
> <echo>I think I, as a task make sense, since i wouldn't want
> to transfer files to the exactly the same destination twice
> (albeit via different mechanisms).</echo>
> </target>
>
> <target name="-check-deploy">
> <echo>I'm about to figure out which transfer type to use</echo>
> <condition property="deploy-type==nfs">
> <equals arg1="${deploy-type}" arg2="nfs" />
> </condition>
>
> <condition property="deploy-type==ssh">
> <equals arg1="${deploy-type}" arg2="ssh" />
> </condition>
> </target>
>
> <target name="-deploy-all">
> <echo>I don't think I make sense, for the same reasons as
> "deploy-ant"'s</echo>
> <property name="deploy-type==nfs" value="doesn't matter" />
> <property name="deploy-type==ssh" value="doesn't matter" />
> </target>
>
> </project>
>
> Thanks!,
> Jamie
>
> On 7/28/06, Dominique Devienne <dd...@gmail.com> wrote:
> >
> > BTW, in -deploy-all, I usually set these properties as
> >
> > <property name="deploy-type==A" value="doesn't matter" />
> >
> > To emphasis the fact that it's the properties existence that matters,
> > not it's value (because that's what target's if/unless check). --DD
> >
> > On 7/28/06, Dominique Devienne <dd...@gmail.com> wrote:
> > > You can do something like:
> > >
> > > target deploy-A if "deploy-type==A"
> > > target deploy-B if "deploy-type==B"
> > >
> > > target deploy depends -check-deploy, deploy-A, deploy-B, etc...
> > > target deploy-all depends -deploy-all, deploy
> > >
> > > target -check-deploy
> > > condition ${deploy-type} equals "A" set property "deploy-type==A"
> > > condition ${deploy-type} equals "B" set property "deploy-type==B"
> > > etc...
> > >
> > > target -deploy-all
> > > set property "deploy-type==A"
> > > set property "deploy-type==B"
> > > etc...
> > >
> > > This avoid's <antcall>, and follows Ant's canonical way to control
> > > target execution using properties. --DD
> > >
> > > On 7/28/06, Andrew Goktepe <an...@gmail.com> wrote:
> > > > There is a loss of performance when you use antcall in large,
> > > > complex builds. It also makes target dependencies less clear. But it's
> > the
> > > > only way I know of to call a specific target based on a value obtained
> > at
> > > > runtime. In most other cases, it's much better to use the 'depends'
> > > > attribute of 'target' with the exact target names.
> > > >
> > > > To achieve a deploy-all case, you could have a separate target
> > (optimally in
> > > > a separate script) that makes 'ant' calls into the main deployment
> > script:
> > > >
> > > > <target name="deploy-all">
> > > > <ant antfile="mydeploymentscript.xml" inheritAll="false">
> > > > <property name="envname" value="stage" />
> > > > </ant>
> > > > <ant antfile="mydeploymentscript.xml" inheritAll="false">
> > > > <property name="envname" value="integ" />
> > > > </ant>
> > > >
> > > > ... etc
> > > > </target>
> > > >
> > > > -Andrew
> > > >
> > > > On 7/28/06, Jamie Jackson <my...@gmail.com> wrote:
> > > > >
> > > > > Thanks for the quick response. I have a couple of follow-ups.
> > > > >
> > > > > I've gotten the impression from reading other posts that <antcall>
> > is to
> > > > > be
> > > > > avoided, so I'm wondering about its use here.
> > > > >
> > > > > The other question I have is: How would I satisfy the deploy-all use
> > case
> > > > > while reusing as much of the script as practical?
> > > > >
> > > > > Thanks again,
> > > > > Jamie
> > > > >
> > > > > On 7/28/06, Andrew Goktepe <an...@gmail.com> wrote:
> > > > > >
> > > > > > Oops. s/<properties file/<property file/
> > > > > >
> > > > > > On 7/28/06, Andrew Goktepe <an...@gmail.com> wrote:
> > > > > > >
> > > > > > > We use a separate properties file for each environment, and
> > have
> > > > > common
> > > > > > > property names. Instead of integ.transfertype,
> > stage.transfertype,
> > > > > etc,
> > > > > > I
> > > > > > > would just have 'transfertype' and it would have different
> > values in
> > > > > the
> > > > > > > different files. Then the Ant script has targets based on the
> > possible
> > > > > > > values of the property, and one generic parent target that calls
> > them.
> > > > > > >
> > > > > > > Example:
> > > > > > > <properties file="${envname}.properties" />
> > > > > > > <target name="deploy">
> > > > > > > <antcall target="deploy-${transfertype}" />
> > > > > > > </target>
> > > > > > > <target name="deploy-nfs"> ... </target>
> > > > > > > <target name="deploy-ssh"> ... </target>
> > > > > > >
> > > > > > > envname determines which environment-specific properties file
> > needs to
> > > > > > be
> > > > > > > read.
> > > > > > >
> > > > > > > This is a more scalable solution. Adding a new environment is as
> > > > > simple
> > > > > > as
> > > > > > > creating a new properties file.
> > > > > > >
> > > > > > > This assumes the build has already occurred and you can make run
> > the
> > > > > > > deployment Ant script separately for each environment.
> > > > > > >
> > > > > > > -Andrew
> > > > > > >
> > > > > > > On 7/28/06, Jamie Jackson <my...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > I'm having a problem trying to grok the "ant way" to do things
> > (i.e
> > > > > .,
> > > > > > > > without conditionals). I just got started with Ant a couple
> > days
> > > > > ago,
> > > > > > so
> > > > > > > >
> > > > > > > > take that into consideration.
> > > > > > > >
> > > > > > > > I'm trying to produce a well-factored script to handle code
> > > > > deployment
> > > > > > > > to
> > > > > > > > remote servers.
> > > > > > > >
> > > > > > > > Tasks:
> > > > > > > > * deploy-integ
> > > > > > > > * deploy-stage
> > > > > > > > * deploy-prod
> > > > > > > > * deploy-all (all of the above)
> > > > > > > >
> > > > > > > > Here's the problem: Depending on the set of servers, some are
> > > > > > available
> > > > > > > > via
> > > > > > > > SSH, others are available via NFS, and I'd like the script to
> > be
> > > > > > > > generalizable enough to specify the transfer type in the
> > properties
> > > > > > > > file,
> > > > > > > > along with the (potentially) varying paths among servers.
> > > > > > > >
> > > > > > > > Here's a stab at the properties file:
> > > > > > > > -----------------------------------
> > > > > > > > svn.url=http://myhost/myrepos/myproj
> > > > > > > >
> > > > > > > > integ.transfertype=nfs
> > > > > > > > stage.transfertype=ssh
> > > > > > > > prod.transfertype=ssh
> > > > > > > >
> > > > > > > > # a nfs basepath would look like //webdev/websites
> > > > > > > > # an ssh basepath would look like username@hostname
> > :/path/to/docroot
> > > > > > > > integ.basepath=//devserver/docroot
> > > > > > > > stage.basepath=username@hostname :/path/to/docroot
> > > > > > > > prod.basepath=username@hostname:/path/to/docroot
> > > > > > > >
> > > > > > > > integ.proj.wwwroot=childwelfare
> > > > > > > > stage.proj.wwwroot=childwelfare
> > > > > > > > prod.proj.wwwroot=childwelfare
> > > > > > > > ---------------------------------
> > > > > > > >
> > > > > > > > Here are a couple of the salient tasks (see inline comments):
> > > > > > > >
> > > > > > > > <target name="deploy-integ">
> > > > > > > > <deploy basepath="integ.basepath" proj.wwwroot="
> > > > > > > > integ.proj.wwwroot"
> > > > > > > > transfertype="integ.transfertype" />
> > > > > > > > </target>
> > > > > > > >
> > > > > > > > <macrodef name="deploy">
> > > > > > > > <attribute name="args" />
> > > > > > > > <attribute name="basepath" />
> > > > > > > > <attribute name="proj.wwwroot" />
> > > > > > > > <attribute name="transfertype" />
> > > > > > > > <!-- I'd like to do it the "right way, and avoid "if",
> > but
> > > > > > don't
> > > > > > > > know how -->
> > > > > > > > <!-- Not to mention that I can't even put the "if" in
> > > > > macrodef,
> > > > > > > > so
> > > > > > > > it doesn't work anyway -->
> > > > > > > > <if>
> > > > > > > > <equals arg1="@{transfertype}" arg2="ssh" />
> > > > > > > > <then>
> > > > > > > > <property name="@{args}" value="-e ssh -Cacvz
> > @{
> > > > > > > > local.buildDir}/* @{basepath}/@{proj.wwwroot}" />
> > > > > > > > </then>
> > > > > > > > <else>
> > > > > > > > <property name="@{args}" value="-av @{
> > local.buildDir
> > > > > }/
> > > > > > > > @{basepath}/@{proj.wwwroot}/" />
> > > > > > > > </else>
> > > > > > > > </if>
> > > > > > > > <echo message="rsync ${args}" />
> > > > > > > > <exec executable="rsync">
> > > > > > > > <arg line="${args}" />
> > > > > > > > </exec>
> > > > > > > > </macrodef>
> > > > > > > >
> > > > > > > > What's the right approach?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Jamie
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> > For additional commands, e-mail: user-help@ant.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
The mail task has a 'message' nested element. It accepts a 'mime-type'
attribute. In your caes you should use the "text/html" mime-type.
--
Regards, Petar!
Karlovo, Bulgaria.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org