Go west young man

This is (likely) my last post to this blog. I've spent the past 2 and a 1/2 years using Maven primarily in my Java projects and my companies. Part of this I think is just growing up. When I first started using Maven I had just started work at a company who's development team consisted of some novice Java users. It of course did not help then that a lot of the software they had was written in Java. Queue some of the ugliest Ant build files I have ever seen. These people obviously had never been exposed to C/C++ and make in an academic environment... as they would have been heckled for such lack of simplicity. These Ant build scripts just wouldn't fly for me. So I found Maven. I used it to simplify the build environment, for my co-workers and myself. I encountered problems while using Maven which I solved. I watched the community slowly build up. I started a blog and shared my knowledge. It was fun.

I've progressed A LOT in the past two years. I am no longer a guy who is fresh out of college, smart but unprepared for nastiness which the enterprises of the world contain. I've honed my technique, worked on numerous projects (many more than the majority of people out of college for only a few years), and I have made honest appraisals of the things I have done. I'm at a point now where the expressivity of a tool such as Ant makes it much more viable than something like Maven. If Maven was Java, then Ant would be Python. I can do the same two things in both, but one is much easier to use (Python, duh).

Other things that have pulled me away from Maven, and more specifically Maven's ideology, are tools such as Gant (Groovy language + Ant) and scripts in Pylons (Python web framework). Being able to use the full power of a language right there in a build file, is a beautiful and powerful thing. I also would argue this is daunting for the novice. I have come full circle from Ant to Maven and back to Ant. I'm now ready to work on projects where the full responsibility is mine in making sure the build files are clean, coherent and useful. I recognize now that this is not a lot of responsibility, that the fact my previous co-workers could not handle it speaks volumes for the type of organization they were running.

Please drop a line if you have any questions about articles I've written here. You can reach me at mentalstasis. at. hotmail. com. I'm always interested in some convo with other computer professionals out there so don't hesitate. Thanks to all you readers out there, and best of luck.

-Rob O.

Concepts of Maven pt. 1

Project structure...

You should never have to change the basic Maven project structure. Believe me, I have worked with Spring 1.x/2.x, Hibernate 2.x/3.x, DWR, Struts, Web MVC (Spring), Portlets, XFire web services, etc. etc. Pretty much any J2EE or Java technology out there I have used in one of my Maven projects.

Why am I stating the above? Because the #1 thing I hear about Maven, and why some person does not use it, is that Java framework X does not work with Maven. This is erroneous. I wish people could be more honest and just state "Hey I don't know". Instead they attack the unknown. Lame. Linking back to structure, often I hear these complaints and other offer solutions that include overriding the default Maven project structure.

If you override the defaults you are destroying the simplicity of the Maven project. By setting up defaults for things in Maven, it provides users the security that they can open any Maven project and quickly understand exactly it's structure. I know that files in src/main/resources will be loaded right into the top of the class path hierarchy once compiled. So any Spring, Hibernate, logging, or other configuration files will be found here. Likewise src/test/resources will be where testing resources go, such as testing Hibernate configuration, testing logging configuration and so on. I know that when creating a web application the basic J2EE web application structure will be contained in the project, and found at src/main/webapp. So WEB-INF will be at src/main/webapp/WEB-INF. I know, enough already. I'm beating a dead horse, you all got the point... Ok just wanted to emphasize why you don't change the structure.

If you have a framework you want to work with in Maven, and can't figure it out after reading this blog and other resources out there then email me, or post a comment to this blog. Please I beg of you, Maven does not deserve a bad rap!!!

Learn it...

Maven is not so simple to just sit down and start using. I say this in direct comparison to Ant, or make. Ant is really easy to get going for a project with very little work. I would say Maven is too, but only for simple compiling and packaging. Get into testing and know things get a little tougher. There are a lot of options, a lot of plug-ins. I recommend two things.

1. First read this article off of the Maven site. It wasn't always there, and the first time I read it a lot of things clicked in my head. It may not really make full sense until you use Maven for a bit. It talks of the build life cycle, which is the backbone of Maven.
2. Get the free book "Better Builds with Maven". A company called Mergere put this out. It is really good. Here is a link, if it is dead use google!

Don't be afraid to work through the Maven site. You should spend at least 3-4 hours just investigating it before you really start up any projects. And of course read this site!

Please understand a few things...

Maven is a system. That means it is a bit complex. But... know this. You should have a super experienced maven pro at your place, who can do ALL the heavy lifting so that developers can very quickly develop. It's the same paradigm as a sys-admin setting up all the test environments so that the developer can come in and do their job.

In Maven there are a few things involved in the "sys-admin" type work.

1. First and foremost is setting up the network repositories being used by developers. This may simply be a single location on a machine, but could be multiple locations on multiple machines. It really depends on your companies circumstances. You may also want to set up a proxying software for one or more repos. This makes it so that developers only need access your local network repo(s), which can go to repos outside the network, get a dependency and cache it local. This has benefits in speeding up download time for dependencies. I highly recommend you do this if you are serious about Maven.
2. POM inheritance model. This is maybe the most powerful feature of Maven. You can specify a lot of things in a POM, Java compiler version, website location, reports to generate (JUnit health, PMD, JIRA..), how to configure Jetty to run your web application (yes type mvn jetty:run and bam you have your app running!!!). These and more can be specified in a POM, and that POM can then be added as parent to another POM. The child POM then inherits all the configuration from the parent, overriding where collisions occur. As the "sys-admin" of Maven you can configure many things so that users will never have to worry about them. Look for examples of this here, in my blog.
3. Archetypes are great. They really are pretty easy to develop once you get the hang. The problem is that there are not a lot of great archetypes available and documented. This will change eventually. To give you the idea of an archetype think of a template but more complex. An archetype allows you to generate a project using a simple 'mvn' command. This could create a XFire, Hibernate, JMS or some other type of project. By the "sys-admin" making available and documenting archetypes projects can get done quicker
   . I have personally created and used them for XFire SOAP services and Hibernate 3.x ORM projects, and you can crank them out using archetypes. If you have used Ruby on Rails think of these as generators. You can create any number of them yourself and put them in the network repo where other developers can use them.

So, if you have one person who can provide the above duties then the rest of your developers should have a pretty easy time working with Maven. These developers will still need to learn about Maven, therefore reading the f**king manual ;)