Pither.com

I ended up reading the Grails code to figure this out, so I thought it might be useful to record.

One of the projects that I recently upgraded to Grails 1.2 makes use of Groovy HTTP-Builder. If you just pull in HTTP-Builder you'll quickly find that it's dependencies break your grails project. So under 1.1.1 and using maven, I had this:

<dependency>
  <groupId>org.codehaus.groovy.modules.http-builder</groupId>
  <artifactId>http-builder</artifactId>
  <version>0.5.0-RC1</version>
  <exclusions>
    <exclusion>
      <groupId>org.codehaus.groovy</groupId>
      <artifactId>groovy</artifactId>
    </exclusion>
    <exclusion>
      <groupId>xml-apis</groupId>
      <artifactId>xml-apis</artifactId>
    </exclusion>
  </exclusions>
</dependency>

New in Grails 1.2 is dependency management via conf/BuildConfig.groovy. There are lots and lots of examples around for how to define dependencies, but significantly less on how to exclude dependencies of those dependencies. So here's mine:

dependencies {
    compile('org.codehaus.groovy.modules.http-builder:http-builder:0.5.0-RC1') {
        excludes 'groovy', 'xml-apis'
    }
}

The thing that caught me out was that there's no groupId specified on the excludes, only an artifactId.

Something else I noticed while reading the dependency code was that the dependency string matching is very limited. Only three parts (groupId:artifactId:version) can be matched. None of the other (ie type or classifier) maven parameters are supported.

