Sonatype Blog

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

Nexus

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 announcement to the mailing lists last night, we had closed 70 issues. That’s 29 issues that came up during the release-testing process, and were debugged, tested, and resolved, leaving the code more stable than it had been previously. Since July 18, I’ve personally pushed out 17 release candidates, with an average of 1.71 (we’ll call it 2) issues fixed per RC, and about 3.5 days in between RCs on average.

We’re all very excited about this release, and I’m very confident that this will be the most stable version of Maven you’ve used to date. Please give it a shot; you’ll be sorry if you don’t!

Now, for anyone interested in why this release is called ‘2.1.0-M1′ and not ‘2.0.10′, please read below the fold:

The release of version 2.1.0-M1 marks an important shift in the development strategy here at Maven. Not only is this the second release with an extensive release-testing phase beforehand - which is vastly improving the stability of our releases, for obvious reasons - but it’s also the first release of Maven to (formally) move beyond the tight constraints of the 2.0.x version series. Previously, Maven was locked into a sort of dual development mode, where only the lowest-risk bugfixes were introduced to the 2.0.x series, and almost all new development was happening on what we were calling the 2.1 or trunk code. With this release, our development strategy has changed. Now, Maven’s development strategy centers on three main goals: regression fixes for the 2.0.x code; low-risk, formally planned features and implementation improvements for the 2.1, 2.2, ..2.x code; and more aggressive subsystem redesign and reimplementation efforts going on in the 3.x code.

There’s a danger of getting into a confusing version-soup scenario here, but I’d like to briefly explain the purpose of each development effort. First, with the 2.0.x version series, we’re planning to do only regression fixes and put it into end-of-life mode soon. We’re starting to run into issues where fixing one regression causes another, and the only good way out involves taking on quite a bit of extra implementation risk…and possibly jeopardizing what stability we have. This is actually why the most recent release is 2.1.0-M1, not 2.0.10 (which is what it started out to be). During the course of fixing issues for the release, we began to recognize the need for some relatively large, risky changes in order to avoid the aforementioned contradictory regression problem. Yet we realized that these code fixes were simply too aggressive for a 2.0.x release, and carried with them more risk for instability (because of the quantity of new code) than we were willing to introduce for 2.0.10.

For this purpose, we have decided to rename the old 2.1/trunk code to 3.x, to make room for a new, intermediary version series. At this point, the 3.x code had already undergone some really significant changes related to embedding, project building, plugin loading, and more. Therefore, these intermediary versions were meant to provide stepping stones for the users, between 2.0.x and 3.x, where new features and reimplementations could be introduced gradually. As part of this effort, we’re creating release plans for each minor version release, which will be backed up by design documents and JIRA issues (for tracking in release notes). Each major introduction will constitute a milestone in the release cycle, with the run-up to the final release being another of the release-testing processes that we’ve just been through.

For more information on the release plans we’re currently working on, see the Maven 2.x page on Codehaus Confluence.

Reading through the archives of the Maven mailing lists, you’ll no doubt come across mention of the by-now-mythical Maven 2.1; these discussions pertain to what is now Maven 3.x, which as I speak is shoring up nicely for a push to its own first milestone release. This code forms the basis of the IDE integration you’re probably using, possibly through Eclipse, via the m2eclipse project or Netbeans, via the Mevenide project. I’m sure this version switch will create a certain amount of confusion, but I’m also sure that all will become clear when the releases start rolling out.

It’s an exciting time here at Apache Maven. Keep an eye on the project, and I think you’ll see some unprecedented progress over the next few months.

Maven, News

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.

Maven

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.

So if it doesn’t work, just try it again. Kinda reminds me of this skit.

Update: Apparently this is still an ongoing issue.

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

“the maven repository that’s a dream to install and use” “Sonatype new nexus maven2 repo manager is looking very good” “Finally, a Maven Repository Manager that works! “Sonatype’s Nexus makes local Maven repositories easy” “get a proxy in place. Have been using sonatype nexus and it does a very good job” “Considering Nexus instead of Archiva for a Maven Repo. Nexus doesn’t need a db. (It’s lucene + filesystem)” “man nexus needs to be installed by default for anyone using maven”

Nexus

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, using the best plugin as a base to provide integration to more users. The trouble is that this implementation changed some core functionality and only supports new projects. Worse is that existing M2e users get tripped up by the incompatibility with the Maven4Eclipse implementation.

A key tenet of Maven is that all Maven based projects behave the same regardless of where they are. Once you know Maven, you should be able to work with any Maven project in seconds. It seems that MyEclipse broke this tenet and the users aren’t too happy about it.

A more appropriate approach would be to work with M2e to add features instead of effectively forking it.

You can read more about it on Jason’s blog.

Maven

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.

For a long time, the next big version was going to be 2.1. The trouble is that we were left with maintaining 2.0.x and adding features and possible incompatibilities in what should be a bug fix only branch.

The decision was made to move the trunk from 2.1 to 3.0 since it has a significant amount of improvements across the board.

