Maven 3.0 – New and Improved Formula
During all the years that I’ve been using Maven I haven’t run into any issues that were caused by a bug in the Maven core. Issues which I know of, I should add. I might just have been lucky or possibly I have run into a bug but blamed it on some plugin. However, during the last couple of weeks I’ve been running into two bugs in the Maven 2 core. They were both a kind of an edge case, but when built with Maven 3.0-alpha everything worked!
The first issue was from the mailing list, where building a multi-module project involving a SAR archive did not work when building just to the package phase. I am guessing here somewhat, but I think the problem lay in the reactor in combination with a build extension packaging (for the SAR archive).
The second case was something I ran into when building a two-level multi-module project including a Java EE 5 EAR archive, which had a lib directory specified. Also, a workaround with a ‘client’ type classifier was used to get a ejb-client jar to be placed in the lib directory (MEAR-85). When building from the EAR project or one level above, it worked just fine and the ejb-client JAR was placed in the lib directory. But when built from the top level, the lib directory specified was ignored and the ejb-client JAR was placed in the root of the EAR.
Both issues existed with Maven 2.2.1, but not with Maven 3.0-alpha-3 and 3.0-alpha-4 respectively. And now 3.0-alpha-5 is out, with an even more improved formula. Don’t let the alpha name fool you, to my experience it is the best Maven ever. If you run into some issue with Maven 2.x, be sure to try out the latest Maven 3.0-alpha – I wouldn’t be surprised if it solves your problem!
In other news
Welcome to the weekly roundup of blog posts that mention Nexus, Maven, and other projects that Sonatype developers contribute to.
Getting Agile: HOWTO: Maven + StoryTestIQ + Selenium RC “StoryTestIQ is an automated acceptance testing tool, which was originally a mashup of 2 existing open source projects, Selenium and FitNesse. StoryTestIQ is many times shortened to STIQ (pronounced “stick”) so it rolls off the tongue more easily. STIQ takes the idea of testing inside the browser a la Selenium and enables editing, tagging, and multi-table execution through a modified FitNesse underneath the covers.” By Sterling Barton, on November 23rd, 2009
Simplericity: Make your war file executable with the Jetty Console Maven plugin “A while back I made a little Maven plugin that takes a war file and makes it executable. With executable I mean that it embeds a Jetty servlet container. Running java -jar myapp.war will deploy your war with the embedded Jetty instance. This provides a very convenient distribution method for Java web applications. It lets you distribute your application as a single artifact. Your users are no longer forced to install a big and ugly app server just to run your app.” By Eirik Bjørsnøs, on November 10, 2009
Karsten’s Blog: How to register a custom Maven repository layout “Maven repositories have a defined directory layout. In the standard installation Maven comes with 2 implementations, the default layout for Maven 2 and legacy layout for Maven 1.x. The layout is configured in the repository setting either in POMs or settings.xml file.” By Karsten Thoms, on October 13, 2009
Ham and Eggs: Creating A Simple Maven Plugin “I’ve been a big admirer of Maven for a long time. For some reason I have never made a plugin of my own. Today I did it, and I have to say it was a great learning experience. I will introduce all the neat things I figured out during the development. So let the story begin.” Published on August 30, 2009
Un expresso sans sucre: Créer un packaging maven2 “Maven 2 propose d’origine les types de packaging des différents composants java / j2ee : jar, war, ejb et ear. Cependant, il faut parfois utiliser des types de packaging moins conventionnels qui nécessitent la création d’un packaging maven dédié.” By Thomas Recloux, on July 07, 2008
Nexus as Open Source Infrastructure: User Sign-Up
If you’ve ever participated in an open source community like the Apache Software Foundation or Codehaus, you’ll know that there are hundreds (sometimes thousands) of participants and interested parties for projects such as Maven, httpd, or Tomcat. Communities like these are only able to communicate because individuals can sign up for mailing lists, issues trackers, and other open source infrastructure without the manual intervention of an administrator. If you want to submit a bug to the Groovy project at Codehaus, you don’t have to send an email to someone asking permission to participate, you simply sign up for an account on the Codehaus JIRA. It just would be as agile a community if you need to wait for an administrator’s permission to participate.
It is this self-service sign-up capability that is a key feature of all scalable open-source infrastructure, and this is also one of the key features that was just released in Nexus Professional (which is also freely available for any interested open source project).
Bringing Open Source to the Enteprise
While this self-service sign-up is important for open source projects, it can also be something useful to the enterprise. Many large software development organizations have realized that the collaborative, open-source development model provides an example for internal development. If an organization can emulate the ad-hoc, merit-driven models of something like the Apache Software Foundation, they can start to gain some of the benefits of open source culture and open source community. I’ve spoken with many executives at large organizations who understand that they need to find a way to bring the “ethos” of open-source into the enterprise. One way to encourage this change is to start using the same infrastructure as open source projects: Nexus, JIRA, Subversion. Another way to bring open-source best practices into the enterprise is to allow for more ad-hoc, user-driven action. Give your developers something like Nexus, and don’t put an administrator in the way. Let them sign up for accounts using the User Account Plugin.
In this post, I provide a brief overview of user-driven sign-up feature just released with Nexus Professional 1.4.0.
A year of providing free Maven repository hosting
I was doing a little digging for some old emails recently and realized that it’s been over a year that oss.sonatype.org has been available for free Maven repository hosting of Open Source projects.
The first was plexus, naturally since Maven and Nexus are both currently built on top of plexus.
Our first real external “customer” on oss.sonatype.org was the Jetty project, followed by Appfuse and OpenSymphony.
We now have over 81 projects actively using the system to host, stage and sync their artifacts to Central. The repository is hosted on a machine at Contegix that is racked up next to the Maven Central repository, making it possible to sync new releases over hourly, not to mention that it is also extremely reliable.
If you have an Open Source project looking for a better way to stage your artifacts and promote them to Central go here to get started. We’ll even help you migrate your existing artifacts.
We also provide free Nexus Professional licenses to projects or forges that would rather run their own system. You may request a license by filling out this form: http://sonatype.com/products/nexus/professional/oss
Special Character Encoding Properties
The other week I listened to Dennis Lundberg’s presentation “Site creation with Maven” and learned something new. As most of us living outside the plain ASCII world have experienced, character encoding makes a big difference when it comes to ensuring that text remains readable. For XML files, the encoding can be defined through the XML header which makes it possible for an XML file reader to decide on the proper encoding. But for other types of files such as Java source files and properties files, the encoding has to be defined outside of the actual source file.
Even though encoding seems to be handled correctly in your environment, with your local language settings or some implicit default value, the best practice is to always explicitly define the character encoding. This will make sure that your build is portable and it will also protect you in the future in case some of your default values change. The bottom line is, just do it!
In the Maven world, you need to specify the character encoding for every plugin that processes source files or creates reports. It would have been great if this were made possible through a shared configuration element in the POM, but that would require an update to the POM model and that won’t happen until Maven 3.x. In the meantime, two special properties have been defined.
