Hello ehowe,

Hmmm.... Why not just use the catalina-ant tasks to install the apps
remotely without mucking with tomcat's webapps directory?  I use the
following target to install my app:

<target name="install" depends="compile,manager.init"
            description="Install application to servlet container" >
        <install
            url="${manager.url}"
            username="${manager.username}"
            password="${manager.password}"
            config="${app.ccf}"
            path="${app.path}" />
</target>


I have a task which does a filter copy of sample.ccf.xml to ccf.xml
and fills in the values in the following tokens:

<Context path="@context.path@" docBase="@context.docbase@"
         debug="5" reloadable="true" crossContext="true">

    <Logger
        className="org.apache.catalina.logger.FileLogger"
        prefix="[EMAIL PROTECTED]@_servlet_log."
        suffix=".txt"
            timestamp="true" />

</Context>

So, no matter where the build for your app exists on the hard drive,
all you have to do is make sure you specify the following in the the
build.properties file (filled with my defaults):

catalina.home=C:/Progra~1/Apache~1/Jakarta/tomcat-4.1.12
manager.username=myusername
manager.password=mypassword

Then type:

ant install

done!

Jake


Wednesday, October 16, 2002, 2:20:12 PM, you wrote:

eec> Today I submitted a patch for CruiseControl that will allow you to use
eec> "context params" instead of "servlet params" to configure CruiseControl,
eec> thus allowing you to not have to muck with the WAR itself to configure it.
eec> It also makes running CC for multiple builds less cumbersome.  Hopefully the
eec> people at CruiseControl will accept the patch and incorporate it into the
eec> source.

eec> If you are using Tomcat 4.1, it is trivial to set up one or more contexts
eec> that all use a single CruiseControl WAR.  You would simply create xml files
eec> containing the context definition in the webapps directory for each build.
eec> The CC configuration would reside in the context definition, outside of the
eec> WAR.  See
eec> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html for more
eec> information regarding Tomcat contexts.

eec> For example, if you had just one project called "mybuild," you would create
eec> mybuild.xml in the Tomcat webapps directory that contains:

eec> <Context path="/mybuild" docBase="cruisecontrol" debug="0"
privileged="false">>
eec>   <Parameter name="logDir" value="/PATH/TO/LOG/FILES/"/>
eec>   <Parameter name="currentBuildStatusFile"
eec>     value="/PATH/TO/CURRENT/BUILD/STATUS/FILE/currentbuild.txt"/>
eec> </Context>

eec> This example assumes you've unpacked the CC WAR file in the webapps
eec> directory, in a subdirectory called "cruisecontrol".

eec> Ed Howe

eec> -----Original Message-----
eec> From: Erik Hatcher [mailto:[EMAIL PROTECTED]]
eec> Sent: Monday, October 14, 2002 3:05 AM
eec> To: Ant Users List
eec> Subject: Re: cruisecontrol vs anthill


eec> Wannheden, Knut wrote:
>> Erik,
>> 
>> 
>>>We use CruiseControl on my work project and its working well, 
>>>although 
>>>it is mildly painful to set up and get running.  I expect more from 
>>>CruiseControl though, given its Martin Fowler's company 
>>>people that are 
>>>developing it (are you listening Thoughtworks?! :) - having to tweak 
>>>configuration *inside* a WAR file is just not cool - make a better 
>>>interface, leverage the slickness of Anthill in this respect (sorry, 
>>>while I had a soap box I thought I'd use it :).
>>>
>> 
>> 
>> Are you using the newest version (2.0, released 25. September 2002) of
>> CruiseControl?  Just wondering since many of the things mentioned in your
>> chart seem to have changed with the new version, but I haven't had time to
>> try it.

eec> Yes, we're using CC 2.0 at work and nothing dramatic has changed that I 
eec> can tell.  The configuration file is now in XML format and we are using 
eec> the HTML formatted e-mail notification.  I'm sure there are other 
eec> improvements, but the configuration inside the WAR is still present (I 
eec> believe) and its still fiddly to get configured completely right.

eec> Its well worth having some type of continuous integration process 
eec> running though.  By all means automate your builds somehow, even if its 
eec> a cron job nightly running a shell script to checkout a fresh copy of 
eec> the code base, run Ant, and send an e-mail of the results.  :)

eec>         Erik



eec> --
eec> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
eec> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



-- 
Best regards,
 Jacob                            mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to