In the meantime, we were working on 2.0.10, and to fix some regressions required fairly significant rework to core functionality. So much rework that we started to wonder if 2.0.x was the appropriate place for such significant changes. Since the trunk was moved up to 3.0, this gave us a bit more leeway in the 2.x line. So… the intended 2.0.10 release was renamed to 2.1.0-M1 and 2 additional Milestone releases defined.

The pure bug fixes that were intended for 2.0.10 will be ported back from the now 2.1.0-M1 release and released as 2.0.10. After that, the 2.0.x line will most likely start to close down to only critical bug fixes.

Confused yet?

One more time: 2.1 became 3.0 2.0.10 became 2.1.0-M1 2.0.10 will be created by backporting bugs from 2.1.0-M1

Read these threads to get up to speed: Maven 2.1.0 GA Plan [vote] Version for pending release [PROPOSAL] Going forward with Maven 2.x releases

Some good news: a 3.0 alpha-1 release should be occurring very soon. It will be without the artifact resolution changes AKA Mercury, but will have the new interpolation and inheritance code. This release will be intended to start identifying incompatibilities between 2.x and 3.0 so they can be handled and to give us a platform to start stabilizing.

Maven

Eugene and I have been watching with amazement how vocal MyEclipse users have been about their great disappointment with Genuitec’s attempt at Maven integration, which amounts to complete mutilation of m2eclipse and the way Maven itself works. Genuitec decided to work in their standard fashion, which is unfortunately not a very collaborative mode of operation, and it’s apparent that MyEclipse customers are not happy.

MyEclipse Breaks Maven

Maven has a very opinionated way of doing things, there is a very strong structure that is encouraged and users have come to like the convention over configuration approach. I warned Wayne Parrot from Genuitec that changing the way Maven worked by default, or at least the attempt to, would result in unhappy Maven users. None of our documentation would apply, users could not use conventional modes of support like the Maven users lists, or the m2eclipse users lists, and they couldn’t benefit from standard books, or the Maven website. I really wasn’t very pleased with some of the initial reactions but it was this quote that drove me to write something about the unequivocally abysmal Maven4MyEclipse integration:

