Skype for linux is a long way behind the windows version. They appear to have only a single developer working on it, who posts updates to the skype linux developer blog about every 6 months. There haven’t been any releases for a long time, so we don’t have integration with modern linux environments (e.g. pulseaudio) and we don’t have many of the new skype features such as desktop sharing.

However, with a little trickery, it is possible to share a linux desktop through skype (well, sort of…). The Skype video hijacker (aka gstfakevideo) allows you to use any gstreamer pipeline as a pseudo-video device in skype. This was originally planned to improve video performance in skype and add compatibility for many new webcams, as well as video manipulation functionality. It can also be used to share your desktop, in relatively new steps.

There aren’t any releases of gstfakevideo, so you’ll have to build it yourself; this is quite simple though:

$ svn checkout http://gstfakevideo.googlecode.com/svn/trunk/ gstfakevideo-read-only
$ cd gstfakevideo-read-only
$ make
$ sudo make install

Then you can close down skype and restart through gst fake video with the following command:

gstfakevideo ximagesrc ! ffmpegcolorspace ! videoscale

This will provide your desktop as a fake webcam in skype. You can change the command to include any gstreamer pipelines (although there are colour limitations for skype). Properties can be set for ximagesrc to restrict it to a subset of the desktop. See the ximagesrc docs for details.

Unfortunately the quality is extremely poor, so that it is barely readable – I’m not sure if that is a skype linux limitation or an issue with the gstreamer pipeline definition. Help from gstreamer experts would be very welcome.

Maven holds useful information about a build and places this in generated jar files under /META-INF/maven/group/artifact/pom.properties. This can be easily accessed from within the code to do useful things like print out the real version number without having to mess around with pre-processing or filtering of source code.

    public String getVersion()
    {
        Properties props = new Properties();
        String version = "DEVELOPMENT";
        try
        {
            InputStream in = getClass()
                    .getResourceAsStream(
                            "META-INF/maven/com.onespatial.radius.clarity/claritystudiobuiltins/pom.properties");
            if (in != null)
            {
                props.load(in);
                version = props.getProperty("version");
            }
        }
        catch (IOException e)
        {
            e.printStackTrace();
        }
        return version;
    }

Memory Leaks and other memory related problems are among the most prominent performance and scalability problems in Java

via Java Memory Problems Performance, Scalability and Architecture – Java and .NET Application Performance Management (dynaTrace Blog).

Alois Reitbauer wrote this insightful post about java memory problems. It’s often overlooked when debugging performance issues, but can be critical. I once managed to increase the performance of an optimal route finding system by over 100x by removing some ‘leaks’ and over-excited object creation code. This was similar to Alios’s experiences where other developers had spent weeks tearing apart the execution profiles and redesigning the system before realising that it was a simple garbage collection issue. Poor support from profiling tools at the time also didn’t help.

The comments about garbage collection configuration are particularly interesting – I’d always assumed that there was little room for improvement. Time to read the docs…

The Maven Release Plugin is a great little tool for automatically releasing maven projects – it will create tags in your source repository and update all your version numbers automatically.
Unfortunately, the documentation is rather lacking when it comes to the format of version numbers. We wanted a set of alpha releases of a product, but couldn’t get the release plugin to find the next version correctly. For example, it would think that the successor to 2.1alpha1 is 2.2alpha1 rather than 2.1alpha2.
It turns out that this is all documented in the javadocs relating to the release management.
From the javadocs for Maven’s DefaultVersionInfo class:

The supported version scheme has the following parts.
component-digits-annotation-annotationRevision-buildSpecifier
Example:
my-component-1.0.1-alpha-2-SNAPSHOT

Terms:
• component – name of the versioned component (log4j, commons-lang, etc)
• digits – Numeric digits with at least one “.” period. (1.0, 1.1, 1.01, 1.2.3, etc)
• annotationRevision – Integer qualifier for the annotation. (4 as in RC-4)
• buildSpecifier – Additional specifier for build. (SNAPSHOT, or build number like “20041114.081234-2″)

Digits is the only required piece of the version string, and must contain at lease one “.” period.

Implementation details:
The separators “_” and “-” between components are also optional (though they are usually reccommended).
Example:
log4j-1.2.9-beta-9-SNAPSHOT == log4j1.2.9beta9SNAPSHOT == log4j_1.2.9_beta_9_SNAPSHOT

* Leading zeros are significant when performing comparisons.

