On 2 January 2012 14:58, Szczepan Faber <[email protected]> wrote: > On Mon, Jan 2, 2012 at 10:12 PM, Daz DeBoer <[email protected] > > wrote: > >> Hey all >> >> Currently, if you want to be guaranteed of getting the very latest >> SNAPSHOT for your build, you need to use: >> configuration.name.resolutionStrategy.cacheChangingModulesFor 0, 'seconds' >> >> This has the unfortunate side-effect of causing every sub-project in a >> multi-project build to verify and possibly download the SNAPSHOT artifact. >> So if you have 100 subprojects, every one will make a remote call to check >> if the SNAPSHOT is up-to-date, and if no SHA1 file is available to check, >> you'll download the SNAPSHOT artifact 100 times! >> > > Let me clarify for my own understanding: we're talking about 100 > submodules, each and every one with 'someConfiguration' that contains > dependency to 'barArtifact' snapshot and each project and > 'someConfiguration' has the resolutionStrategy configured as above, with 0 > seconds. Right? >
Correct. The "0 seconds" is measured from the commencement of resolution for each subproject, so even a cached entry from a previous resolution in the same build will be considered out of date. > > >> It's trivial for me to update Gradle to only resolve a SNAPSHOT once per >> build, using the cached artifact for the lifetime of the build. The main >> downside to this is that we would no longer support the scenario >> multi-project scenario: >> /sub-project1 -- Resolve mymodule-SNAPSHOT >> /sub-project1 -- Publish a new version of mymodule-SNAPSHOT >> /sub-project2 -- Resolve mymodule-SNAPSHOT, and expect the newly >> published one >> >> I guess we could support this by invalidating the cached entry when we >> publish a new version, but what if the publication is done via a custom >> task? >> Perhaps we need a new way to express that a module may change _during_ >> the build, so we can't even rely on a cached version from within this >> build. My gut feel is that the common scenario is to use the latest >> version, but only check once per build. >> >> Any feedback? What use-cases do we need to support? >> > > My gut feel tells me we should be backwards compatible, at least by > default :) > Well until _very_ recently the multi-project scenario above would never work on Windows, due to file locking issues. My feeling is that the entire caching DSL will be reworked for the next release (also for offline and force support). So I'm trying to gather use cases to drive this rework. Daz
