On Feb 22, 2012, at 10:16 AM, <[email protected]> wrote: > >> P.S. I think screwing around with the Maven snapshot naming scheme is >> asking for trouble. Putting it in the manifest seems safer to me. >> Unfortunately, you didn't elaborate on *why* you want to do this, so we >> can't really comment on any alternative solutions. >> > > Oh, I can elaborate ;) This is currently how my team traces its way back > from an binary artifact in the field to source control checkins. I assume > there are much better ways to do this, but, my approach, is an incremental > re-work of our nonstandard build with an eye towards the lowest hanging > fruit, iteratively. Know what I mean?
It sounds like you're describing ad-hoc releases. Recording the SCM id in the manifest will provide traceability, but you're also opening up the can of worms that variances in snapshots of the transitive dependencies make the version of a field installation the *set* of versions for the transitive snapshots that could also vary. Make sense? Resolving issues will get a lot harder because of this. For that reason, I'd adjust your process so field engineers can generate releases on the CI in a self-service manner. If I were BigCo, I'd probably link the release generation requests to the field sites that use them so that I can figure out what customers have these "releases" when it comes time to get them all updated. Brian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
