> To: [email protected] > Subject: Re: A thought on local-SNAPSHOTs > Date: Sun, 15 Jun 2014 13:08:17 +0200 > From: [email protected] > > Op Sun, 15 Jun 2014 11:07:33 +0200 schreef Stephen Connolly > <[email protected]>: > > > The real issue I see is people not defining their snapshot policy (and I > > mean that in a wider sense) > > > > Personally speaking I favour *never* deploying snapshots. Only using them > > for local speed up where a large reactor required to wire everything up > > using either the `package` or `verify` phase (with or without tests > > skipped) would just take too long. > > > exactly my thoughts as well. I see a lot of users still doing 'install' > for the wrong reasons: > - coworkers said so / internet said so. > > > So for me, with my pattern of creating local aggregator projects and not > > really installing let alone deploying snapshots, there is no problem... > > > > When working on projects however that use a CI system to deploy snapshots > > after every build... Well I tend to curse them (or turn off snapshot > > update > > checking)... Worse is where this was done because building a specific > > artifact requires a toolchain I do not have access to on my machine... > > So I > > am forced to turn on snapshot checking for every build while working on > > that module. > > > > What you usually find is people have not realised the cause and effect. > > > > I favour the CI server deploying snapshots with every build *but* into a > > repo only for use by the CI server. > > > > I favour never deploying smapshots to developer repositories... Any time > > you think you need to... Well you probably just need to cut a release... > > Can't cut a release because tests are failing? Wtf are you giving me that > > broken shit for... Timestamped snapshots are just a crutch... > > > > My €0.02 > > > > I like to improve the lifecycle even a bit. If you do a deploy, the > install should be skipped. This way all co-workers will pull the same > instance. If the deploy fails, your local repo is still clean. > My current thought is to introduce the ability to split the lifecycle. > > : > : > verify > / \ > install deploy > > This would improve the reliability of Maven, make it a bit faster and in > the end both 'mvn install' and 'mvn deploy' will keep the same behavior. > > thanks, > Robert > > > On Sunday, 15 June 2014, Mark Derricutt <[email protected]> wrote: > > > >> Hey all, > >> > >> A recent discussion on one of the github PR's led to a discussion on > >> SNAPSHOT resolution, which is a long standing issue in maven range > >> support > >> with several long standing open tickets lingering. > >> > >> A thought I just had, which relates to some things I've been playing > >> with > >> in my C.I. builds, could quite simply resolve this. Maybe.... > >> > >> I know a few people who say "they just don't allow/use SNAPSHOTs" but > >> whenever you do an `mvm install` you end up with a -SNAPSHOT in your > >> ~/.m2/repository - and that then affects resolution. > >> > >> My thought was.... why is the local _repository_ treated differently to > >> normal repositories - in that it's as tho > >> `<snapshots><enabled>true</enabled></snapshots>` > >> is defined for them - and maybe it is? Why not simply.... _disable_ > >> that. > >> > >> But further than that, what if maven tracked TWO local repositories: > >> > >> ~/.m2/repository > >> ~/.m2/snapshots > >> > >> Much like `distributionManagement ` has two a `repository` and > >> `snapshotRepository` section, what if we have an > >> `installationManagement` > >> section ( probably limited only to `settings.xml` for install wide > >> settings? ) that did the same, but for the local repository? -SNAPSHOTs > >> installed via `mvn install` or downloaded via dependencies would go in > >> here. > >> > >> This way - there's a clear separation of snapshots and releases, if you > >> don't want snapshot resolution - disable that local repository.... > >> > >> Thoughts? > >> > >> Mark > >> > > MG>SNAPSHOTs are Murphy on your back Not only maven but eclipse distros going into local p2 repo MG>Spent most of the weekend trying to get eclipse buildnumber to sub in "reasonable version" on SNAPS MG>24 hours later i called nojoy and mv SNAPs and success deployed eclipse distros into local p2 repo MG>I agree with Stephen ..if a SNAP is'nt validated for public use dont put in any repo MG>BTW: nexus repositories have 3 categories of distros SNAPs, STAGED and RELEASEs MG>Happy Fathers Day
> --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
