You should create a profile that is either used in CI (to set the release versions to use), or is used in development (the convenience of flipping to all the snapshots). It depends on your release process as to how you want to go - you want to make sure that the default dependencies are explicitly specified and the ones you intend to next release with.
In the profile, you could use an open ended range to get the latest snapshot, or RELEASE (to get the latest release) - just ensure these aren't values used to release against since they aren't resolved to their actual values and you lose reproducibility. I would personally set this up to have all the latest releases coded into the POM, and then a profile to flip to the latest for testing (either using the method above, or just coding in the relevant snapshot values). I'd probably use that profile in a regular CI build. HTH, Brett 2008/5/16 Eric White <[EMAIL PROTECTED]>: > > Hi, > I'm a little stumped. > > I have a project that collates several installable artifacts(components) > into one easy to distribute installer(roll-up installer). > The project I inherited actually grabs these components from the directory > path when it runs NSIS to build the installer. This bothers me. I want it > to grab artifacts from my repository. > So now all of my installable components deploy a nice little zip assembly > artifact that I can pull down into my roll-up installer. > Works, great. > However, when I run it from my automated build system (bamboo) I want it to > grab the latest non-snapshot builds of each of the components and build me > an installer. > Problem: > How to adjust the versions of each of these component dependencies on the > fly? > > 1. I've considered placing variables in the version fields for each of these > and reading in a properties file to populate them. Doesn't work, every > method I use to read this property file occurs after dependency resolution. > 2. Dependency version ranges! Well, I got excited at first, but it never > resolves to the proper most recent version. I think it's because I'm using > Major.minor.patch.build instead of whatever format maven expects. > 3. Setting version variable values on the command line. This works, but is > a little messy, as there are about a dozen components involved. I might end > up with this. I would need to then write these values to a file and include > it in my tag for posterity. > 4. Maybe mangle the release plugin so that it could read in my version > values from a properties file and fix up the parent pom for me before > tagging and rebuilding... but I am very intimidated by the release plugin > source code. That, and I think the initial dependency validation will still > fail. > > Anyone have any advice? Maybe use ant? :-) > > > -- > View this message in context: > http://www.nabble.com/roll-up-installer-tp17258159p17258159.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Brett Porter Blog: http://blogs.exist.com/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