After reading that, it is obvious what we were doing wrong. The unit tests also give a few useful examples:

    public void testNextAnnotationRevision()
        throws Exception
    {
        checkNextVersion( "1.01-beta-04", "1.01-beta-05" );
        checkNextVersion( "1.01-beta-04-SNAPSHOT", "1.01-beta-05-SNAPSHOT" );
        checkNextVersion( "9.99.999-beta-9-SNAPSHOT", "9.99.999-beta-10-SNAPSHOT" );
        checkNextVersion( "9.99.999-beta-09-SNAPSHOT", "9.99.999-beta-10-SNAPSHOT" );
        checkNextVersion( "9.99.999-beta-009-SNAPSHOT", "9.99.999-beta-010-SNAPSHOT" );
        checkNextVersion( "9.99.999-beta9-SNAPSHOT", "9.99.999-beta10-SNAPSHOT" );
    }

I’ve just discovered a trivial way of creating a web service in a j2se application. The aim of the webservice was purely as a test – I was taking an existing service (defined by a wsdl and implemented with jax-ws) and creating a mock service to invoke as part of a workflow. The mock service endpoint was a standard jax-ws annotated @WebService class, implementing the interface generated by xjc. I was expecting to have to use jetty and the jax-ws servlet to actually create a web service, but found a utility class in jax-ws that creates a simple service automatically. Thanks to the power of jax-ws, my test service class is now as simple as the following:

import javax.xml.ws.Endpoint;

public class MockWebService
{
  public static void main(String[] args)
  {
    Endpoint.publish("http://localhost:8666/mockservice", new MockServiceEndpoint());
    // MockServiceEndpoint is a simple mock impl implementing the xjc-generated stubs.
  }
}

Fantastic!

Just a few notes in case I forget these annoying workarounds:

If the navigator window (hit F5) becomes detached on linux, it won’t automatically re-attach by dragging. To re-attach it, hold ctrl down and double-click on the gray area behind the toolbar

To add a cross references, don’t use the navigator window, it will just mess things up. Use Insert-cross reference with a reference to the headings and format Number (full context). Apparently this gets ugly if you try to read it in MS word though.

To avoid connection problems and svn ignoring your proxy configurations, it’s best to use the JavaHL (JNI) library for subclipse. This can be set from the Team->SVN->SVN interface preferences dialog within eclipse. The libraries must be installed (libsvn-java package)
The missing piece of the puzzle though is that the native libraries need adding to the java library path (they aren’t there by default). To do this, add the following to your eclipse.ini file:
-Djava.library.path=/usr/lib/jni

Doesn’t seem to be documented anywhere useful…

I’ve just spent another 2 hours trying to get the jaxb-maven-plugin to work on my build machine. I’ve noticed this problem several times in the past too – javb-maven-plugin is not happy when you move between JVMs. Unfortunately to identify the problem I had to modify and re-build the plgin to get it to show an exception. At least it’s open source and maven makes it trivial to do this though…

To use the plugin in java 1.5, you need to specify a jaxws dependency:


<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>1.11-SNAPSHOT</version>
<executions>
<execution>
<goals>
<goal>wsimport</goal>
</goals>
</execution>
</executions>
<configuration>
<packageName>com.mypackage</packageName>
<wsdlDirectory>src/main/resources/</wsdlDirectory>
<wsdlFiles>
<wsdlFile>MyService.wsdl</wsdlFile>
</wsdlFiles>
<verbose>false</verbose>
<target>2.0</target>
</configuration>
<dependencies>
<dependency>
<groupId>javax.jws</groupId>
<artifactId>jsr181-api</artifactId>
<version>1.0-MR1</version>
</dependency>
</dependencies>
</plugin>


Thanks to this forum thread for giving the final clues

I’ve just discovered a very well hidden feature in open office. It is possible to print multiple pages per sheet (as you can do in just about every gnome application through the standard print dialog):

• View the print preview (from the toolbar button)
• Select multiple pages (from the toolbar), so that the number of pages per sheet is shown on the screen
• Select print page view from the toolbar. You will need to manually set the page orientation (landscape/portrait) from the standard print dialog, but otherwise it will print n pages per sheet!

The Maven2 release plugin is fantastic at sorting out your builds, but can be quite slow.
The default script operates in two phases: First, it checks that the project is valid, updates the poms and creates appropriate tags in subversion. Secondly, it checks out the tagged code, performs a full build and deploy.

If you follow good practises and have a CI system in place, the additional tests in the first phase are slightly unncessesary. Fortunately, these can be easily disabled and will speed up your build system considerably. Simply run the following:

mvn release:prepare -DpreparationGoals=clean