Monday, April 25, 2005

m2 for Maven users

I have been working through trying to get m2 to work with my latest projects because I do want to use Maven and I think it might be simpler for others to pick up than Maven1. But there has been plenty of frustration and confusion along the way.

There is still no DTD or XSD for any of the config files, which drives me batty. But, at least this time, you'll get a somewhat helpful error message when you screw up. Something along the lines of 'we wanted to find a tag here, but we found this text instead'. In general, that's the only improvement I've seen in error messages. You still have to hunt and peck if it's anything else that's gone wrong.

There's this concept of 'scope' for dependencies. I'll admit it's a really good idea. I don't need junit files or my mock objects jar in my deployed war. But either I don't quite get it, or they don't work as they should. First of all, out of the four scopes, one of them is called 'build' and one is called 'compile'. I've yet to figure out what the difference is there. I guess it doesn't matter because I soon found out that if I set my dependency scope to 'build', none of my dependencies were included in the compile classpath. I had to set them all to compile for it to, well, compile. And even that was a trick. For every dependency it sees, it not only tries to fetch the artifact, but an associated .pom file. That's great if you've got a common thing that resides in the central repository. It's not so great for things like the JavaMail jar (which cannot be legally hosted on ibiblio). For that and a few others, I had to put together my own pom and put it in the appropriate repository directory. Yeesh!

They've changed the repository layout as well. I understand what they're trying to do, but I don't like it. I just end up having to navigate through a lot more directories. Instead of groupId/jars, the pattern is groupId/artifactId/version/. Like I said, I get it, but I don't like it yet.

They have made it easier for newbies to understand, "what do I type to create a jar", etc. Rather than needing to remember a plugin and/or goal name, you just need to know which "phase" of the project you want to execute. I believe there are five phases, and if you execute one, you execute all of it's predecessors. To name a few from memory, there's compile, test, and package. Just type 'm2 package' and your jar, war, whatever will be compiled, tested, and packaged into your desired archive format. You can also still access plugins and goals directly, but they have to be configured in your pom.xml. I haven't gone there yet, so I can't speak to how much pain that will be.

Other low impact, but noticeable changes:
- project.xml has been replaced with pom.xml
- I'm pretty sure it's impossible to set your 'home' to anything other than "user.home/.m2"
- no more build.properties, project.properties, etc. Instead, there is a settings.xml file that resides in user.home/.m2 directory. So far, mine looks something like this:

<settings>
<profiles>
<profile>
<active>true</active>
<localRepository>/develop/repository</localRepository>
</profile>
</profiles>
</settings>

That's all I have for now. I am using it for two very simple projects that only produce .jar files. For this type of project, the only real pain involved is getting all the files available in the repository.

I have a couple of web projects that are still using Ant. I'm sure the process there will not fit into the m2 "box". However, I noticed that they released tech preview 2 today, which can hook into Ant tasks. Maybe I'll have to see what that's about next.

0 Comments:

Post a Comment

<< Home