That's the right process, and no, the process itself is not overkill but you need to decide what is the right level between better traceability and release overhead for you. Obviously your process was a lot simpler with Ant because you never/rarely tagged and released your code. If you found an issue, you always went forward, scrambling to fix an issue as quickly as possible. That's certainly agile but unpredictable and with Maven you get more. If you find an issue with a new release, you may have an option to go back to the previous release, thus giving time for your development team to come up with a new release with a proper fix included.
Typically though, you don't want to release every little change in your libs.jar separately. If your webapplication still works with an older version of the libs.jar, you stay on that version until you decide to to move the next version (which could have been released way ahead). The release process is supposed to give you better predictability - for example you can have an actual roadmap (these and these features will be implemented in these versions) with expected release dates. It all depends on your needs. If you think you never want to go back to an older released version, there's no point releasing the library jars. You could keep it all in one multi-module build but the issue there probably is that people working on signup webapplication probably don't want to build shop. You can also just keep using snapshots until one of the web projects need to release (or never release if you never need to). I assume you are using the release plugin, in which case your trunk/branch versions for any given module should be a snapshot (it's prepared for development of that version whether or not you are actively working on it). In addition to using release plugin, using versions plugin ( http://mojo.codehaus.org/versions-maven-plugin/) can greatly ease the burden of maintaining the version dependencies. You can for example eagerly update specific dependencies to latest release versions (e.g. versions:use-latest-releases<http://mojo.codehaus.org/versions-maven-plugin/use-latest-releases-mojo.html> versions:commit<http://mojo.codehaus.org/versions-maven-plugin/commit-mojo.html>) and set up a Hudson job just for that. Overall, release process can be taxing to set up for the first time but typically pays dividends later. And whenever you feel you have manual overhead, you should try automate it and minimize the time to make a new release (for example: do you need javadocs, sources, dependency reports when releasing - if not, turn them off). Kalle On Tue, Nov 10, 2009 at 9:53 AM, Eric Moore <[email protected]> wrote: > Our development team recently mavenized a couple of our web > applications. We are struggling a bit with the new development methodology. > > > > A brief description of our artifacts and our setup: > > > > We have 2 web applications: shop & signup. > > These 2 web applications are both dependant on 2 jars: content.jar & > libs.jar. > > We use IntelliJ for our IDE and Hudson for a CI/build server. > > > > Now for our ‘process’: > > > > - Suppose we add some new functionality to our libs.jar. We > increment the version, let’s say from 1.0.0 to 1.0.1. > > - Now we release libs version 1.0.1 > > - Now we update the shop & signup web apps to be dependant on libs > 1.0.1. And we release both of them > > - Now QA finds a bug in the libs. > > - Change the libs.jar pom to be 1.0-SNAPSHOT, indicating > development. > > - The developers change shop & signup poms to be dependant on libs > 1.0-SNAPSHOT > > - Develop the fix > > - Now we increment libs.jar to version 1.0.2 > > - Update shop & signup web apps to be dependant on 1.0.2. Release. > > - Another bug is found… > > - Change the libs.jar pom to be 1.0-SNAPSHOT, indicating development > > - The developers change shop & signup poms to be dependant on libs > 1.0-SNAPSHOT > > - Develop the fix… > > - And so on > > > > Now for the question: For a simple setup like this, is Maven overkill? > > > > Our development process was quite a bit simpler when we were using ANT and > didn’t worry about the versions. > > > > Before, everyone just updated from subversion and got the latest code and > there was no worrying about updating our pom files with each test/release > cycle. > > > > We’ve gone the maven route and would like to stick with it. > > Could anyone comment on our process and maybe point out some ways to > improve this constant pom updating? > > > > Thanks, > > Eric > > >
