On 02/01/2012, at 9:12 PM, Daz DeBoer <[email protected]> wrote:
> 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'
Which, looking at it, seems like too much work. Perhaps we should provide a
shorthand.
> 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!
>
> 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
Conceivable use case, but carries far less weight than the reasonable
expectation of a user to not do the 100 downloads outlined above.
> 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?
Could we provide API to invalidate the cache at runtime for a particular
dependency?
> 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.
This seems too coarse to me. Given how edge this is, I think having the user
specifically tell us to purge the cache is better. It avoids unnecessary checks
and is conceptually simpler I think.
> 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?
The current behavior leaves a bad taste in people's mouths so I think it's
important to fix. If we invalidate the cache on upload and provide a way for
the user to do it ad hoc I think that's enough. That shouldn't block anyone.
Then we can see what use cases emerge and maybe provide some more automatic
stuff.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
