Posted by Andrew Phillips around lunchtime: July 20th, 2011
Recently, I was preparing a connection checker for Deployit’s powerful remote execution framework Overthere. To make the checker, as compact as possible, I put together a jar-with-deps1 for distribution.
Tests and trial runs from the IDE worked, so I was expected the dry-run of the distribution to be a quick formality. Instead: boom!
Turns out that one of the libraries used by Overthere, TrueZIP – or indeed any code that utilizes Java’s SPI mechanism2 – doesn’t play well with the jar-with-deps idea. (more…)
Posted by Barend Garvelink mid-afternoon: February 25th, 2011
Update, 26-02: Brian Demers from Sonatype pointed out in the comments that Maven 2.0.10 and later are forwards-compatible with changes in the metadata format. If your Maven 2 version is one of the recommended versions on the download page, you will not have this problem.
Two days, in fact. Yesterday evening, after my colleagues went home, I brought down our Nexus 1.8.0.1 instance to upgrade it to 1.9 without interrupting their work. The download page for Nexus 1.9 contains the following instruction:
Sonatype has changed how the lucene indexes are stored on disk, it is required that users reindex all repositories in their nexus server to start benefitting from the changes (and for search to work properly).
Inconspicuous enough. Furthermore, clicking through from the change overview to the full change log reveals:
[NEXUS-3849] – Add full support for the new maven 3 snapshot metadata
What it doesn’t reveal is that the rebuild metadata command in the repository administration screen, which would appear to be proper housekeeping at a time when you’re reindexing the repositories, now generates Maven 3 style metadata and inadvertently breaks compatibility with Maven 2 (update: older versions). This is where the fun begins.
Posted by Wilfred Springer in the late evening: February 6th, 2010
I’m proud to say that – during the six years of employment at the company formerly known as Sun Microsystems – I wrote all my documents in DocBook. Of course there was the occasional warning that we were all expected to use StarOffice, but by making sure the DocBook generated output resembled the printed material produced by HQ, it never turned into a big argument. And since my entire DocBook chain was built from open source, I had to use Apache FOP.
Apache FOP has a long history (more…)
Posted by Vincent Partington in the wee hours: January 7th, 2010
Last year, before the Christmas holidays 
, I described how we do middleware integration testing at XebiaLabs and I described the way we deploy test servlets by wrapping them in WAR and EAR files that get generated on the fly. There is only one thing left to explain; how do we integrate these tests into a continuous build using Maven and VMware?
Running the middleware integration tests
So let’s start with the Maven configuration. As I mentioned in the first blog of this series, the integration tests are recognizable by the fact that the classnames end in Itest. That means they won’t get picked up by the default configuration of the Maven Surefire plugin. And that is fortunate because we don’t always want to run these tests. Firstly they require a very specific test setup (the application server configurations should be in an expected state, see below) and secondly they can take a long time to complete and that would get in the way of the quick turnaround we want from commit builds in our continuous integration system.
(more…)
Posted by Vincent Partington at around evening time: December 14th, 2009
Last week I wrote about the approach we use at XebiaLabs to test the integrations with the different middleware products our Java EE deployment automation product Deployit supports.
The blog finished with the promise that I would discuss how to test that an application can really use the configurations that our middleware integrations (a.k.a. steps) create. But before we delve into that, let us first answer the question as to why we need this. If the code can configure a datasource without the application server, it must be OK for an application to use it, right? Well, not always. While WebSphere and WebLogic contain some functionality to test the connection to the database and thereby verify whether the datasource has been configured correctly, this functionality is not available for other configurations such as JMS settings. And JBoss has no such functionality at all. So the question is: how can we prove that an application can really work with the configurations created by our steps?
(more…)
Posted by Vincent Partington at around evening time: December 7th, 2009
For Deployit, XebiaLabs’ automated deployment product for Java EE applications, we are always building and modifying integrations with middleware systems such as IBM WebSphere, Oracle WebLogic and the JBoss application server. These integrations are small enough so that they can be rearranged to get many different deployment scenarios. A typical step, as we call these integrations, would be “Create WebSphere datasource” or “Restart WebLogic Server”. So how do the test that code?
We’ve had some success using FitNesse and VMware to do integration tests on our deployment scenarios. But there were a few problems with this apporach:
- We could only test complete deployment scenarios in this way. If we wanted to test just a single step, we had to make a deployment scenario that used that step just to be able to test it.
- Because FitNesse does not provide any feedback while a test is running and the steps, let alone the deployment scenarios, can sometimes take a while to execute, there was little feedback on the progress.
- While it is possible to debug a FitNesse Fixture using Eclipse the process is not very convenient when debugging a technical component such as this step.
- To verify that a deployment scenario has executed succesfully we had to extend our FitNesse Fixture often. And while debugging code under test in FitNesse is complicated enough, debugging a Fixture is even harder!
Clearly we needed a different approach if we wanted to develop new steps easily.
(more…)
Posted by ShriKant Vashishtha in the early afternoon: November 22nd, 2009
When it comes to generating command-line scripts for Java applications, Maven “appassembler” plugin comes handy. Its “assemble” goal does all the maven magic, i.e. searching the dependencies used for creating the Java application, adding them into the classpath of resultant script and finally copying all relevant jars to a single place. It was all working very nicely until I stumbled across the problem of long classpaths in the Windows OS.
Irrespective of whether you use DOS prompt or cygwin, Windows limits the length of environment variables. Though there are various options to overcome this problem using Java 6 wildcard classpath, mapping the path to some drive etc, they all look like workarounds to me as problem can recur again anytime.
(more…)
Posted by Wilfred Springer in the late evening: October 14th, 2009
Maven archetypes are an excellent way of allowing people to create instances of a particular type of project without having them to know or worry about all of the peculiarities and details. (And the latest incarnations of the Maven Archtetype Plugin are actually way better than I realized: somewhere down the line, they introduced the ability to use Velocity templates for parameterizing the output. Nice!)
(more…)
Posted by Maarten Winkels in the late evening: September 2nd, 2009
Posted by Ravan Naidoo in the early morning: July 14th, 2009
Recently I had to get JAX-WS based webservices running on Weblogic 10.3. However instead of using the default Weblogic 10.3 stack (Metro), the Apache CXF stack had to be used. Why? We required SOAP over JMS capabilities and that is possible with CXF without much effort.
(more…)