Just imagine that you have a list (a long list) of names in a spreadsheet (no, it's not suitable for export and processing as a CSV) that are unhelpfully in the wrong format. In my case they looked like "FredBloggs" instead of "Fred, Bloggs".

If you happen to be using a decent, open spreadsheet this is easy to fix as there's a "Regular expressions" checkbox on the Find and Replace dialog.

However if you're stuck with a proprietary spreadsheet life is a little harder. Excel has VB hiding in there somewhere though, so it had to be possible. Thankfully the Internet knows all and someone else has already written the code. Just to make sure I don't loose it, I'm going to reproduce the bit I found useful here:

Option Explicit

Function ReReplace(ReplaceIn, _
    ReplaceWhat As String, ReplaceWith As String, Optional IgnoreCase As Boolean = False)

    Dim RE As Object
    Set RE = CreateObject("vbscript.regexp")
    RE.IgnoreCase = IgnoreCase
    RE.Pattern = ReplaceWhat
    RE.Global = True
    ReReplace = RE.Replace(ReplaceIn, ReplaceWith)
End Function

Once that had been added to my spreadsheet as a module, I could use something like this to do my conversion:

=ReReplace(A3, "^([A-Z][^A-Z]+)([A-Z])", "$1, $2")

Yes, groups and back references are all supported (as they are in the Open Office find and replace dialog)!

Having copied the new cell down a whole column I had my results. All that remained was a copy/paste of the values to overwrite the originals with the corrected formatting.

Following the recent release of Grails 1.2.0 I've attempted to upgrade a few of the projects I work on. Some of these attempts have gone better than others.

For one of the simpler ones I only hit two problems.

1. Combining Acegi with Enum's defined in the same source file as domain objects no longer works. The grails bug is here and thankfully the workaround is easy - just pull all the Enum's into their own files.

2. Due to some of the performance improvements that Grails 1.2 makes around it's handling of GSPs and Sitemesh, the addProperty() function no longer works correctly

Unfortunately the second problem was not so easy to work around. It does however have a fix committed to the 1.2.x branch of development code. So how do you get that then? Here's what I did:

$ git clone git://github.com/grails/grails.git grails
$ cd grails
$ git checkout origin/1.2.x

You'll get some warnings about not being on a branch, but assuming you just want to build it and not modify it, you can safely ignore them.

$ ant package

You'll obviously need ant and a suitable java compiler ready to go before running this last step.

After a couple of minutes you should have a dist/grails-1.2.1.SNAPSHOT.zip file which you can unzip/install in just the same way you would a download from the grails site.

Only thing left after that is to "grails upgrade" your project again to set it to the 1.2.1.SNAPSHOT version!

One (probably the only one I've found so far actually) of the benefits to getting up at 6am, is that when you later discover there's 5 inches of snow on the road outside and decide it's not very sensible to try driving in it, you have time to build a snowman instead...

Having observed a sample of two(!) I have reached the conclusion that girls really can multi-task... but that's not always a good thing.

When Edward was very small he would get hiccups a lot. Sophie got them slightly less often but still enough to have noticed a repeating, and different pattern between the two of them.

When Edward got hiccups you could easily cure them by getting him to have a drink. After a few mouthfuls he would be fully focused on the milk and have forgotten all about the hiccups, which would then cease quickly.

Sophie on the other hand seems perfectly capable of drinking a bottle of milk while maintaining hiccups all the way through!

So there you have it; curing hiccups requires dedication and focus (plus a good drink), which apparently boys can do better than girls! ;-)

I started out with a virtual machine image that was 10GB is size. Within this are two partitions - the first a few hundred MB for /boot and the rest is a LVM partition. The LVM then contains swap, root and /home. In this particular case I needed to make /home bigger, I actually needed an extra couple of GB but thought I may as well add 10GB for good measure. This post is just a record of the process/commands I used to do this, along with a few notes.

For this to work, you have to be working with a RAW format image file. For me, this is what I started with, but if you need to convert to RAW, this is how:

$ qemu-img convert -O raw old_image.qcow new_image.raw

If you haven't just converted your image file and hence don't have a spare copy as the original, I suggest you make a backup of your image before you continue!

$ cp old_image.raw new_image.raw

First off, you need to extend the image file itself, hopefully you're on a system that allows sparse files, so this wont actually take any extra space:

$ dd if=/dev/zero of=new_image.raw seek=20G obs=1 count=0

With obs=1 you can set the seek= to be your target image size. I started with 10GB and wanted to add another 10, so I've set seek=20G.

Next is extending the partition that contains LVM. In theory you can use fdisk directly on image files, but in this case it didn't work for me, so an easy solution was to attach the image to a loopback device:

$ sudo losetup /dev/loop0 new_image.raw

Next up is fdisk:

$ sudo fdisk /dev/loop0

Here you want to delete the existing partition and re-create a larger one in it's place. It's important that the new partition starts in exactly the same place as the old one. For me, this was nice and easy - just delete the second partition and create a new one using the defaults, then save and quit. My commands were (I included a couple of "p"s to verify where I started and finished):

p
d
2
n
p
2
<enter to accept default>
<enter to accept default>
p
w

We're done with fdisk, so now the loopback device can be cleared:

$ sudo losetup -d /dev/loop0

Now you want access to the partitions within the image file, so that you can get at LVM to resize it:

$ sudo kpartx -av new_image.raw

This should show each of the partitions within the image and which loopback device they've been mapped to. For me, the interesting one was the second partition which got assigned to /dev/mapper/loop0p2.

There are a couple of bits that need resizing in LVM, the first is the physical volume. The default action of pvresize is to resize to consume all available space, so all that's needed is:

$ sudo pvresize /dev/mapper/loop0p2

To resize the logical volume I looked up the number of extents that were now free and used this number in my lvresize command (the number after -l). If you don't already know the name/device of your LV, you'll also want to run lvdisplay to find it.

$ sudo vgdisplay
$ sudo lvresize -l +2559 /dev/virt-machine/home /dev/mapper/loop0p2

Nearly there now. The image file, partition and LVM are done. Just the actual file system left. For me this was ext3, so pretty simple to extent to the full LV, just need to fsck and resize:

$ sudo e2fsck -f /dev/virt-machine/home
$ sudo resize2fs /dev/virt-machine/home

That's it! Everything should be resized. The only thing left is to tidy up and get rid of the loopbacks you created early. First you have to deactivate the LVM volume group, then you can remove the loopback devices:

$ sudo vgchange -a n virt-machine
$ sudo kpartx -d new_image.raw

Now fire up the virtual and enjoy the extra space.

It doesn't seem like long ago that I made a similar post to this. In fact, I guess it wasn't really that long!

Anyway, this time it's Sophie's turn.

Sophie has been quite mobile for a while. She swivels on her stomach then rolls across the room and swivels again to reach her target! For the last couple of weeks she has been practising getting up on all fours and for the last few days has been staying up long enough to get some good rocking in and even the occasional "step" with her hands before her balance lets her down.

So probably only another week or two and Sophie will be off and crawling. Next she'll be pulling herself up (she's already trying to reach up to things) and then we'll really be in trouble!