Goal

The goal is to develop a strategy to migrate all existing Glast projects from Maven1 to Maven2 is as unobtrusive a way as possible. The reasons to switch to maven2 are

• Support for maven1 is fading away
• Netbeans6, due to be released before end-of-year, has support for maven2 built-in (but not maven1)
• Maven2 has many improvements, including simpler dependency management

We will not be able to move all projects over-night, so we need a strategy for which order to move projects, and how projects which have moved can continue to co-exist with projects which have not moved. We will need to provide clear instructions to developers to allow them to move their projects.

Requirements

• We need to maintain the features we have in maven1, including
  • Ability to check projects out and build them in Netbeans
  • Ability to deploy projects using the built-in netbeans tomcat server (Netbeans deploy)
  • Ability to use in-place deploy so that JSP pages can be edited and the effects seen immediately without the need to redeploy
  • Ability to deploy projects from netbeans to the development (tomcat03) and production (tomcat*) tomcat servers.
• Ability for cruise-control to build projects. This should not be too hard since cruise-control has support for maven2
• Ability to deploy snapshots and releases to a central Glast maven2 repository
• Ability to deploy sites to http://glast-ground.slac.stanford.edu/docs

Possible additional features

• Right now there is a lot of boiler-plate code which has to be copied into each new Glast project. For freehep Mark set things up so their was a master project which other projects inherited from so that we didn't have to repeat the same information in each sub-project. A maven "archetype" for Glast projects might also be a good way to achieve this.
• Now that we have 12 tomcat servers it is difficult to remember which server each application should be deploy to. It would be nice to be able to do something like mvn -Dmode=prod tomcat:deploy and have the application automatically deploy to the correct location. This would require some type of custom maven plugin which would talk to the glastgen database.