Thanks for the response! I think profiles might help. But this would mean defining the latest version numbers in my settings.xml. Which means my component builds would have to parse settings.xml and replace their version numbers when they build. Doable but not elegent. One question, is this captured somehow in the repository when the artifact is deployed? I'm about to go try it.
Also, just to provide some more information: In my build system their are two types of projects, common and products. Common projects may be dependencies of other projects and have two build plans each, test and promote. Test just deploys a snapshot artifact, and promote runs the release plugin. Products projects are more relavent to this discussion. They are not allowed to be dependencies (except to the roll-up installer). They are customer facing, so their major and minor version numbers are synced up. These have two build plans each, test and assemble. "Test" runs on source check in and ensures it is build-able and passes unittests. Assemble is run manually, tags the source, and creates a zip assembly with everything needed to run that product. It is these "product" assemblies that I am grouping and rolling together into installers. The version numbers of the assembly builds are automated, (ie, 3.4.0.57) where 57 is the build number provided by bamboo. This allows QA to goto bamboo hit play, and walk away with something to test that is versioned and tagged in source control. So I don't really have control over what the next released version will be. It depends on how many times QA clicks the button. My hope was that I could set it up such that the assembly builds could log their latest version somewhere and then I could use that property to tell the roll-up installer which verison to use. So right now, the options are, 1. figure out how to parse settings.xml during product assembly builds and update the version number for that dependency in the proper profile. Probably write a maven plugin for this. 2. Put the versions for the product assemblies on the command line in bamboo and use bamboo variables to set them. Would require a bamboo plugin to read properties and set the bamboo variables (if this is even possible) Thanks, Eric Brett Porter wrote: > > 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] > > > -- View this message in context: http://www.nabble.com/roll-up-installer-tp17258159p17276622.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]
