Over the last month, the NPanday developers have been doing a considerable amount of work to ship the 1.2 release, which is now available at Codeplex. There are over 50 improvements included, with the main items of note being:

• Improved type names to better distinguish .NET artifacts
• An MSI-based installer for the Visual Studio Addin and Maven plugins
• MVC project support
• Rewrite of documentation

NPanday primarily provides two capabilities: a set of Maven plugins, for constructing builds in Maven that use the .NET command-line tools; and a Visual Studio Addin that keeps a Visual Studio project in sync with the Maven POM and adds reference resolution from Maven artifact repositories. Together this allows you to use a single tool across .NET, Java or any other Maven-based projects, including the same benefits of dependency management, automated release and source control management, and so on.

NPanday has emerged as the defacto solution for those looking to build .NET projects using Maven, and it has been great to see the community growing and active over the last year, with many more users participating and submitting patches. Earlier in the year we added Lars Corneliussen as our newest committer, and he has been leading the charge to NPanday 2.0 and cleaning up some of the historical cruft in the codebase. We’re looking forward to a lot more activity in that area in the near future that will make NPanday even easier to work with in the future.

If you’re building .NET projects and are familiar with Maven, or looking for Maven-like features, I hope you’ll to check it out and let us know what you think!

Filed under: Maven, Syndicated Tagged: .net, npanday

I recently had some time to spend in Eclipse IAM, working on improving the WTP support.

Version 0.11.0 already had good support for WAR projects, including war overlays (which was a bit tricky to implement in Eclipse). Now the last builds of the coming 0.12.0 version have EAR support.

You can import your Maven EAR projects and Eclipse will recognize the Maven-generated application.xml and configure automatically the dependencies to the other WAR projects opened in the workspace, with no extra configuration from you. And from the usual WTP "Run in Server" wizard you can run the EAR project and all associated WAR files in your favorite application server.

You can install the development builds of 0.12 from http://q4e.googlecode.com/svn/trunk/updatesite-dev/ until it's released, and check the installation instructions for requirements or if you have issues. For help and feedback, we have a newsgroup at Eclipse.

Recently, TestNG produced a new release, 5.12. This release is now in the central repository, though under the version 5.12.1 (more on that below).

http://repo1.maven.org/maven2/org/testng/testng/5.12.1/

Upgrading to 5.12.1

If you’ve been using TestNG with Maven, or are familiar with the changes in TestNG 5.12, you’ll notice there is a difference in this version to previous releases. There is no longer a jdk14 and jdk15 variant of the JAR – with the JDK 1.4 javadoc-style annotations no longer supported, there is just the single TestNG JAR. This means that previous versions using ranges will not automatically upgrade, which is expected given the compatibility change.

Where you might previously have had this in your POM:

<dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>5.11</version> <classifier>jdk15</classifier> <scope>test</scope> </dependency>

You can now simply use this:

<dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>5.12.1</version> <scope>test</scope> </dependency>

No other changes should be necessary.

Guice users should be aware that TestNG now depends on Guice 2.0, and bundles the classes in the JAR. Consequently, Guice is listed as a provided dependency – I haven’t noticed this causing any conflict as long as you are using the official Guice 1.0 or 2.0 release, but this is something to look out for in the future.

Getting TestNG to Central

Some will wonder why this still took so long, given the TestNG release was about a month ago.

Firstly, the library had added a dependency on Guice, and removed a dependency on QDox. This required updates to the POM that were not present in the released bundle. As an Ant-built project, the TestNG POM needs to be maintained separately.

Secondly, Cedric very patiently obliged with several requirements to make it easier for Maven releases in future – in particular, the bundle now includes GPG signatures.

Finally, it turned out that there had been a problem in producing the original distribution, leading to a discrepancy between the Maven release and the original release. This is the reason that there is now a version 5.12.1 (which will likewise be on testng.org shortly) that corrects the content and aligns the TestNG distribution with the Maven release of the same JAR.

The upshot of all of this is that, while this required some back-and-forth to get everything right, future releases will now be much quicker to process and the potential is there for further automation.

Are you Using TestNG with Maven?

I’ve been using TestNG with Maven for some time now, finding it particularly powerful for handling functional testing with Selenium. If you’re using TestNG with Maven, what do you think of the current support?

Filed under: Maven, Syndicated, Testing Tagged: Maven, releases, Testing, testng

"When scheduling project builds in Continuum, keep development builds and nightly builds separate. Development builds should run quick and often so that broken builds are immediately flagged, while nightly builds should run everything and must deploy the generated artifacts to an accessible repository where developers and QA members can retrieve it the following day."

For example, if most of the development work happens during daytime, you can schedule your development builds to run every two or three hours (depending on how long your builds take) during the day when changes are being pushed in your source repository. You can simply configure it with "clean install" as you goals since the purpose of the development builds is to ensure that your build is not broken.

On the other hand, you can schedule your nightly builds to run at night (say every 10 in the evening). All the integration tests must be executed and builds must be deployed to your internal artifact
repository. This ensures that the development team and the QA team get all the changes from the previous day when they build the project and test the nightly builds the following day, respectively.

Make sure that your build notifications are configured so that the development team are immediately notified if the build breaks.