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.
- 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.
- 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!
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.
- 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.
- 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.
- 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.
