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!
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.
Jason and I are doing a Maven tutorial at Øredev, a developer conference in Malmo, Sweden. The session is on Tuesday Nov 3 and will be based on Sonatype’s MVN-101 course, where we will explain the motivation behind Maven and go through its core concepts. The emphasis will be on the Project Object Model (POM) and underlying fundamentals such as the Maven lifecycle, plugins and goals, and its dependency management. Related development tools such as M2Eclipse will also be covered. The target audience for this session are developers who want to understand how Maven works and how to use it.
MVN-101 is a full-day course while the session at Øredev is time-limited to one afternoon, so it will be adapted to the participants’ knowledge level. As Tim blogged about in an earlier post, people new to Maven will benefit from the coverage of the fundamentals of Maven. However, if you have been using Maven for a while you will appreciate the thorough refresh and I think you most likely will learn something you did not already know about Maven.
Be sure not to miss Jason’s session on Maven 3.0 on Friday Nov 6 either! It’s going to be busy week for him as he is also speaking at a Maven meetup that I am organizing for the Swedish JUG in Stockholm on the 5th. For us Swedes, it is going to be a Maven week!
I, Anders Hammar, am a software architect and developer working for Devoteam Sweden. I strongly believe that having conventions and good tools is necessary in order to be productive, I use Maven and tools such as M2Eclipse and Nexus in my daily work. I also help our customers implement development environments based on Maven. For the Swedish market, Devoteam Sweden is working with Sonatype, providing Maven training and other services. I will blog here as a Maven fan for the community.