I'm not quite an expert on Maven, but would the Maven Release plugin help at all?
http://maven.apache.org/plugins/maven-release-plugin/ I haven't used the plugin, so I can't speak to how well it works, but it seems to me that should you be using a CI server to manage builds, when you reach a successful test and deploy of your app in CI, it could automatically do a 'mvn release:prepare' and 'mvn release:perform' to tag your poms with an appropriate non-SNAPSHOT version and then be able to commit to SCM. Does anyone else have experience with the Maven Release plugin to verify/discredit my assumptions? -Nick On Sat, May 22, 2010 at 12:45 PM, Rick R <[email protected]> wrote: > 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. >
