<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Piraguablog &#187; Uncategorized</title>
	<atom:link href="http://www.piragua.com/category/uncategorized/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.piragua.com</link>
	<description>Just another WordPress weblog</description>
	<lastBuildDate>Tue, 22 Jun 2010 22:03:49 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Building Grails Apps with SVN and Hudson and fighting with application.properties</title>
		<link>http://www.piragua.com/2010/01/27/building-grails-apps-with-svn-and-hudson-and-fighting-with-application-properties/</link>
		<comments>http://www.piragua.com/2010/01/27/building-grails-apps-with-svn-and-hudson-and-fighting-with-application-properties/#comments</comments>
		<pubDate>Wed, 27 Jan 2010 23:24:40 +0000</pubDate>
		<dc:creator>Mike</dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://www.piragua.com/?p=40</guid>
		<description><![CDATA[It&#8217;s incredibly easy to set up a Hudson project to build a Grails application with the available Grails plugin for Hudson.  Every once in a while, however, there&#8217;s a little problem that&#8217;s been nagging me &#8211; merge conflicts within that pesky little application.properties file.
There are several things that cause application.properties to get re-written by Grails, [...]]]></description>
			<content:encoded><![CDATA[<p>It&#8217;s <a href="http://today.java.net/pub/a/today/2009/06/23/Grails-and-Continuous-Integration.html" onclick="javascript:pageTracker._trackPageview('/outbound/article/today.java.net');">incredibly easy</a> to set up a <a href="http://hudson-ci.org/" onclick="javascript:pageTracker._trackPageview('/outbound/article/hudson-ci.org');">Hudson</a> project to build a Grails application with the available Grails plugin for Hudson.  Every once in a while, however, there&#8217;s a little problem that&#8217;s been nagging me &#8211; merge conflicts within that pesky little application.properties file.</p>
<p>There are several things that cause application.properties to get re-written by Grails, the most common of which for me is installing / uninstalling plugins.  Since this is a properties file, the order of the lines is unimportant (they&#8217;re just key value pairs, after all), until your build machine does an &#8217;svn up&#8217; and encounters all sorts of conflicts that can&#8217;t be resolved automagically.<img class="alignright size-medium wp-image-42" title="Option #1 - uncheck that use update box" src="http://www.piragua.com/wp-content/uploads/2010/01/hudsonUseUpdate1-300x205.png" alt="hudsonUseUpdate" width="300" height="205" /></p>
<p>There are two (well, OK, three) ways to workaround this:</p>
<ol>
<li>Tell hudson do to a clean checkout with each build.  To do this just make sure the &#8220;Use update&#8221; box is NOT checked under the subversion modules section of your build configuration.  This works well if your project is relatively small and you have a fast connection to your source code repository.</li>
<li>Revert the application.properties file before the build happens.</li>
<li>Stop using SVN.  Well, I don&#8217;t actually know if other SCMs handle this better, but it wouldn&#8217;t surprise me.  I certainly know of a few that handle it worse!</li>
</ol>
<p>For the most part I&#8217;ve been using option #1 &#8211; until I recently added a very large project to the Hudson build&#8230;  The build time more than doubled &#8211; and that&#8217;s just unacceptable.</p>
<p>Enter Option #2.  In your build configuration, add an &#8220;Execute Shell&#8221; Build Step that happens BEFORE your Grails build that reverts the file so that the workspace always has the latest and greatest &#8211; without conflicts.</p>
<p style="text-align: center;"><img class="aligncenter size-full  wp-image-45" title="buildStep" src="http://www.piragua.com/wp-content/uploads/2010/01/buildStep1.png" alt="buildStep" width="415" height="218" /></p>
<p>Note that depending on how your checkout works, you may need to add the checkout path in front of application.properties, for example:</p>
<blockquote><p>svn revert yourGrailsApp/application.properties</p></blockquote>
<p>If there&#8217;s a better way, I&#8217;d love to hear it.  In the mean time, this extra little build step works great!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.piragua.com/2010/01/27/building-grails-apps-with-svn-and-hudson-and-fighting-with-application-properties/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Announcing WhenWorksForYou.com</title>
		<link>http://www.piragua.com/2009/07/05/announcing-whenworksforyoucom/</link>
		<comments>http://www.piragua.com/2009/07/05/announcing-whenworksforyoucom/#comments</comments>
		<pubDate>Mon, 06 Jul 2009 03:06:35 +0000</pubDate>
		<dc:creator>Mike</dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://www.piragua.com/?p=36</guid>
		<description><![CDATA[WhenWorksForYou.com allows you to ask your friends exactly that question: &#8220;When works for you?&#8221;   You can easily create an event and enter a few dates that work for you. Then invite your friends to visit the site and let you know which of those options work best for them. Once you have feedback [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://WhenWorksForYou.com" onclick="javascript:pageTracker._trackPageview('/outbound/article/WhenWorksForYou.com');">WhenWorksForYou.com</a> allows you to ask your friends exactly that question: &#8220;When works for you?&#8221;   You can easily create an event and enter a few dates that work for you. Then invite your friends to visit the site and let you know which of those options work best for them. Once you have feedback from your potential guests, you can make a decision on the best date and time to schedule the actual event.  </p>
<p>Check it out and give it a try!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.piragua.com/2009/07/05/announcing-whenworksforyoucom/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Grails Code Coverage Plugin 1.1.4 Released!</title>
		<link>http://www.piragua.com/2009/03/05/code-coverage-upgrade/</link>
		<comments>http://www.piragua.com/2009/03/05/code-coverage-upgrade/#comments</comments>
		<pubDate>Fri, 06 Mar 2009 03:54:28 +0000</pubDate>
		<dc:creator>Mike</dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://www.piragua.com/?p=34</guid>
		<description><![CDATA[The Grails Code Coverage plugin has been upgraded to work with Grails 1.1 RC2.  Please give it a shot and create JIRA issues (http://jira.codehaus.org/browse/GRAILSPLUGINS/component/13147) if you encounter any problems.

This release of the plugin removes the test-app-cobertura script and utilizes changes in Grails 1.1 RC2 to hook into the test-app script instead.  In order to run [...]]]></description>
			<content:encoded><![CDATA[<p>The Grails Code Coverage plugin has been upgraded to work with Grails 1.1 RC2.  Please give it a shot and create JIRA issues (<a href="http://jira.codehaus.org/browse/GRAILSPLUGINS/component/13147" onclick="javascript:pageTracker._trackPageview('/outbound/article/jira.codehaus.org');" target="_blank">http://jira.codehaus.org/browse/GRAILSPLUGINS/component/13147</a>) if you encounter any problems.</p>
<div></div>
<div>This release of the plugin removes the test-app-cobertura script and utilizes changes in Grails 1.1 RC2 to hook into the test-app script instead.  In order to run coverage, simply install the plugin (grails install-plugin code-coverage) and run &#8220;grails test-app&#8221;.  There are several other changes in this release as well:</div>
<div>
<ul>
<li>Upgraded Cobertura to 1.9</li>
<li>Ability to override the default exclusions list</li>
<li>Ability to bypass coverage instrumentation and report generation with the -nocoverage flag (e.g. grails test-app -nocoverage)</li>
</ul>
<div>Full docs available on the Grails.org wiki:  <a href="http://www.grails.org/Test+Code+Coverage+Plugin" onclick="javascript:pageTracker._trackPageview('/outbound/article/www.grails.org');" target="_blank">http://www.grails.org/Test+Code+Coverage+Plugin</a></div>
</div>
]]></content:encoded>
			<wfw:commentRss>http://www.piragua.com/2009/03/05/code-coverage-upgrade/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
