grails 1.3.8 and java 1.6

since we still have a lot of grails 1.3.8 application, we are forced to use them and apparently sometimes all the test fail with the following exception:


java.lang.IllegalAccessError: tried to access class org.apache.xml.serializer.XSLOutputAttributes from class org.apache.xalan.transformer.TransformerImpl at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2387) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2255) at org.apache.xalan.lib.Redirect.write(Redirect.java:212) at org.apache.xalan.extensions.ExtensionHandlerJavaClass.processElement(ExtensionHandlerJavaClass.java:495) at org.apache.xalan.templates.ElemExtensionCall.execute(ElemExtensionCall.java:230) at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:395) at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:177) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2336) at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2202) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1276) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:673) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1192) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1170) at org.apache.tools.ant.taskdefs.optional.TraXLiaison.transform(TraXLiaison.java:187) at org.apache.tools.ant.taskdefs.XSLTProcess.process(XSLTProcess.java:709) at org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:333) at org.apache.tools.ant.taskdefs.optional.junit.AggregateTransformer.transform(AggregateTransformer.java:264) at org.apache.tools.ant.taskdefs.optional.junit.XMLResultAggregator.execute(XMLResultAggregator.java:158) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at _GrailsEvents_groovy$_run_closure5.doCall(_GrailsEvents_groovy:58) at _GrailsEvents_groovy$_run_closure5.call(_GrailsEvents_groovy) at _GrailsTest_groovy$_run_closure1.doCall(_GrailsTest_groovy:199) at TestApp$_run_closure1.doCall(TestApp:82) at gant.Gant$_dispatch_closure5.doCall(Gant.groovy:381) at gant.Gant$_dispatch_closure7.doCall(Gant.groovy:415) at gant.Gant$_dispatch_closure7.doCall(Gant.groovy) at gant.Gant.withBuildListeners(Gant.groovy:427) at gant.Gant.this$2$withBuildListeners(Gant.groovy) at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source) at gant.Gant.dispatch(Gant.groovy:415) at gant.Gant.this$2$dispatch(Gant.groovy) at gant.Gant.invokeMethod(Gant.groovy) at gant.Gant.executeTargets(Gant.groovy:590)
fix in the BuildConfig.groovy file:


inherits("global") { // uncomment to disable ehcache // excludes 'ehcache' excludes 'serializer' }

git deleting remote branch

deleting a remote branch is rather clunky, but easy:

git push origin :branch

please ensure that you have the colon (:) infront of your branch name to ensure that the branch will deleted.

git memorizing branches

First, you must create your branch locally

git checkout -b your_branch

After that, you can work locally in your branch, when you are ready to share the branch, push it. The next command push the branch to the remote repository origin and tracks it

git push -u origin your_branch

Teammates can reach your branch, by doing:

git fetch
git checkout origin/your_branch

You can continue working in the branch and pushing whenever you want without passing arguments to git push (argumentless git push will push the master to remote master, your_branch local to remote your_branch, etc...)

git push

Teammates can push to your branch by doing commits and then push explicitly

... work ...
git commit
... work ...
git commit
git push origin HEAD:refs/heads/your_branch

Or tracking the branch to avoid the arguments to git push

git checkout --track -b your_branch origin/your_branch
... work ...
git commit
... work ...
git commit
git push

Found at stackoverflow

submitting all files in a directory to qsub

recently we needed a small script to submit all files in a directory to a script, executed by qsub.

#!/bin/bash if [ $# -lt 2 ]; then echo Missing arguments... echo "Use: process.sh 'input dir' 'output dir'" exit 1 fi if [ -d $1 ]; then for file in `ls $1` do qsub -cwd -p -512 run.sh $1$file $2 done else echo "Missing or incorrect input directory..." exit 1 fi

and the actual run.sh script is just a small java program, which takes our two parameters.

java -Xmx1024m -jar $HOME/data/jars/DataExtractor-0.1.jar $1 $2

maven-assembly-plugin - stackoverflow

currently I'm developing several helper tools for the alchemy project and promtply run into the issue of a stackoverflow exception with maven. Basically I try to assemble several archive, including all the required jars and generate the corresponding MANIFEST.MF files for a couple of main classes. apparently with maven3, you have to set the following flag: export MAVEN_OPTS=-Xss2m to avoid having a stackoverflow exception. Annoying... solution found here

Maven - generate executable jar file

Recently I started to work a bit more with scala again and also finally upgraded to my new nemesis, maven3. More torture than maven2, but I could not live without it.

So what I wanted todo is rather simple, build an archive containing all my classes, a generated manifest and make it executeable.

10 minutes later we found the solution:



<plugin> <artifactId>maven-assembly-plugin</artifactId> <executions> <execution> <id>convert-to-asci</id> <phase>package</phase> <goals> <goal>single</goal> </goals> <configuration> <archive> <manifest> <mainClass>edu.ucdavis.fiehnlab.alchemy.core.process.util.ConvertMZXmlToAscii</mainClass> <packageName>edu.ucdavis.fiehnlab.alchemy.core.process.util</packageName> <addClasspath>true</addClasspath> </manifest> </archive> <descriptors> <descriptor>src/main/descriptor/jar.xml</descriptor> </descriptors> <finalName>ConvertMzXmlToASCII-${project.version}</finalName> <appendAssemblyId>false</appendAssemblyId> </configuration> </execution> <execution> <id>alchemy-converter-zip</id> <phase>package</phase> <goals> <goal>single</goal> </goals> <configuration> <descriptors> <descriptor>src/main/descriptor/zip.xml</descriptor> </descriptors> <attach>true</attach> <finalName>alchemy-converter-${project.version}</finalName> </configuration> </execution> </executions> </plugin> The important part is to set the appendAssembyId to false, otherwise you get all kinds of annoying exceptions....

relocating a git repository

Recently I started creating a new project, with the amazing name 'alchemy'. Sadly it turned out that this name was already taken on google code. So to start working on it I had to create a temporary project on google code and once I managed to get my greedy fingers on the others project name (successful I might add!) ...

...I had now the challenge to move my dozen or so lines of codes over to the new repository.

Now I'm the first one to admit, I'm still kinda green with 'git' and have only used it in the past on 1 or 2 little project and never on anything real. So how complicate will it be to move the code and not loose your complete history of commit (all 7 of them...)

Surprisingly easy it turns out, just issue the following magic commands and you are all set.

1. git remote add alchemy https://code.google.com/p/alchemy/
2. git push alchemy master
3. git remote rm origin
4. git remote add origin https://code.google.com/p/alchemy/
5. git remote rm alchemy

Now looking at this, I'm quite sure I could had simplified this even more, but for now it got the job done.