I am only speaking in regard to MNG-3092, there are several other related issues which I think all should be fixed
Cons ---------------------- 1) Continuous integration of trunks I would like to be able to run the tests of all of my artifacts against a build of trunk of every other. How I currently achieve this... Use continuum with clean install and force a rebuild of every artifact on a regular basis. If MNG-3092 were to go ahead in order to include a snapshot in a build I would have to change the dep of each artifact to include a -SNAPSHOT in one of the bounds. 2) Using MNG-3092 is not the correct approach to exclude snapshots from releases. The enforcer plugin can detect and alert when a snapshot is resolved anywhere in the transitive tree. It would be nice to be able to bind this to a release Pros --------------------------------- 1) stops you getting inconsistent builds when you have a snapshot repository in your repository list that has artifacts matching a range 2) will stop (i think) dirty builds from snapshot metadata in the local repository. The local repository has multiple personality disorder. There is no way to enable disable the local metadata left in the local repository after a release or install. If the local repository cache was separate and the actual local repository (i.e. for installs) was a first order repo then this problem would go away On Thu, 31 Jan 2008 02:14:59 Stephen Connolly wrote: > IMHO > > I think a vote with the two positions clearly identified (perhaps with pros > and cons for both if the pair of ye can agree on the pros and cons). > (unless somebody else has a third position) > > -Stephen. > > On Jan 30, 2008 12:56 PM, Mark Hobson <[EMAIL PROTECTED]> wrote: > > On 30/01/2008, Mark Hobson <[EMAIL PROTECTED]> wrote: > > > I don't think that linking this level of artifact resolution > > > uncertainty to its source repository is a good idea. How version > > > ranges are resolved should be completely deterministic and independent > > > from where the artifact was actually downloaded from, otherwise we'll > > > end up with no end of build reproducibility problems. > > > > In addition, the local repository would be exempt from these rules. > > This would require manually deleting artifacts from the local repo to > > ensure that certain versions weren't picked up; a maintenance > > nightmare I'm sure you'll agree. > > > > How's best to proceed with resolving this issue? Would voting make > > sense, or should the PMC lay down the intended direction? I'm not > > sure whether this thread needs to get any longer.. :) > > > > Mark > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
