Skip to main content

Maven is good, but needs some love

Posted by fabriziogiudici on July 27, 2010 at 1:23 PM PDT

You know that I've moved to Maven more than one year ago and I don't regret. I think I would be unable to manage the number of projects I'm managing on my own without it (or at least without an effective artifact repository).

But Maven needs a proper and clean environment. Maven experts are constantly advising about that. One of the most important pieces of the environment is the artifact repository. You can create a cheap one with a plain webdav resource, or you can install a specific tool such as Nexus or Artifactory. A plain webdav resource is simpler to manage and might sound as a good solution for simpler cases, while a specific tool is more powerful but more complex to setup and administer. It's your choice: the important thing is that everything is under your control and properly managed.

Hear what's happening to me since a couple of days. Before going on, I'll recap a couple of Maven concepts. When you have a multi-repository project (unfortunately it frequently happens, as some libraries you might depend have their own repo), Maven searches for artifacts in all of them - what typically happens is that the first repo responds with an HTTP 404 - Not Found and Maven searches on until it finds what it needs. Then it stores a metadata XML file to recall where it has last found the artifact. In this way it can avoid constantly polling for things and it's faster.

Now, I have still a few remaining messy things in my projects. When I made the switch one year ago, I thought that a webdav repo was ok for my stuff and used the webdav facility at Kenai. Later I realized that Nexus was worth while, and in any case I was able to deploy most of my stuff to the free Sonatype Maven hosting. But I have still three projects relying on Kenai's webdav. I planned for moving them sooner or later, but I didn't so far because I didn't touch them for some months.

Now, a couple of days ago, Kenai started randomly responding with a small text page saying HTTP 500 - Internal Server Error instead of the HTTP 404 when you ask for a non-existing resource - but the status code is set to 200 so Maven and Nexus, that clearly aren't much smart sometimes, instead of treating this as a "not found", are accepting the resource that is served with the error. The resource, of course, is a small HTML page with the text "Internal Server Error" etc... Of course, storing this as an artifact, a POM, or a metadata XML file isn't good at all and breaks the build. In a couple of days, the error literally poisoned all my repositories, both Nexus and the one on my disk, and all my builds are broken. Now I'm compelled to fix the thing ASAP - and I'm forced to postpone my next release of blueBill, since this week will be focused on the required clean up.

Clearly, it's not entirely a Maven fault (even though that silly way of handling HTTP 500 is crying out loud); the problem originated from Kenai and a messy situation in my software factory. With Maven, you must be very precise and accurate. You can take this as an annoyance - on the other hand it's also a stimulus for setting up things properly.

I do hope that the next release of the Maven tools, anyway, will have this sort of silly bugs fixed.

Related Topics >>


Let Maven die - What we need is more love for Ivy

I've always hated Maven... I find it vastly overcomplicated and very difficult to use. It's just an ugly solution for the problems it tries to solve. I have recently tried Ivy. It is in my opinion, what Maven should have been. It's much simper and much easier to use, but it too could use some love... it slows the build process a bit too much (particularly when trying to test a bug fix in NetBeans). I think if some attention was directed at Ivy there is a lot more to gain.


Thought, Oracle has lost all love for that already? Will it survive, or be killed?

It's just a bug, for the rest

It's just a bug, for the rest Kenai is still the best forge around. Plans by Oracle are clear: it is kept and merged with Java.Net. There are no uncertainties in this area. I don't exclude that the bug that I've experienced is related to the work that is in progress to migrate the forge to Java.Net.

In all fairness

you should really change your title to something. "How a broken Kenai setup killed my Maven repositories" or "Maven can't take care of every broken infrastructure for you.."

The remaining point is that

The remaining point is that 1) for any practical purpose with Maven you need to rely on a repository and 2) if the repository is broken you can't build your stuff. With any build system that doesn't rely on repositories, or that can be tweaked in some way when things are troubled, you can still work. With Maven you have to prioritize fixing the faulty part of the infrastructure. The message that I'm trying to convey is that Maven gives many advantages, but you must be prepared to set up and manage a working infrastructure. It's a cost that you must evaluate and be willing to pay.

Did your server really

Did your server really responded with a http status 500? Or did it respond with a 200 OK but gives an error page? As far as I know Maven treats both like it should.

Good point - indeed, it's a

Good point - indeed, it's a double error from Kenai, it's saying error 500, but responding with 200. Now I'm going to fix my post.


% curl -v ""
* About to connect() to port 80 (#0)
*   Trying connected
* Connected to ( port 80 (#0)
> GET /projects/nbpwr/maven-repository/releases/org/incava/org.incava.util.diff/1.1.0/org.incava.util.diff-1.1.0.pom HTTP/1.1
> User-Agent: curl/7.16.4 (i386-apple-darwin9.0) libcurl/7.16.4 OpenSSL/0.9.7l zlib/1.2.3
> Host:
> Accept: */*
< HTTP/1.1 200 OK
< Date: Tue, 27 Jul 2010 21:07:08 GMT
< Content-Type: text/html
< Content-Length: 122
< Cache-Control: max-age=0
< Expires: Tue, 27 Jul 2010 21:07:07 GMT
< Vary: Accept-Encoding
Status: 500 Internal Server Error
Content-Type: text/html

* Connection #0 to host left intact
* Closing connection #0
<html><body><h1>500 Internal Server Error</h1></body></html>

If you don't trust your

If you don't trust your repository, set your checksumpolicy to fail or warn, so maven will complain (or fail) about it.

I know - in any case, I think

I know - in any case, I think that the point is that the repository must work. That's why I'm taking this week to get rid of the webdav stuff and publish the things at Sonatype, where it's possible, or to my instance of Nexus.