MiR: August 2008

Month in Review: August 2008

August started out with quite a bit of excitement as the FUSE team gathered in Dublin Ireland to discuss project status and future development. This was my first time to see Dublin and meet the core group of Open Source developers working on the various components of FUSE.

Upon return to Newfoundland I dived into research and development involving Apache Servicemix Kernel and XHarness. The first phase of this work was to gain a deeper understanding of Apache Geronimo GShell, Plexus, and JLine. The second phase has been to improve XHarness to inter-operate smoothly with these technologies.

The first fruits of these efforts were released in XHarness 1.0-beta2, you can expect to see more improvements in the upcoming XHarness 1.0-beta3.

Open Source headline in Quebec

A recent headline carried on the CBC is reporting that "Quebec's open-source software association is suing the provincial government, saying it is giving preferential treatment to Microsoft Corp. by buying the company's products rather than using free alternatives." The original story posting can be found here, a press release by FACIL regarding this story can be found on their website here.

This will be an interesting story to follow.

Cheers

SNAPSHOTs are my Kryptonite

I've been playing around with building my own SNAPSHOT of Apache Geronimo GShell . For those of you not familiar with Maven SNAPSHOTs they are the artifacts generated during a Maven build on a project's SNAPSHOT branch (this is defined in the project's pom file).

SNAPSHOTs are a necessary step in the development of project code. Not every build of a project's source code can be considered a point release. To add new features, fix reported bugs, refactor code, or just improve internal documentation, among other things, developers need to build the source and test the modified modules. The process of iterating through successive build/test cycles allow for a higher quality finished release.

So far so good, how could this cause development pains?

Allow me to elaborate. When building larger applications developers will rely on features from other projects, sometimes these features only exist in SNAPSHOT form as the next point release containing the required feature have not yet been made (and may be days, weeks, or months away from release). So to continue onwards with their own project developers will include dependencies on SNAPSHOT builds. Something to keep in mind however is that SNAPSHOT builds may or may not be available for a given project's repository or mirrors at all times (resulting in an Artifact not found message, and failed build)...

So back to my above statement, why are SNAPSHOTs my Kryptonite?

By depending on a SNAPSHOT one becomes dependent upon the continual successful build of an unstable code branch. These dependencies deepen as relied upon projects also include their own SNAPSHOT requirements. The possible non-availability of particular SNAPSHOTs can result in you not being able to build the project your currently interested in. Sure you can checkout the source code to your dependencies and build your own SNAPSHOTs, and repeat the process until you can build your entire project... this process normally works, it just takes time :S

Is there any solution to this problem?

Considering the nature of SNAPSHOTs there probably isn't much that we can do to ensure that we don't spend too much time building dependencies, forward progress in development can not always be with a stable code base. In practice we have to assume that SNAPSHOTs will be available from some repository, those that are not will hopefully be a quick svn co <branch>, mvn install away.

It's taken several hours now to build up the dependencies I required for my SNAPSHOT of GShell. Now that I have these artifacts in my .m2/repository I can continue on developing as per normal. I just wanted to share a little of my adventure in the process, and relieve some of the sudden headache I develop every time I build a project and get artifact unavailable in all defined repositories - then see the word <ProjectName>-SNAPSHOT.jar.

Cheers

XHarness How To: Using ignore ANSI.

With the release of XHarness 1.0-beta2 I have decided to write a quick how-to for using the new ignore ANSI feature. The reason for this feature addition was to resolve the issue separation of content and presentation.

When testing an application we are generally concerned with the correct content of output, presentation details such as bold text or text colour markups may not be essential to asserting a correct response.

Take for example an application that takes in a username and reports back "Hello username, welcome to example1 program". The general format of the XHarness definition to test this program would be:

<xh-execbg executable="${path.to.app}/bin/example1"
processname="example1"
dir="${path.to.app}"/>
<arg line="foobar"/>
</xh-execbg>
<assert timeout="10" erroronfail="true">
<and>
<outputcontains stream="stdout"

task="xh-execbg">Hello foobar, welcome to example1 program.</outputcontains>
</and>
</assert>

Given the input "foobar" we expect the output to be "Hello foobar, welcome to example1 program." In this case XHarness will run the demo application, assert the correct output was received, then report success.

Now what happens if we modify example1 program to print out username in bold? The above XHarness definition would report a failed assertion. The reason for this is that the output contains method will be looking for plain text, the markup to present bold text would violate the matching specified.

To simplify working with output that may include ANSI markups the ignoreansi attribute was added. The default behavior is to not ignore ANSI text markup control characters, thus allowing developers to consider these markups part of a correct response. If the developer however would like to ignore such presentation details and just focus on the content of a response they may alter their output contains fragments to the following:

<assert timeout="10" failonerror="true">

<and>

<outputcontains stream="stdout"

task="xh-execbg"

ignoreansi="true" >Hello foobar, welcome to example1 program.</outputcontains>

</and>

</assert>

This time when XHarness processes the output from example1 program it will assert a match successfully.

For more information on using XHarness please see the XHarness web site: http://xharness.codehaus.org

XHarness 1.0-beta2 Released

"XHarness is a system test harness for Apache Ant 1.6.x. It allows people to describe their product/system tests in the form of XML as part of an ant build file, describing the tasks and processes that comprise the test cases and what their expected behaviour is."

This latest release includes fixes to the Unix async launcher and includes a new ignore ANSI control character mode for output matching.

You can download XHarness 1.0-beta2 from the download page.

Hello World!

Another blog is born... This one will focus on my adventures in open source, events, and anything else occupying my mind.

Cheers