Maven Blogs @ Sonatype

Maven: The Definitive Guide Hits the Virtual Shelves at Amazon!

Mon, 06 Oct 2008 17:26:41 GMT

In case you missed it, Maven: The Definitive Guide is now available! This book is great for understanding Maven from the ground up, from its explanation of the Maven POM to in-depth guides to building project websites or creating your own project assembly. It's an invaluable reference and introduction, and I'm not just saying that because I helped write it! If you've ever had questions about how best to configure Maven for your project's build, you should consider picking up a copy today.

Order Your Copy of Maven: The Definitive Guide

Mon, 06 Oct 2008 14:33:00 GMT

We've had a lot of support for our online, free version of Maven: The Definitive Guide, and I think that we've created a good introduction and reference for both new and veteran Maven users. In my opinion, we're about half way to the point of creating a lasting reference for the next decade. Personally, I'd like to see: more examples in the intro portion of the book, and more details in the reference part of the book. I'd like to see a whole section devoted to the internals of Maven and the process of developing Maven. Additionally, I think the community deserves a closer look at some of the unepxected uses of Maven. I could easily see this book growing another 500 pages or being split into two, and I'd also like to see us supplement this reference with other books in the near future.

If you use our free, online reference, I'm going to take the publishing of the print book as my opportunity to suggest that you purchase a copy. This isn't in the spirit of a public radio drive, nor am I trying to position the book as some sort of charity work. I'm asking you to purchase the book (for a little more than $20) as a statement to publishers that Maven matters. I'm convinced it does, and surprising our publisher with some strong numbers will help the community by convincing other publishers that Maven matters.

I'm also making the case because I'm convinced that the world needs more free books in the style of the Subversion book. The Subversion book had strong sales despite the fact that it was freely available online. Maven is just as pervasive as Subversion within the subcategory of Java. I am convinced that free books make more sense for authors, publishers, and consumers, and I have made it something of a personal goal to convince authors to write free. If you like reading free, then help us write more free.

If you like what you see, buy it.

Hudson, Meet JavaServiceWrapper

Wed, 01 Oct 2008 16:37:59 GMT

Here at Sonatype, we're working on a continuous integration build farm for testing the various open source projects we're involved with, including Nexus, m2eclipse, and of course Apache Maven. Yesterday, as part of this effort, I took a minute to repurpose some of the work we've done with JavaServiceWrapper for Nexus. By combining some of the techniques found in the Nexus build with the Hudson WAR file, I was able to create a bundle that wraps Hudson in JSW startup scripts and configuration. Obviously, this isn't a momentous achievement, but it is very convenient for anyone who wants to run a very simple Hudson instance, and have that instance recover automatically after a machine restart. You can download the bundle at http://repository.so...

Good Review of Nexus / Comparison to Artifactory

Sat, 27 Sep 2008 18:06:00 GMT

James Williams blogged a quick comparison of Artifactory to Nexus. He leans toward Nexus, and his post provides a good feature comparison between the two repository managers. Competition is great, and Sonatype really does see the presence of other strong repository managers as a sign of a healthy community. We believe that Nexus is the best option out there, and it is nice to see people notice all the hard work this team has put into making a solid repository manager.

Read his evaluation and comparison here: http://cfossguy.blogspot.com/2008/09/my-artifactory-versus-nexus-experience.html

Apache Maven 2.1.0-M1 Released!

Fri, 19 Sep 2008 17:16:49 GMT

Yesterday evening, the Apache Maven project announced the first milestone release of the 2.1.0 (2.1.0-M1 is the actual version name). I highly recommend downloading your copy today, from the Apache Maven website. This release is the culmination of development work going back beyond last May, and a release process that produced its first release candidate (RC) build for testing on July 18, two months to the day before I was finally able to push the 2.1.0-M1 binaries out to the download page, and announce the release publicly. In that time, the code has undergone some important revision to make it faster and more stable. Looking back, there are some interesting statistics associated with this release, mainly because they highlight a marked difference between the two most recent Maven releases - 2.1.0-M1 and 2.0.9 - and all those that came before. Here are a few of those statistics. When we started the release process on July 18, we had 41 issues assigned to that Fix-For version in JIRA; when I sent out the ...

