I was referring to profiles in your POM, not in the settings - sorry for the misunderstanding.
- Brett 2008/5/17 Eric White <[EMAIL PROTECTED]>: > > 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] > > -- Brett Porter Blog: http://blogs.exist.com/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
