kbuntrock commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1299226304
##########
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##########
@@ -401,6 +399,26 @@ private Future<File> createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+ try {
+ downloadTask.get();
Review Comment:
As I apprehend the "lazy restore" functionality, there are two approach,
each one with their pros and cons.
**Non lazy restore** (the default) : immediate restoration of artefact and
other build outputs.
Build stability is the main concern. If the restoration fails, the build is
executed normally. (I'm interrogative about the part where you say it can fail
the build. For me it's the exact opposite intend). **Con**: we might restore
stuff not used further in another module build.
**Lazy restore** : restoration of artefacts is done only when used. It can
save some bandwidth and speedup the build when used with a remote cache. (Pros
with a local cache are not so clear to me.) **Con**: If the cache is
corrupted/not accessible and an artefact must be used as a dependency in
another module : the build is doomed and will fail.
Actually, the non lazy restore does not really work as expected since the
restore is done (download is immediately launched when using a remote cache),
but we don't check the result straight away. It might be far too late when
we'll discover the artefact did not restored well.
Am I missing something in the picture?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