I was using maven4myeclipse because I was following a book on maven. Until I reached a chapter on multi-module maven projects, after countless hours and then days trying to get the example chapter to work in maven4myeclipse I went online seeing if anyone else encountered similar problems. Well I’ve saw on google that someone in the myeclipse forums actually “removed maven4myeclipse” (http://www.myeclipseide.com/PNphpBB2-viewtopic-t-21172-highlight-m2eclipse.html) and instead installed m2eclipse. Curious I followed those same steps and managed to install m2eclipse without any obvious problems. I was surprised to see that not only did m2eclipse have everything that maven4eclipse had but it seemed much, much, much more capable of doing big multi-module enterprise applications minus the frustration that maven4eclipse gave. Also m2eclipse truly followed the “convention over configuration” philosophy as I could literally drag and drop ANY pom files from any location into a m2eclipse project and have it working immediately. As opposed to maven4myeclipses non-standard propietary project meta information which is very myeclipse centric and non-portable for maven projects. I’m very disappointed in the maven4myeclipse plugin and I’ll recommend to anyone reading this post that if they want a excellent maven plugin for their projects, I would strongly recommend that they uninstall maven4myeclipse and instead install m2eclipse, I’m sure that it’ll be compatible with your existing maven projects with a minimum amount of disruption.

So how did did Genuitec get their Maven integration so wrong? I really think it is a lack of foresight in cooperating with a project that has a very strong community and doing pretty poor product planning. They obviously didn’t talk to many of their customers about Maven integration as you can see from litany I’ve collected below. I think the integration of Maven in MyEclipse can be considered a complete flop by MyEclipse users. Hopefully the next time around Genuitec will make an attempt to communicate more with the Open Source community which they are trying to leverage and do a better job of listening to their customers or they are going to be listening a continuation of the litany below.

So what can Maven4MyEclipse users do? Well, I don’t have an ideal solution because that’s up to Genuitec. As a stop gap for MyEclipse users who want to harness the full power of m2eclipse, they can use the following update site that will disable Maven4MyEclipse and replace it with stock m2eclipse.

http://m2eclipse.sonatype.org/update-maven4youreclipse/

After all, it’s your Eclipse and you can have Maven the way you expect and want it. Glad we could help. The rest is a keen lesson in learning to treat your customers like an intelligent community of users who prefer to not have their time wasted.

The Genuitec Maven Integration Litany from MyEclipse Customers

We’ve assembled some of the feedback from Genuitec’s own customers who are frustrated with the problems they are having with Maven4MyEclipse:

Maven projects are not arbitrary. They have a consistent and predictable layout. You have effectively made m2eclipse useless with your M4ME implementation. Because of this I’ll most likely not move to newer versions of MyEclipse past 6.0. (source)

I have several hundred maven projects that work just fine with m2eclipse but are useless with Maven4MyEclipse. Hopefully future versions will become compatible but until then i will not upgrade. (source)

Why do we need a custom implementation of m2eclipse? Why do we need custom implementations of anything? I don’t mind new features being added to MyEclipse, but if each new version is going to break my existing setup, it begins to become tedius. Especially if there is no easy way to disable a conflicting feature from within the Manage Your Configuration. Creating a new project and copying things into it is simply not an option. (source)

Okay, I have now been able to disable Maven4MyEclipse and have the original m2eclipse working again (on MyEclipse 6.5). (he also provides instructions how to remove Maven support from MyEclipse) (source)

The crux of the issue here is that m2Eclipse is very powerful, very flexible and works with existing projects or new ones. I can take any maven-based project and just use it. Maven4Myecilpse appears only to work for Newbies at the expense of those of us who already have Maven-based projects. So, for people like me, M4ME offers none of the value that M2E does. And as a result I’ll probably do what’s been recommended above and pry your component out in favor of putting M2E in. (source)

If you read this thread you’ll see that’s exactly the problem. One of the other posters mentioned 400 maven-based projects. Without being able to add maven support from ME to the project, he can’t function within ME 6.5. I think if you can’t fix M4ME at least make it so those of use who want to use M2E can turn off M4E. (source)

Like many others here, I find Maven4MyEclipse to be a major step BACKWARDS in functionality from the plain-old m2eclipse plugin.What in the world were you thinking to actually REMOVE from m2eclipse the standard maven project structure? Simply defies all belief! (source)

I am migrating from M2Eclipse to Mave4Eclipse my project works fine with M2Eclipse when i try build using the Mave4Eclipse i am getting this error. (source)

We currently have the Standard edition, so we cannot use maven4myeclipse, and are unable to run m2eclipse after it is installed. This is very disappointing and doesn’t seem to be in line with the pluggable / open architecture of eclipse. (source)

I appreciate all the hard work which has been put into the myeclipse maven integration but It is not yet a complete maven solution and has several features which are missing (many of which are already implemented in the m2eclipse plugin). As a paying customer I’d like to get the some of the new features of 6.5 but i cannot because I am forced to stay at 6.0.1 until the myeclipse maven integration catches up to m2eclipse. This doesn’t seem like a viable solution. (source)

I’m no great fan of Maven after it biting me severely along the way but it would at least vaguely work with the M2Eclipse plugin. Rolling back from 6.5.1, a fantastic release otherwise where a lot of bugs I was running into were fixed, and having no option to run the freely available working Maven plugin and pay for it just hurtful. (source)

We’ve bought six Standard edition licenses, but we can’t use them while MyEclipse won’t work with our existing Maven projects. Is there a download of version 6.01 for OSX available until you have removed Maven4MyEclipse from the Standard edition? (source)

I installed m2eclipse not realizing that MyEclipse 6.5 had a maven plugin. I seem to have had a conflict (both m2eclispe or Maven4MyEclipse preferences pages are getting exceptions) so I disabled the m2eclipse plugin. Even though m2eclipse is disabled, I am still getting a java.lang.NoClassDefFound error from Maven4MyEclipse preference page. I am unsure how to recover at this point — do I have to reinstall MyEclipse 6.5 and start over? Also, is there a way to disable Maven4MyEclipse? (source)

This is, quite frankly, ridiculous, but you’ve already heard that over in other threads. (But it’s sort of unfathomable how you guys didn’t anticipate that this would be a problem — integrating m2eclipse into MyEclipse in such a way that you removed functionality AND prevented users from restoring that functionality with their own local installs of m2eclipse. Did this really, really never cross the drawing board?!?) (source)

…why stomp on the namespace of the existing m2eclipse plugin? Why didn’t you create your functionality in an entirely different namespace, and make it so that users could choose whether to use it at all, and if they chose not to use it they wouldn’t have any problem installing m2eclipse right atop MyEclipse 6.5? (source)

this new feature prevents us from using 6.5 with our existing maven projects… which we would like to be able to do as used to. Downgrade ahead of us. (source)

I created a Maven project from scratch at work and checked it in to Subversion. I’m also lucky enough to be able to work from home and have access to that svn repository, and I’m flabergasted that I can’t check out that same project and work on it at a different location and have all the same functionality available to me. I can’t add Maven support to the project. I can’t figure out how to add AspectJ support. It’s a total nightmare trying to get this project working on another machine. (source)

If the magnitude of the problem isn’t completely clear from this forum thread, just for the benefit of the developer folks, I use Maven 2 for all Java projects developed for my company and others I consult for. When I discovered that the initial Maven 2 support in MyEclipseIDE prevented using existing Maven 2 projects, I had to completely uninstall MyEclipseIDE and am unable to use it at all now. So I’m a version behind, and am stuck there until this Maven support issue is resolved. So if this support issue has been resolved, then please let me know, so I can upgrade. If not, then please understand the magnitude of the problem: I cannot use MyEclipseIDE at all until this is resolved. (source)

m2eclipse