I've been trying to read up on best practices with Maven in a team environment where different groups are working on different but related modules. Been reading over chp7 of 'Better Builds With Maven' but still have some questions.
To keep it simple for sake of discussion... war project depends on jarA, jarA depends jarB. Three different teams are working on those three separate modules. For this current project we have not set up a continuous integration server yet. (We're still on CVS here for source control management but I know another team using CruiseControl for continuous builds so at some point we'll use that as well.) We are using Artificatory for our local internal repository. Right now since the project is still very young we're just declaring the version number as 1.0-SNAPSHOT. Ultimately all that we care about building to the dev server is the webapp (war) project. We started out for a while having the various jar projects do a 'mvn deploy' when they were ready to deploy their jars, the problem with that is how does jarB know that he's not going to break jarA who depends on jarB if he does a deploy? jarA team can be happily going along coding against a local repository version of jarB that allows him to not break. Lets say jarA doesn't do a deploy, but now a dev build of the war project needs to take place - it ends up pulling in the new jarB snapshot which causes things to break. How is that kind of thing best avoided (other than forcing down locked version numbers?) How do you make sure you can always get a good build of a dev war that is dependent on various interrelated modules? Typically we've done this the harder way and not relied on teams using mvn deploy - and instead we would require teams to tag their code with a DEV tag (since we still want to allow people to check in code that compiles but isn't DEV server ready yet.) On the server we then go through and do a cvs update from the DEV tag for all the modules and build them which makes sure we get a decent build or catch any problems. I'm guessing this is where a continuous integration build system would help? ( I assume it can do the same thing and build from a tag and build in the correct order? ) I'm just wondering what the best practice is in making sure you can 1) allow developers to always be checking in code (that compiles, but could break another person depending on it) and 2) easily get a quick dev build of the main project (war) to a server? Next probably somewhat naive question, but in regard to increasing a version number, I take the best practice is when some sub-module feels its ready for a new version number, they simply update their pom version number (remove the -SNAPSHOT) and check in their pom and possibly do a mvn deploy. Then they go back with maybe a 1.1.1-SNAPSHOT declared for their project so they can continue to work on the next release with snapshots? I take it then they just communicate with the other teams that a new version or snapshot version is ready. So to sum up what I 'think' is the way day-to-day operations run for teams 1) team works on their code with 1.0-SNAPSHOT version number 2) before checking in any code, run mvn clean install with the -U flag to get any new dependent snap shot versions 3) assuming code builds, it can be checked in 4) when happy with code as stable enough for others to use, tag it to DEV, do mvn deploy There is something still really wrong with the above though. It doesn't allow someone to ALWAYS be able to make a good dev build, but I guess that's the drawback to using snapshots. Any suggestions and articles on the best way to handle a combination of doing source control management and maven for multiple module projects would be appreciated.
