Yesterday evening I ran into a bit of a problem when I tried building my latex document that uses biblatex/biber. For some reason, biber would not generate any output but fail with
Olivers-MacBook-Air:~ porten$ biber
data source /var/folders/5c/y7ssnfgj2fz1fnx1gz_z7ng80000gn/T/par-porten/cache-5a7f3069e2a4d51fd3557003fc55ec74c554c947//inc/lib/Biber/LaTeX/recode_data.xml not found in .
Compilation failed in require at Biber/Utils.pm line 21.
BEGIN failed--compilation aborted at Biber/Utils.pm line 21.
Compilation failed in require at Biber/Internals.pm line 8.
BEGIN failed--compilation aborted at Biber/Internals.pm line 8.
Compilation failed in require at (eval 22) line 2.
...propagated at /opt/local/lib/perl5/5.14.1/base.pm line 94.
BEGIN failed--compilation aborted at Biber.pm line 5.
Compilation failed in require at script/biber-darwin line 20.
BEGIN failed--compilation aborted at script/biber-darwin line 20.
Now, what fixes this is simply deleting the par cache:
sudo rm -rf /var/folders/5c/y7ssnfgj2fz1fnx1gz_z7ng80000gn/T/par-porten/
Running SWTBot tests as part of your maven/tycho build cycle is rather well documented and pretty straight forward (see for example the sonatype docs). Doing so with a WindowTester Pro recorded test is not – but then again it is pretty straigt forward as well.
There are just two things that you need to change from the SWTBot tests pom.xml (as presented in the sonatype docs):
- have useUIThread = true
- add a dependecy to com.windowtester.runtime.feature.group to pull in platform specific plugins
You will also need to tell maven/tycho where to find the latter feature, of course, by adding http://dl.google.com/eclipse/inst/windowtester/beta/3.7 to your repositories.
Full sample pom.xml after the break.
When I first started running my Tycho/Maven build of my visual editor in Jenkins the build would always fail if a single test failed. That was mainly because the Maven build would run the surefire test automatically but cancel the build if there were any failures in them. In turn, this would not keep artifacts from being generated and thus not create a new snapshot release. To make matters worse, my tests are not that stable yet – running them on Linux sometimes fails for no reason whatsoever, leading to yet another broken build.
Now, this is obviously not what you (or Jenkins, for that matter) would expect to happen. What I wanted and what I guess you would normally want is for the build to pass but for Jenkins to mark the build as “unstable”.
To acomplish this on the command line, you simply need to tell Maven to ignore test failures
mvn clean install -Dmaven.test.failure.ignore=true
With Jenkins, this is equally straight forward:
Now Jenkins acts nicely and reports unstable builds while still producing all artifacts.
I finally managed to get the Maven-based build of my Eclipse-based graphical editor to work – including unit and swtbot-ui tests:
[INFO] Reactor Summary:
[INFO] de.van_porten.vrest.build ......................... SUCCESS [0.077s]
[INFO] de.van_porten.vrest.target-platform ............... SUCCESS [0.112s]
[INFO] de.van_porten.vrest.core .......................... SUCCESS [2.842s]
[INFO] de.van_porten.vrest.core.edit ..................... SUCCESS [0.869s]
[INFO] de.van_porten.vrest.core.editor ................... SUCCESS [0.829s]
[INFO] de.van_porten.vrest.bundle ........................ SUCCESS [0.105s]
[INFO] de.van_porten.vrest.help .......................... SUCCESS [0.076s]
[INFO] de.van_porten.vrest.ui ............................ SUCCESS [1.387s]
[INFO] de.van_porten.vrest.ui.properties ................. SUCCESS [3.650s]
[INFO] de.van_porten.vrest.feature ....................... SUCCESS [0.113s]
[INFO] de.van_porten.vrest ............................... SUCCESS [1:08.099s]
[INFO] de.van_porten.vrest.tests.core .................... SUCCESS [4.087s]
[INFO] de.van_porten.vrest.tests.ui ...................... SUCCESS [13.315s]
[INFO] de.van_porten.vrest.p2-repository ................. SUCCESS [2.498s]
[INFO] BUILD SUCCESS
[INFO] Total time: 3:02.410s
[INFO] Finished at: Sat Nov 26 22:22:30 CET 2011
[INFO] Final Memory: 97M/231M
I’ll push to Jenkins now and see if the continous build and test also works there. Cross your fingers.
The one thing that is bugging me is an oddness with my target platform defintion that for some reason doesn’t want to resolve org.apache.batik.* properly – once I switch target to the development platform everything works as expected. But I will figure that one out eventually ..
More on the culprits and solutions I have to follow shortly.
One of the most visited blog entries on this blog probably is my article on transforming CUnit results to JUnit results: CUnit Tests in Hudson. There I write about how to use xsltproc to transform the output of CUnit to be processed by Hudson/Jenkins.
Now, I decided to put the file on BitBucket to maybe consolidate the contributions or changes others are making. I welcome everybody to make contributions to the transform there.
The link to the BitBucket project is: https://bitbucket.org/mcdeck/cunit-to-junit
I’ve been pondering the thought of buying a NAS system for quite some time now but could not find a suitable one. My requirements are quite challenging though, I must admit:
- Silent: I want to run the system near my desk so it has to be very silent. (And I mean super-silent – not just a little silent)
- Fast: Access to the drives has to be fast.
- Feature-Rich Software: I want to use the NAS primarily as a NAS, but it should offer features like BT downloading and the like. It should also act as a iTunes and/or DLNA server.
- Hardware Features:
- Wake-On-Lan / Wake-on-Wan
- Inegrated WLAN Adapter
- Raid 1, 5 or 10; 10 preferred
I bought some off-the-shelf NAS, namely the Synology DS411slim and the Acer easyStore H341. Both were decent devices but were not really up to the challenge. I ended up returning both of them.
After installing Adobe Reader into my Ubuntu installation I noticed that the Adobe Reader was actually making itself at home as the default viewer for PDF files. However, I do only rarely use it because I feel that the Ubuntu Document Viewer (aka evince) is the quicker and better solution most of the time.
Now, I could change the default for double-clicking by going through any PDF file’s Properties->Open With and selecting Document Viewer there. Firefox and Thunderbird for one thing did not really seem to care at all about this, though. Both kept using Adobe Reader to open PDF files when double-clicking in the download window and only offered the reader as the default in the file save dialog.
To work around this problem, I came up with a solution using xdg-mime.
In a terminal, I did
porten@lx-porten:~$ xdg-mime query default application/pdf
porten@lx-porten:~$ sudo xdg-mime default evince.desktop application/pdf
porten@lx-porten:~$ xdg-mime query default application/pdf
Obviously the important part is the xdg-mime default. I would actually have expected setting the default via the file properties to have the same effect, but alas, it does not.
Testing is one of the essential tasks in modern software development, so it is only natural to want to test an application as thoroughly as possible.
I’m currently working on an application that offers a service via xmlrpc. For a client side implementaion I use python’s xmlrpclib and that is working well. Then again, I obviously want to test the xmlrpc functionality also during regular unit and functional tests and not only using the client. What’s more, having to instantiate a server to be able to run tests is cumbersome at best.
Unfortunatly, Pylons does not offer a method to test xmlrpc controllers out of the box. The solution I found is not quite as complicated as I had feared at first. Read more after the break.
To be able to use Basic Authentification in repoze.who running in a wsgi app in your Apache installation, you need to tell Apache to WSGIPassAuthorization. An Apache configuration like this will do:
# Setup mod_wsgi
WSGIScriptAlias /myApp /var/www/pylons/myApp/mod_wsgi/dispatch.wsgi
Allow from all
The importanat part here is
This will pass HTTP authorisation headers through to the WSGI application.
Sources: Repoze-dev Mailing List, modwsgi Wiki
This might seem easy enough, but it took me a while to get it right since the Pylons documentation is a bit misleading here, really. It says you should use xmlrpc_fault from pylons.controllers.xmlrpc but that’s actually not working if you’re doing something like:
from pylons.controllers.xmlrpc import xmlrpc_fault
return xmlrpc_fault( 101, "My Error" )
This will wrap an xmlrpclib.Fault into a pylons.controllers.util.Reponse object which will fail to marshal with something like:
TypeError: cannot marshal <class 'pylons.controllers.util.Response'> objects </class>
The correct way to do it is:
return xmlrpclib.Fault( 101, "My Error" )