Saturday, May 26, 2012

SVN commit problem: no working copy

During developing I often use SVN as CVS. However, sometimes when trying to commit I get an error message stating that a specific folder/file is no working copy which leads to a failure of the commit process.

But don't worry: it is easy to fix in a few steps:

  1. Create a copy of the affected folder and move it to somewhere outside your working copy.
  2. Clear the copied folder of all SVN-references (e.g by deleting all .svn folders).
  3. SVN-delete the affected folder (either be SVN CLI or from the context-menu when using tools like Tortoise/Rabbit-SVN) - if the folder contains subfolders make sure to also SVN-delete these as the SVN-delete command is not recursive.
  4. Commit the deleted (and only the deleted!) folder.
  5. Delete the folder from the filesystem.
  6. Copy the aforementioned copied folder back into the working copy.
  7. SVN-add the folder.
  8. Commit.
That should make sure, that you're working copy is usable again. Another way would be to just SVN-revert the folder to the last revision, but thus you would loose all changes you've made since the last commit/update.

Monday, May 14, 2012

How to properly restore a backed-up Eclipse workspace

This morning my Ubuntu crashed while I was working in Eclipse. Unfortunately this also corrupted my workspace state. But, no problem - I had a backup. However, restoring the backup wasn't as easy as I had thought...

I had backed up my home partition with deja-dup - the built in backup solution in Ubuntu. After the recovery deja-dup's status dialog gave me quite a few error messages stating that SVN related files couldn't be restored due to missing permissions. I assume, this was due to the fact, that rabbitcvs, the tool I access my SVN repositories with besides Eclipse, still was holding locks on these files.

Stopping rabbitvcs's status checker service didn't help. So I fired up deja-dup's recovery dialog again by right clicking on the folder and choosing the "Revert to previous version..." entry. After the dialog appeared (and deja-dup knew the path of the folder it should recover) I renamed the workspace folder (could also have deleted it, but just in case...) and let deja-dup do it's job. And guess what, it worked! As deja-dup doesn't seem to just restore the changed files, but everything, that is under the marked folder, there is also no performance loss in acting like this.

"Easy-peasy!" you may shout out now, but for me it took nearly 10 minutes to work this out.

Friday, April 13, 2012

Adding CXF runtime environment to Eclipse

Another quick tip for JAX-WS development in Eclipse:

When adding a CXF-Runtime via Window->Preferences->CXF 2.x Preferences don't forget to set a checkmark to the left of the entry, otherwise Eclipse won't use the environment and will complain about a missing CXF jar.

Export Java Libraries into WAR file

Just deployed my first JAX-WS web service with external libraries (SMACK in my case) in Eclipse and discovered, that to get the libraries into the exported WAR one has to add them via Properties->Deployment Assembly) of the web project. Adding them to exported libraries in the build path view doesn't have the desired effect.

Thanks goes to Thorbjørn who answered the question on Stackoverflow.

Openfire doesn't start

Just downloaded the latest release of Ignite Realtime's Openfire XMPP server. They also provide a .deb package besides .tar.gz, so I chose to use it. After installing I tried to start the server by executing

/etc/init.d/openfire start

But nothing happened.


So I further inspected the code of the script and found out, that it only checks for old Java versions:

if [ -z $JAVA_HOME ]
then
t=/usr/lib/jvm/java-1.5.0-sun && test -d $t && JAVA_HOME=$t
t=/usr/lib/jvm/java-6-sun && test -d $t && JAVA_HOME=$t
fi


But my Java version java-7-oracle was missing. So I simply added it at the end:

if [ -z $JAVA_HOME ]
then
t=/usr/lib/jvm/java-1.5.0-sun && test -d $t && JAVA_HOME=$t
t=/usr/lib/jvm/java-6-sun && test -d $t && JAVA_HOME=$t
t=/usr/lib/jvm/java-7-oracle && test -d $t && JAVA_HOME=$t
fi


which allowed the script to run properly.