Maven does not dictate structure. Maven promotes it!

Tue, 09 Sep 2008 04:49:43 GMT

This is my response a comment on TSS about the structure in Maven projects. We recommend a structure we don't dictate one ...

The directory structure used by a Maven project has never been fixed. There are defaults, yes, but they can all be overridden. I have had many clients over the years that have had existing structures that needed to be preserved for various policy reasons, or projects that had lives spanning many branches into the past where changing the directory structure would have made merging a nightmare. The defaults are easy to change at a project, or organizational level. That the structure is fixed in Maven is a myth.

Many organizations choose to start new projects using the standard structure and/or migrate to the standard where possible as standard Maven documentation, training, and idioms then apply. Maven's defaults were chosen to allow for growth but are, in fact, as arbitrary as the defaults in any other system. The advantage is that our defaults are used by a few hundred thousand people and there are undeniable benefits in a collective understanding of a project structure. I'm not trying to say this alone mitigates any of the implementation defects in Maven (of which no one is more acutely aware then myself) or that a default structure alone is a good reason to use Maven. But it lends itself toward building a level of social capital (a measure of how well groups can work together) because there is some common structure from which to work from and communicate. Maven does not dictate a structure, contrary to popular opinion, but we definitely promote one.

You have used your same Ant build files since 2002 which works for you. If you deliver using this tool set who can argue with that. But I have seen the argument many times over and it goes something like "my structure is pretty simple because I stick to the basics and it does what I need." This is perfectly fine in isolated cases but try to onboard new developers, find resources for your build and release team, attract developers to your open source project, reach a standard in your department, or your organization, integrate with disparate parts of your organization, incorporate third party libraries, integrate open source and you will rapidly find N pivot points against which you must learn something different to make the overall system work. This is simply an untenable proposition for a community of people trying to together efficiently.

Maven has many flaws, but it is very usable by a large number of groups. Maven is also not static. Not many people know that .NET and C toolchains have been created for Maven, or that with a few new implementations of internal components that Maven can build OSGi components directly from manifest information (look Mom, no POM!), or that you can write Maven plugins in Groovy, Ruby, or Ant script. Many of these things are unknown because the Maven project has admittedly been terrible at documenting these attributes and features. This is a failure at the Maven community level that we are trying address.

Ultimately it's your decision as a user. If Maven doesn't work for you don't use it. But Maven was not meant to cater to personal biases, it was meant to work for groups and as such compromises need to be made in order to use Maven effectively. Maven is not for anyone in particular, it was intended for a large number of users who have made a conscious decision to work in more or less in the same way to achieve results in what they are making, not in how they make it.

Atlassian, you should try Nexus

Mon, 08 Sep 2008 15:51:02 GMT

I was researching an indexing bug we've been having with Confluence when I came across this FAQ entry:

Maven complains it is "Unable to download the artifact from any repository."
We use Maven project's Archiva Maven Proxy to act as our Maven repository. Sometime, however, artifact downloads fail because of Archiva's instabilities. If you run into messages like this, sometimes a second attempt will succeed in dowbloading the artifact. If it doesn't work after a few times, then the artifact may be truly missing. You can search our Archiva to confirm this.

Atlassian, maybe you should try Nexus instead. See what our users are saying:

The Maven version shuffle

Fri, 05 Sep 2008 21:12:25 GMT

The Maven project is again pretty active with lots of efforts underway to improve artifact resolution, inheritance and interpolation. The changes have led to a reshuffling of the Maven versions.

Maven users rebel against MyEclipse

Fri, 05 Sep 2008 14:54:41 GMT

Sometimes Maven takes heat for being "opinionated" and wanting you to do things a certain way. Even though it is usually configurable, it's normally easier to go with the flow.

It seems that the "Maven Way" is catching on, as masses of Maven users rebel against MyEclipse's attempt at using M2Eclipse as the basis for their Maven integration. In the beginning it sounded like a good thing..