The short story of the workaround it is to disable the advanced attachment features in Gmail.

You can look at the blog post to find out when the problem occur, why it does and why the workaround helps:

[1] http://db.tidbits.com/article/11495

This was the result that I got:

$ sudo port upgrade groovy
--->  Building groovy
...
Command output:     [javac] Compiling 699 source files to /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_groovy/work/groovy-1.6.2/target/classes
    [javac]
    [javac]
    [javac] The system is out of resources.
    [javac] Consult the following stack trace for details.
    [javac] java.lang.OutOfMemoryError: Java heap space
    ...
    [javac] 	at com.sun.tools.javac.Main.main(Main.java:54)

BUILD FAILED
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_groovy/work/groovy-1.6.2/build.xml:173: Compile failed; see the compiler error output for details.

Looking in the directory mentioned above, we find a build.properties file that contains some settings:

$ cat /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_groovy/work/groovy-1.6.2/build.properties
...
groovycMain_mx = 512m
groovycTest_mx = 1G
groovycExamples_mx = ${groovycMain_mx}

javaDoc_mx = 512m
groovyDoc_mx = 640m

OK, plenty of memory, but nothing seems related to javac compilation. Let's check the line 173, that the error message mentioned:

sudo vi +173 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_groovy/work/groovy-1.6.2/build.xml

The javac call there does not contain any memory setting, so we must assume that it uses the default heap size:

<javac srcdir="${mainSourceDirectory}" includeantruntime="false" destdir="${mainClassesDirectory}"
       deprecation="on" debug="yes" source="1.5" target="1.5" fork="true" classpathref="compilePath">

However, looking a few lines further down, we find the groovyc call:

<groovyc srcdir="${mainSourceDirectory}" destdir="${mainClassesDirectory}" fork="true" memorymaximumsize="${groovycMain_mx}">

Let's add the same memory setting as the groovyc call uses to the javac call:

<javac srcdir="${mainSourceDirectory}" includeantruntime="false" destdir="${mainClassesDirectory}"
       memorymaximumsize="${groovycMain_mx}" deprecation="on" debug="yes" source="1.5" target="1.5" fork="true" classpathref="compilePath">

Let's try the upgrade again:

$ sudo port upgrade groovy
--->  Building groovy
--->  Staging groovy into destroot
--->  Deactivating groovy @1.6.1_0
--->  Installing groovy @1.6.2_0
--->  Activating groovy @1.6.2_0
--->  Cleaning groovy

Success.

Update: The memory problem seems to be related to Java6. Switching to Java5 makes the build go through, and I've replicated that on two Macs.