I got back into doing a small feature enhancement for Continuum the other day. There was just one problem - after I built Continuum myself and ran it, my machine dropped to a blue screen of death and rebooted. (Yes, I'm back on Windows). This was pretty strange, as running Continuum that others built work just fine, and I really didn't have time to investigate it any further.

What to do? Pretty hard to develop if you can't run something you build. I don't really have a separate development server at my disposal right now.

Luckily, I'd gone VMWare image crazy just a few days before. I was testing out startup scripts, so I've used this information to create a stack of VM images - from my old versions of Windows I have lying around to Darwin and OpenSolaris. I also had the Ubuntu VM already downloaded from the VMWare site. Up until a couple of months ago I'd been using Ubuntu but I got tired of the network problems I was having, so it was good to have it around again.

That was the best solution I could come up with. I now have my home directory on the Ubuntu VM mounted over samba so I can edit like its local, run it in the VM, browse from my own browser, and debug using remote debugging like I'd have to anyway. The speed difference really isn't noticable - the only annoying thing is coordinating the capture of the pointer inside that window.

So, an odd setup, but actually quite a nice one if you like Linux from the command line and Windows for your apps (and drivers).

TestNG has been on my "must play with that some day" list for quite some time. Though I'm yet to write any significant tests with it, I was lucky to recently get some exposure to it to prod me along. This came in the form of support for Maven 2 contributed by Jesse Kuhnert, who not only did the initial patch but continually and patiently prodded me to look at it. I'd also listened to Cédric's JavaPosse podcast (or at least the first half, it seems to cut all the old ones off in the middle). I'd also started to get the IDEA plugin, assuming I got the right one
since the web page just said "get the plugin from the plugin list", and there are two, neither of which seem to be related to the project. The other was a generator and I now have the little TestNG logo in the configurations dialog, so I think I'm good to go.

The main reason I had put it off for so long was that I hadn't yet learned much about actually using TestNG and I knew I was going to have to make some changes to our test runner code called Surefire that has been around a long time and not evolved with the Maven 2 architecture. The patch for TestNG worked out of the box, but didn't (couldn't) integrate with other features.

There were some rough edges along the way. Since the patch was using a few internal APIs from TestNG that were public, upgrading through releases that had come since constantly broke the code. Might be time to introduce them to Clirr, another of my favourite new toys :)

However, the refactoring is now done and the TestNG code all revisited, and we've landed support that is comparable to JUnit (3) and the basic POJO test runner that is built in. It supports all of the fork modes (none, once for the whole suite, or fork for each test set), but more importantly integrates with anything else in the build lifecycle, such as Cobertura, without any additional configuration. This required very little TestNG specifics, so hopefully the basis is now there for other providers, as we start to see requests for JUnit 4 roll in. This is pretty satisfying, as we get to see the fulfilment of Maven's promised build knowledge reusability in action.

Once released, using TestNG tests is just a matter of including:

And from there you can run the usual mvn test, mvn cobertura:cobertura, mvn clover:clover, etc. Of course, you can customise them to enable things such as parallel test execution and using TestNG's XML suite definition files instead of the normal includes/excludes mechanism.

Another great thing is that you can try out TestNG immediately, even with your JUnit tests in place - the test runner finds each Java file and sets the JUnit flag for tests if appropriate so that they can be mixed in the directory with TestNG tests.

There are some instructions for those that might be game enough to test it before the release, but it is not quite there yet and there are still some minor bugs to be resolved. Hopefully, these won't hold it up for too long.

All in all, I think this is a great development and I certainly anticipate trying out TestNG on my current project. Just as soon as I get through all the mail I haven't read while I was playing around with it.

Technorati Tags: maven

Do yourself a favour - check out Jetty6.

It's been a while since I've done any form of webapp development, so I'm a bit rusty. The last place I worked at ran Tomcat servers (quite successfully), so development was naturally done against the same, with the occasional foray into Resin. But both suffered from the problem that fairly regularly, someone would get their dev environment misconfigured and spend some time troubleshooting where it had all gone wrong. It was inevitably something simple and completely unrelated to the NullPointerException or some other runtime exception that had popped up in the logs or in the browser.

With IDEA having Tomcat support built in, when I was starting to test the new webapp I naturally fell back to the old habit of firing that up. And then, no end of of problems:

• The Windows install of Tomcat omits all the startup scripts because you get a service, and you'd never want anything else, right? The IDEA support requires the scripts, so I grab the tarball instead.
• Errors on startup. SEVERE: Error filterStart. I know that means an exception in the filters I have configured. I'd like to know what it is. But the only way I'm extracting it is with a breakpoint and startup in debug mode (yes, this was my fault, but a little more helpful error message would be nice).
• Ok, everything working. Webapp redeploys most of the time, in about 15-20 seconds after making changes. Sometimes it needs a stop/start cycle to pick it up though.
• Somehow I manage to get a NullPointerException on startup when it was working before. Googling seems to indicate this is an invalid ROOT.xml, as I see a user getting reprimanded for not bothering to do validation on the XML. Sorry, but a NullPointerException is a bug, user error or not. I can't find the cause, the XML is valid and I've deleted IDEA's cache of the tomcat base to no avail.
  

• web resources read directly from the source tree, so you can edit, save, refresh without any deploying, etc.
• detects changes on a scheduled interval (I'm using 10 seconds), reloads the webapp if classes/descriptors/libs change. It reloads fast and I haven't seen it fall over on it yet.
• Very little setup required.

<plugin>

  <groupId>org.mortbay.jetty</groupId>

  <artifactId>maven-jetty6-plugin</artifactId>

  <configuration>

    <scanIntervalSeconds>10</scanIntervalSeconds>

    <contextPath>/</contextPath>

  </configuration>

</plugin>

mvn jetty6:run

Both Steve and Lars have been talking about how they think Maven repositories could be improved. Lots of good points, lots I agree with, lots I'd have already done if there were more hours in the day :)

I'm sure there are plenty of folks out there that have thoughts of their own on this topic. So, if that's you, how can you help?

There are a few different categories of people that can help in their own ways.

1. Open source library and framework developers and release managers - Even if you don't use Maven yourself, chances are your users do. Treat that support as importantly as any other feature request. You can submit your own Maven metadata, and even have your releases automatically published to the Maven repository system. Here are the instructions for both. It's also important to consider how your choice of dependencies affects your users. Putting all your functionality into one library is a distribution convenience, but can cause confusion for users about what the dependencies really are if they only use a part. Give them a choice. Produce libraries with discrete, independant functionality and clear dependencies (including clear version requirements), and produce the convenient bundled archive with the lot.
   
2. Developers interested in working on an application - participate in the Maven Repository Manager. We are building an application that does all the fun things like reporting on bad data, converting Maven 1.x repositories, and doing searches and browsing of the repository. You can comment on the brief feature and design notes. You can help us fix or implement issues in the repository manager, or in Maven itself. Vote for the ones important to you. Or discuss your ideas on dev@maven.apache.org with the other developers.
   
3. Users of the Maven repository - Help us fix metadata with usability problems. Even better, get the project you are using to buy into the problem and help fix it.
   

It's been a fruitful hour or so realising some things about how IntelliJ works and how the debugger behaves differently to running the code outright.

Lesson 1: The appearance (or lack) of <Click to see difference> in Junit results is not random. It only appears when you are comparing Strings in assertEquals - for objects, you get the traditional "expected <....> but was <....>". So if your String methods are consistent with equals(), then you can put a .toString() in your assertEquals to get this to appear. Or, a better solution:

Lesson 2: You can copy the text between <...> in the junit output to the clipboard, then select the second set, right click and say "Compare with clipboard". This gives you effectively the above without modifying your assertion questionably.

Lesson 3: The debugger changes the way your code executes, but only if you step through. Specifically, if toString() has side effects.

This one bears more explaining. My tests failed under Maven. My tests failed when run from IntelliJ. My tests failed when I run through the IntelliJ debugger without breaks. But as soon as I set a breakpoint and then continue execution, test succeeds. I'm trying to figure out why equals() is broken (its failing, but toString() produces identical results and displays all the elements), but stepping through is not going to help.

Why would it be different when stepping into the debugger? Because some of the variables were lazily initialised, and this was done in toString() via a call to a getter, but not equals() which was just using the variable reference. The debugger, when stepping, calls toString() on methods. This probably also highlights why its not a hot idea for toString() to have side effects :)

Things I should have known already, but weren't immediately obvious at the time.

Mergere has an opportunity for a developer in our product development team, developing our software lifecycle management system, based on Apache Maven and Continuum.

The role includes responsibility for all aspects of a project, including helping to identify requirements, designing and documenting specifications, implementing and testing solutions, and managing time lines for the successful and timely delivery of the projects.

Mergere offers a flexible, distributed work environment. We follow the best practices of Community-oriented Realtime Engineering (CoRE) to increase project visibility and lower communication overheads.

Resumes should be sent to brett *at* mergere *dot* com. OpenDocument, PDF or plain text formatted are preferred.

Specific Responsibilities:

* Design and implementation of Mergere products

* Adhere to the product plans throughout project life cycle

* Identify possible project risks and implement corrective action to ensure project success

* Work with Mergere sales, marketing, architects, and quality assurance, to ensure successful project completion

* Work with Mergere community-oriented engineering team that participate in relevant open source projects

* Work with Mergere client technical services to ensure products meet the requirements of clients

* Participate in ongoing design and process improvements related to planning, development, and delivery of Mergere solutions

* Participate in improving Mergere business practices and processes

Required Skills:

* 4+ years experience in software development

* Strong Java programming and design skills

* Knowledge of different development methodologies

* Details and results oriented

* Efficient and effective when working independently, with cross-functional teams.

* Excellent communication (verbal, written and presentation) and interpersonal skills

* Proven technical and organizational skills

* Thrive on working in a fast-paced environment

* Effective problem solver

* A driven and positive personality

* Able and willing to learn Mergere product offerings

Beneficial Skills:

* Experience in using Apache Maven and related tools

* Active involvement with a Java Open Source community

* Able and willing to travel 4-6 weeks per year

Looks like there a few fun gatherings happening at JavaOne next week. I'm a first-timer, so I'm looking forward to it.

<plug>
I'll be at the free "beer JUG" on the Tuesday night at 6pm, where the Maven devs will be talking about Maven 2.0 and Continuum, and the ActiveMQ folks will be talking about their latest development. There's also appetizers, an open beer and wine bar, and free t-shirts.
</plug>

I thought I'd get the word out - hope to see you there, and during the conference drop by the Mergere booth and say hi!

(apologies to javablogs readers who see this twice... I've filed it! http://jira.atlassian.com/browse/BLOG-156)

**Seating is limited -- Register Now to Attend**

WHAT: Open Source "BEER JUG" Event!
WHEN: 6.28.05 - Tuesday Night 6:00pm after JavaOne
WHERE: Sheraton Palace Hotel (2 Blocks North of Moscone)

This free event includes appetizers, open beer and wine bar, and t-shirts for all attendees!

Learn about the newest versions of ActiveMQ and Maven, including: new features, component changes, core capabilities, and best practices. Get the scoop first-hand from the projects' primary contributors, and speak with other developers who are implementing these Open Source technologies into business solutions. Presenters include:

Jason van Zyl, Project Chair at Maven and Continuum
James Strachan, Project Lead at ActiveMQ
Winston Damarillo, CEO, Simula Labs and Founder, Gluecode Software

http://www.simulalabs.com/JUGevent-register.php

I've been given the opportunity to present on Maven 2.0 and Continuum at the Sydney Java Users Group tonight at 6pm.

I'd encourage people in Sydney to get along to the group if they can. It's free, and they usually have some great speakers there, me being the exception :)

All the details are at:
http://sydneyjug.dev.java.net/

The Maven team have released a set of Ant tasks for performing dependency management within your Ant scripts. This includes:

• Transitive dependencies
• Snapshot handling
• Scope tracking
• Deployment using SCP, SFTP, and file protocols

The tasks are based on the Maven 2.0 artifact handling code, so behave identically. The version included is slightly newer, from the upcoming alpha-2 release.

This gives you access to the more than 8500 artifacts available in the Maven central repository, and the ability to utilise the published artifacts from other Maven 1.0 or Maven 2.0 built applications.

An example use:

<artifact:dependencies pathId="dependency.classpath">
<dependency groupId="org.apache.maven.wagon" artifactId="wagon-provider-test" version="1.0-alpha-2"/>
</artifact:dependencies>


Download: http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-artifact-ant-2.0-alpha-1-dep.jar
User's guide: http://maven.apache.org/maven2/ant-tasks.html

This arrived today (right now it can be viewed here: http://javablogs.com/ViewHotBlogEntries.action)

The blog is http://localhost:8080/. At the end of the day, all it means is that you lose the real "hot" entries because you can't get to this blog anyway :)
The question is, is this an exploit of a bug in javablogs or has it been deliberately stacked by requesting it continually?

After a long break, the Sydney JUG meeting was on again last night and had the privilege of seeing Mike Cannon-Brookes deliver another talk on SiteMesh (he originally spoke about it in the context of java.blogs at SJUG last July.

I gave a thought to investigating it at the time - and got as far as downloading 1.5 and reading the docs (the ones that weren't marked TODO at least!), but didn't see the advantages over Tiles.

However, it was good to see it given more attention last night and got to learn about some more advanced features like DecoratorMappers and inline decorators.

It is more obvious now that SiteMesh might be the better solution for us, even in a Struts environment.

The advantages I see in SiteMesh over Tiles are:
- a lot less configuration by applying layouts to a bunch of pages by a pattern, rather than having to cut and paste definitions for each page in tiles (even though they extend a common base, you still need 4 lines per page per skin)
- an easy way to skin by using a ParameterDecoratorMapper to pick a skin (this could easily be replaced with some other technique - we use the domain name of the request). Tiles could do this but I found it quite slow at the time because of the subrequest to select the template JSP, and have just dealt with copying all the defs for each skin up until now.
- the fact that it splits both the template/decorator and the page/fragment content as a complete HTML file that you can style is a big win when you work with a separate team of HTML designers that don't want to deal with JSP.
- I think it may be faster - I'll be taking this for a spin today and will report back :)

Good luck at the TSS Symposium Mike!

I finally got around to picking up a copy of JUnit in Action today. I recently read the sample chapters from TSS and it's great reading. I thought I knew my way around writing tests pretty well, but I've learned some good ideas on mock objects from this.

It reads really easily, very "step-by-step", and it should be good for evangelizing unit tests to fellow team members.

Nice job Vincent and Ted!

As any product approaches version "10", there seems to be an aversion to using a version. Red Hat Linux stopped at 9 and merged with Fedora. Mac OS decided roman numerals were the go, Microsoft started throwing all sorts of years, letters, and marketing symbols behind the versions of their software.

Sun's application server isn't really that close to 10 (currently at 7 and I'm not sure there were really 6 versions before that), but it seems that the history of rebranding it is going to continue. Sun ONE as a brand is probably not that old itself, but it seems that the J2EE 1.4 RI will now equal Sun's application server (I'm not sure they were that much different before) and be called the Java System Application Server.

This move actually makes a lot of sense to me, but I wish they'd make up their minds!

I've actually been trying out S1AS7 recently as we are going to have to start doing some work with a JMS queue and don't currently own an application server. I've had some issues configuring it and loading any apps that use log4j, but other than that it was pretty simple.

It's been a long time coming (I promised myself this two years ago!), but I finally took the plunge and started writing some Cactus test cases.

I had it in my head that it was going to require a lot of work, but thanks to a lot of recent usability enhancements by the Cactus team, and a well-written Maven plugin, setting up was a breeze.

Once I had a simple test case in place, I just had to add 4 or 5 properties to my project.properties file, and run maven cactus to test the case against Tomcat 4.1 and Resin 2.1. Piece of cake!

We use webapp deployment descriptors in Tomcat 4.1 (and in resin via an xml entity included in resin.conf) to configure all of the JNDI resources which were necessary when moving onto a more complicated test case. I originally fudged around with trying to keep one copy of these but decided in the end that a customised server.xml with them included was the best solution for now.

Making the cactus plugin aware of these files might be one of my other side projects. There have been a few small things that can still be improved (which I promptly entered into bugzilla :) but overall it's great.

I also have to say that the documentation is quite good too - something usually missing in open source projects - which made a huge difference.

For those that couldn't be in Sydney to see Mike Cannon-Brookes speak at SJUG a few months back, this tech talk on TSS has a lot of similar elements in there. Interesting reading/listening depending on your preference for video or transcript.

I've promised myself I'll give WebWork2 a try "real soon now", but regardless I think we are probably tied to Struts and Tiles here due to the large amount of infrastructure and code invested into it by now.

Not that there is anything wrong with Struts! There certainly seems to be a lot of favourable comments for WebWork over Struts, but I still find I can churn new actions out nice and quickly, and don't tend to get too bogged down in repetitive form beans by reusing one across a sub-application and using validator to define all the rules on the input. Still, I can see where it can be cleaner, and maybe WebWork is the way to go.

Has anyone had a negative experience with WebWork2? That's something I'm yet to hear.

I'm impressed.

I haven't checked out JMeter for some time, although even when I did use it briefly about August last year for a large project's load testing requirements, it did the job.

The more recent versions have added a little polish, but now come with an ant task for automating the load test run and the server-side capacilities seem a lot clearer although I still haven't given them a try.

I think I'll be using it more often from now on, as automating such tests is a necessity, and its great to be able to test several components of your app in one platform (full web requests vs just the SQL you are running via the JDBC tests).

Add in a little functional testing by checking so pre and post conditions and you've got a reasonable solution. Considering we've used a commercial product with which I no longer have any confidence in its consistency or results, I'm really impressed with JMeter.

One thing though, the "add component" interface and the open/save model needs a serious redesign. Probably my only complaint a year ago and it is still there. File open does an import, and save does a subtree export. This is fine, but really it needs a workspace open/save option that is the default, and adding bits into the work space under separate test plans needs to be easier. I think it is possible under the current interface, but its certainly unclear. But this is only a minor complaint, because once it is setup you rarely worry about it.

I can't believe I'm still discovering neat new things in IntelliJ. Ok, so that's partly to do with not having done a lot of development since I got it, which is unfortunate.
Some of the things I've been discovering today are:

• The stats in the console window for Junit tests


• those inheritance annotations in the left nav that helps you navigate your hierachy


• showing the top of a scope just above the top of the window when at the bottom and it has scrolled off


• the annotation of comments as thin gray bars in the right nav - good for locating big chunks of commented out code :)

I've been playing with DBUnit recently, and it is pretty much everything I was looking for.
I'm surprised I hadn't heard about this earlier among all the other *Units. dIon gave a neat little demo of it at SJUG last month, including the always important availability of a Maven plugin that he wrote.
Goodbye 2000 line test database setup code! :) Now I just navigate the site generating test data in real time on a clean database, and then run maven dbunit to generate the XML. To update, put it back in the original state with dbunit:import-dataset then repeat, or just edit the XML by hand. Very nice.

I downloaded the latest IntelliJ Aurora build yesterday. It seems more stable (no more syntax errors popping up warning dialogs!), and added some new features such as the ability to indent XML files with 2 spaces while Java with 4.

Being a new IntelliJ user, I must admit to not having done a lot of research about what was available for it plugin-wise. I've now found the community site and the early access site. A few of the plugins are quite handy, but I was much more impressed by IntelliJ Aurora, the current beta version. Not only is it running rather smoothly on my laptop (128mb RAM rarely cuts it for an IDE these days), but the look and feel is now much more polished, and the featureset has grown quite a bit. I'm especially pleased to see line wrapping added to the reformatting commands, and the new project enhancements are exactly what I was looking for.
Probably the only disappointment is that the project importing from v3 projects doesn't work correctly, so I can't use Maven to generate the project files. I think it just isn't creating the new IML files. To fix this, I've started working on upgrading the Maven plugin to handle v4 projects directly.
Overall - very happy with it. Seems stable even for a beta other than the above bug, but we'll see how it goes over time.