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?


> 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
:)

Cheers


> --
> Darrell (Daz) DeBoer
> Principal Engineer, Gradleware
> http://www.gradleware.com
>
>


-- 
Szczepan Faber
Principal engineer@gradleware
Lead@mockito

Reply via email to