Stéphane Nicoll’s Thoughts Welcome Guest | Login or Register

The other day I was watching House M.D Season 5 on the tube and I found the team ring tone really interesting.

There’s this story that ring tones for the iPhone are not “free” but you can actually do whatever you want if you have GarageBand or even simply iTunes. Some websites provide really useful info (here, here and here).

All right, I got it. It’s far from being perfect, especially at the end (loop time). If you are in the US, you can get the right ring tone here though.

In a previous article, I was talking about the current naming issues in the first milestone of Maven 3.0. Hopefully, the first release candidate will have usual artifact Ids. See SPR-5385 for more details.

Good news!

I’ve been using Spring extensively for a couple of months now and I must say I really enjoy it. Since we have a RESTful web service at work, I wanted to test that latest REST integration in Spring 3.0 M1 as it was presented at Devoxx.

My first surprise was actually that it was quite hard to find this milestone release on any Maven repository so I had a look to the downloadable bundle (after all, I could use the big spring.jar file). No big spring.jar file but a bunch of jar files with weird names, like org.springframework.core.jar (wtf?).

The first entry in the 3.0 M1 changelog as announced here is

revised project layout and build system with module-based sources

Well, the new repository structure looks weird to me but it has a really nasty side effect: all artifactIds have changed (yes!). Have a look to the Maven repository view yourself.

I am a bit confused here. Either the SpringSource guys have decided to really break this in 3.0 because they wanted to harmonize it somehow (I still don’t get what it brings if you are not in the process of using OSGi) or they have no idea how Maven works. I hope it is the second case and we will be able to let them know the chaos that users will experience with existing user projects if we keep this.

The obvious first problem is that all Maven poms should accommodate the names change which is annoying but not that much. However, the transitive dependencies mechanism of Maven will not detect a version conflict of the Spring framework anymore! Say that you have an old/stable module that relies on Spring 2.0. This module uses some stable Spring API at runtime and you are actually using it in a Spring 2.5 container in the final project. If you upgrade this project to 3.0 M1, you will end up with both Spring 2.0 and Spring 3.0 M1 in your classpath! Pretty scarry… You could obviously use the optional flag in the maven dependencies but since Maven does a good job of resolving the version conflict for us, most users have not chosen this approach.

All in all, cast your vote here please!