Source: http://dickmcjohnnson.blogspot.co.uk/2011/07/logitech-webcam-pro-9000-running-under.html
Currently working logitech.xml link: http://dl.dropbox.com/u/29758043/logitech.xml
Quick:
get logitech.xml, run sudo uvcdynctrl -i logitech.xml
The maven inheritance/parentpom structure is great for defining common build steps, but there is often a need to override or completely disable some stages in child modules. Most maven plugins provide a configuration option to skip them, which can simply be added to the child module.
The cobertura plugin is more difficult, because it actually invokes an entire sub-lifecycle within the default build lifecycle. This lifecycle includes a number of stages such as pre-test, test and post-test which all execute any plugins defined for those stages. This typically means cobertura instrumentation, surefire testing and cobertura results checking. Configuration in the child module can disable the instrumentation or change the results checking, but won’t remove the sub-lifecycle completely.
Fortunately, there is a rather obscure way of doing this – override the cobertura execution to change the lifecycle phase in which it applies:
<plugin><groupId>org.codehaus.mojo</groupId><artifactId>cobertura-maven-plugin</artifactId><executions><execution><id>cobertura-clean</id><phase>none</phase></execution><execution><phase>none</phase></execution></executions></plugin>
You will need to make these executions and in particular the id tags match the parentpom exactly, depending on how you have configured cobertura.
This same approach should work for all plugins.
I want to check out all trunks from a hierarchical svn tree structure containing multiple projects at different levels. A standard svn checkout of the root will attempt to get all tags and branches, which will take far too long.
The following bash script helps with this – it will find all the trunks and print the svn commands to check them out.
#!/bin/bash
check() {
local PROJ_ROOT=$1
local PROJ=$2
local FILE_ROOT=$3
#echo "Check($PROJ_ROOT, $PROJ, $FILE_ROOT)";
case $PROJ in
tags/) ;; ## ignore
branches/) ;; ## ignore
trunk/)
echo svn co $PROJ_ROOT/$PROJ $FILE_ROOT ;;
*/) # FOLDERS only
#echo "Looking in $PROJ_ROOT/$PROJ"
for PROJ2 in `svn ls $PROJ_ROOT/$PROJ`; do
check $PROJ_ROOT/$PROJ $PROJ2 $FILE_ROOT/$PROJ;
done;
esac;
}
check '$1' '/' `pwd`;
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
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-SNAPSHOTTerms:
- 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…