Re: A thought on local-SNAPSHOTs
On 18 Jun 2014, at 17:05, Barrie Treloar wrote: It takes a small (but not negligible) amount of time to haul the release jars from you local Maven Repository - likely also hosted on your CI server. Plus pulling in any snapshots previously deployed. The problem gets extended further when you're actually wanting topic isolation of related, independent changes. If your CI server can't work out that two projects share a dependency relationship are in the build queue then you are left with manual workarounds. In some cases - such as my github based open source projects, using either Travis CI or Cloudbees BuildHive - the projects cannot know they're related - at least AFAIK there's no way of indicating that. Sharing a local maven cache (~/.m2/repo) feels wrong for two independent projects. And if they are dependent they should be built together in the same reactor project. Whilst they're technically independent projects because of using git - where they MUST be due to how maven-release-plugin works, and how git branches/tags - they are related, but differ in release cadence. In-progress reviews that introduce related changes to both require visibility or each others current builds, but neither knows what SHA1 they relate to, unless you start introducing git-submodules and source-dependencies - but that makes for rather wacky repository layouts and monolithic maven builds. As for review, if they are independent why do they need to be reviewed together? 99% of the time they are independent, as the API changes at a slower cadence, but sometimes - changes affect both - and should be review in relation to each other. Perhaps rethinking the workflow is an option? Possibly - at this stage it's looking like "don't use github - or the biggest CI environment on the planet" - sadly. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A thought on local-SNAPSHOTs
On 18 Jun 2014, at 20:50, Stephen Connolly wrote: Thus you can declare upstream literate projects and branch matching criteria... an upstream project's local repository The problem here is the way Gerrit presents its reviews, they're not publicly accessible branches so there IS no matching branch names, as each review/patchset is merely a SHA1 ref. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A thought on local-SNAPSHOTs
Well one of the features I want to write for the literate project type in Jenkins is a smarter Maven awareness... Thus you can declare upstream literate projects and branch matching criteria... an upstream project's local repository cache will then be exposed to downstream projects... but on a branch for branch basis based on the branch matching rules... The UX I am aiming for is that you start working on a feature branch, find you need a change in an upstream library, create a matching feature branch in the upstream library's SCM and now... presto-chango your build stays working as they both have the same local repository cache (with layers on so that downstream does not pollute upstream)... of course since both projects are literate project type, you've also got your own auto-created project in each for your feature branch (which you can have configured to stay retained or be removed X days after the branch is closed) Of course I am searching for a better name than "literate" as while the primary build descriptor format is a literate build in a README file... it also works for other documented build definitions (e.g. there is a .travis.yml parser - if not fully functional - in the code base from day 0) On 18 June 2014 05:18, Mark Derricutt wrote: > You assume CI servers have intelligence and deep knowledge of Maven. Or > that you have deep control over their configuration. > > You can't do that with Travis CI, nor with Code-review tools such as > Gerrit ( not cleanly, not without doing evil things with maven configs like > I mention in [1] ). > > Starting from a complete clean local repo is also kinda horrible as a > small commit will now take 10 minutes or so to download deps just so a > 15second build could fail. That feels WRONG. > > "Living without SNAPSHOTs" should include the CI server, otherwise you're > just (IMHO) lying to yourself about not using SNAPSHOTs. > > [1] http://www.theoryinpractice.net/post/76092272646/intra- > repository-review-builds-with-gerrit-and-apache > > > On 18 Jun 2014, at 15:05, Barrie Treloar wrote: > > Your CI should know that project B depends upon A. >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: A thought on local-SNAPSHOTs
On 18 June 2014 13:48, Mark Derricutt wrote: > You assume CI servers have intelligence and deep knowledge of Maven. Or > that you have deep control over their configuration. > > You can't do that with Travis CI, nor with Code-review tools such as > Gerrit ( not cleanly, not without doing evil things with maven configs like > I mention in [1] ). > > Starting from a complete clean local repo is also kinda horrible as a > small commit will now take 10 minutes or so to download deps just so a > 15second build could fail. That feels WRONG. > It takes a small (but not negligible) amount of time to haul the release jars from you local Maven Repository - likely also hosted on your CI server. Plus pulling in any snapshots previously deployed. I'm not familiar enough your tools, or workflow. If your CI server can't work out that two projects share a dependency relationship are in the build queue then you are left with manual workarounds. Sharing a local maven cache (~/.m2/repo) feels wrong for two independent projects. And if they are dependent they should be built together in the same reactor project. You can manually wait for build-success to be received from the build server before you checkin Project B. As for review, if they are independent why do they need to be reviewed together? Perhaps rethinking the workflow is an option?
Re: A thought on local-SNAPSHOTs
You assume CI servers have intelligence and deep knowledge of Maven. Or that you have deep control over their configuration. You can't do that with Travis CI, nor with Code-review tools such as Gerrit ( not cleanly, not without doing evil things with maven configs like I mention in [1] ). Starting from a complete clean local repo is also kinda horrible as a small commit will now take 10 minutes or so to download deps just so a 15second build could fail. That feels WRONG. "Living without SNAPSHOTs" should include the CI server, otherwise you're just (IMHO) lying to yourself about not using SNAPSHOTs. [1] http://www.theoryinpractice.net/post/76092272646/intra-repository-review-builds-with-gerrit-and-apache On 18 Jun 2014, at 15:05, Barrie Treloar wrote: Your CI should know that project B depends upon A. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A thought on local-SNAPSHOTs
On 18 June 2014 12:23, Mark Derricutt wrote: > Interesting, I hadn't noticed this was only a warning. > > The main problem I have is the moment you start relying on these fake > reactors you end up breaking C.I. builds with dependant changes. > Why? Your CI should know that project B depends upon A. If you checkin B first, then yes you will get problems. If you checkin the correct order then the CI will stack the builds so you wont have a problem. Either in this thread or elsewhere was the guidance to avoid have a snapshot repo for developers. But this is needed for CI, as each build should be using a clean local repo - so it needs to pull snapshots from somewhere else as they wont be in your now empty repo, nor build as part of the reactor. > > This is my main beef with multiple git repositories for projects - if you > have a pairing of dependant changes ( an API change and an Implementation > change ) - without specific tooling about sharing local-repos for discreet > dependent change sets you end up with false-negative build failures. > This is a process issue. Either your CI is too aggressive with its code change checking window, or you need to slow down commits, and make sure they are in the correct order, so that you avoid the false-positive failures.
Re: A thought on local-SNAPSHOTs
Interesting, I hadn't noticed this was only a warning. The main problem I have is the moment you start relying on these fake reactors you end up breaking C.I. builds with dependant changes. This is my main beef with multiple git repositories for projects - if you have a pairing of dependant changes ( an API change and an Implementation change ) - without specific tooling about sharing local-repos for discreet dependent change sets you end up with false-negative build failures. I believe this is an area that Jason's new continuous deliver system does not even try to address (yet), I think I saw it mentioned that it requires simple-repo to work. Mark On 16 Jun 2014, at 20:00, Stephen Connolly wrote: That's it... and also note that while Maven complains if the pom at the specified is not the parent, it will build correctly ... just resolving the parent from the local repository and not from the disk. On 16 June 2014 06:05, Barrie Treloar wrote: On 16 June 2014 14:12, Stephen Connolly wrote: On Sunday, 15 June 2014, Mark Derricutt wrote: So if I have two modules that are interdependent on in-progress changes, how does one build/test the dependant one. Note - reactor builds and multi-modules builds are out of the question - the above modules are in separate git repositories and there's no way to create a "fake reactor" setup - i.e. a separate pom.xml just listing elements ( maven complains when that pom is not the parent ). Even if the local aggregator does something like ../foo A link to a blog post or more detail might be useful for those still learning. I'm pretty sure I know this to look like ROOT/ - aggregator - pom.xml (reference modules ../projectA and ../projectB) - projectA - projectB But its not something I do, and I'm hoping I got it right from Maven experience :) This is where the vaoporware "Magic Checkout" plugin that Kristian has mentioned would be useful. This plugin would automatically change a released dependency to its snapshot version, check it out, and update/create the aggregator project to reference the checked out version. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A thought on local-SNAPSHOTs
That's it... and also note that while Maven complains if the pom at the specified is not the parent, it will build correctly ... just resolving the parent from the local repository and not from the disk. On 16 June 2014 06:05, Barrie Treloar wrote: > On 16 June 2014 14:12, Stephen Connolly > wrote: > > > On Sunday, 15 June 2014, Mark Derricutt wrote: > > > > > So if I have two modules that are interdependent on in-progress > changes, > > > how does one build/test the dependant one. > > > > > > Note - reactor builds and multi-modules builds are out of the question > - > > > the above modules are in separate git repositories and there's no way > to > > > create a "fake reactor" setup - i.e. a separate pom.xml just listing > > > elements ( maven complains when that pom is not the parent ). > > > > > > Even if the local aggregator does something like > > > > ../foo > > > A link to a blog post or more detail might be useful for those still > learning. > > I'm pretty sure I know this to look like > ROOT/ > - aggregator > - pom.xml (reference modules ../projectA and ../projectB) > - projectA > - projectB > > But its not something I do, and I'm hoping I got it right from Maven > experience :) > > This is where the vaoporware "Magic Checkout" plugin that Kristian has > mentioned would be useful. > This plugin would automatically change a released dependency to its > snapshot version, check it out, and update/create the aggregator project to > reference the checked out version. >
Re: A thought on local-SNAPSHOTs
On 16 June 2014 14:12, Stephen Connolly wrote: > On Sunday, 15 June 2014, Mark Derricutt wrote: > > > So if I have two modules that are interdependent on in-progress changes, > > how does one build/test the dependant one. > > > > Note - reactor builds and multi-modules builds are out of the question - > > the above modules are in separate git repositories and there's no way to > > create a "fake reactor" setup - i.e. a separate pom.xml just listing > > elements ( maven complains when that pom is not the parent ). > > > Even if the local aggregator does something like > > ../foo A link to a blog post or more detail might be useful for those still learning. I'm pretty sure I know this to look like ROOT/ - aggregator - pom.xml (reference modules ../projectA and ../projectB) - projectA - projectB But its not something I do, and I'm hoping I got it right from Maven experience :) This is where the vaoporware "Magic Checkout" plugin that Kristian has mentioned would be useful. This plugin would automatically change a released dependency to its snapshot version, check it out, and update/create the aggregator project to reference the checked out version.
Re: A thought on local-SNAPSHOTs
On Sunday, 15 June 2014, Mark Derricutt wrote: > So if I have two modules that are interdependent on in-progress changes, > how does one build/test the dependant one. > > Note - reactor builds and multi-modules builds are out of the question - > the above modules are in separate git repositories and there's no way to > create a "fake reactor" setup - i.e. a separate pom.xml just listing > elements ( maven complains when that pom is not the parent ). Even if the local aggregator does something like ../foo ? > > On 15 Jun 2014, at 23:08, Robert Scholte wrote: > > exactly my thoughts as well. I see a lot of users still doing 'install' >> for the wrong reasons: >> - coworkers said so / internet said so. >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: A thought on local-SNAPSHOTs
On Jun 15, 2014, at 5:45 PM, Mark Derricutt wrote: > So if I have two modules that are interdependent on in-progress changes, how > does one build/test the dependant one. > This setup is just normal and works in m2e with Eclipse's workspace resolution. I can have an arbitrary graph of projects where the projects can be in source form or binary dependencies: everything is resolved from within Eclipse and I don't need the command line at all. I have worked like this for years and Igor has made many improvements over time to make it easier. > Note - reactor builds and multi-modules builds are out of the question - the > above modules are in separate git repositories and there's no way to create a > "fake reactor" setup - i.e. a separate pom.xml just listing > elements ( maven complains when that pom is not the parent ). > That said I am working with a customer where this type of workspace resolution we have in Eclipse we want on the command line. Ideally I want the behaviour we have in Eclipse to be available on the command line and in CI systems. The graph of projects you have in your IDE is probably not too dissimilar from a graph of projects you have in a CI system and you should be able to build them all in the same "workspace". I basically always work in Eclipse for this reason and I never install anything until I want to try it all on the command line. Ultimately I hope not to have to install anything ever and maybe install can just go away at some point. > On 15 Jun 2014, at 23:08, Robert Scholte wrote: > >> exactly my thoughts as well. I see a lot of users still doing 'install' for >> the wrong reasons: >> - coworkers said so / internet said so. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To think is easy. To act is hard. But the hardest thing in the world is to act in accordance with your thinking. -- Johann von Goethe
Re: A thought on local-SNAPSHOTs
On 15 Jun 2014, at 21:07, Stephen Connolly wrote: I favour never deploying smapshots to developer repositories... Any time Agree fully on not deploying snapshots - but I'm talking about locally INSTALLED snapshots. broken shit for... Timestamped snapshots are just a crutch... Agreed totally - and we never use them either. But that's 100% irrelevant to this topic ( at least directly ). - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A thought on local-SNAPSHOTs
So if I have two modules that are interdependent on in-progress changes, how does one build/test the dependant one. Note - reactor builds and multi-modules builds are out of the question - the above modules are in separate git repositories and there's no way to create a "fake reactor" setup - i.e. a separate pom.xml just listing elements ( maven complains when that pom is not the parent ). On 15 Jun 2014, at 23:08, Robert Scholte wrote: exactly my thoughts as well. I see a lot of users still doing 'install' for the wrong reasons: - coworkers said so / internet said so. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: A thought on local-SNAPSHOTs
> To: dev@maven.apache.org > Subject: Re: A thought on local-SNAPSHOTs > Date: Sun, 15 Jun 2014 13:08:17 +0200 > From: rfscho...@apache.org > > Op Sun, 15 Jun 2014 11:07:33 +0200 schreef Stephen Connolly > : > > > 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 >/\ > installdeploy > > 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 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 > >> `true` > >> 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: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org >
Re: A thought on local-SNAPSHOTs
Op Sun, 15 Jun 2014 11:07:33 +0200 schreef Stephen Connolly : 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 /\ installdeploy 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 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 `true` 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A thought on local-SNAPSHOTs
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. 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 On Sunday, 15 June 2014, Mark Derricutt 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 > `true` > 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 > -- Sent from my phone
Re: A thought on local-SNAPSHOTs
I definitely like that. At times (and many times) I want to blow away all my local snapshots. Having a separate local repo for that would be a nice separation. Cheers, Paul On Sat, Jun 14, 2014 at 10:12 PM, Mark Derricutt 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 > `true` > 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 >
A thought on local-SNAPSHOTs
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 `true` 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
