On Mon, Dec 28, 2015 at 02:05PM, Evans Ye wrote: > > Since you do not remove gradle.home before runnung gradle -g it will add > > garbage, too. This may not a valid point here. > > I dont think with -g will add garbage since we create a new dir for cache. > As a resault we don't need to clean up gradle.home(~/.gradle) as well. They > are separated. > > I dont think clean up the gradle.home during the cache gen step is a good > idea neither because components built by gradle will be affected, i.e. > their jars will be removed, which is an annoying side effect. Realclean > might be better, but we need some clear description when gradle tasks > invoked.
I guess cleaning would _only_ make sense during the generation phase, to guarantee that our image comes with nothing but a fresh set of the libs and other things pulled in by Gradle. Cos > > If you are afraid of stacking up lots of garbage, why don't you provide a > > .dockerignore file with following entries: > > Yup, as cos said these dirs are not the problem. The jars inside > gradle.home are. And we cant enumerate them into dockerignore. > 2015年12月28日 上午3:39於 "Konstantin Boudnik" <[email protected]>寫道： > > > On Sun, Dec 27, 2015 at 08:34PM, Olaf Flebbe wrote: > > > Hi Evans, > > > > > > > > > > > That was my "masterpice". ;) > > > > > > git blame is a snitch ;) > > > > > > > > > > > Copying $HOME/.gradle may accidentally commit large amount of unrelated > > > > libraries into docker images. Which is why we setup another clean dir > > using > > > > the -g option. > > > > > > > > Maybe we can come up with an empty step to get rid of that annoying > > logo? > > > > > > > > > > Since you do not remove gradle.home before runnung gradle -g it will add > > > garbage, too. This may not a valid point here. > > > > Well, then 'realclean' target needs to be improved to take care about this > > issue. Or we need to wipe out gradle.home first thing then the generation > > task > > is called. > > > > > If you are afraid of stacking up lots of garbage, why don't you provide a > > > .dockerignore file with following entries: > > > > > > build > > > output > > > bigtop-packages > > > dl > > > > I am not concerned about these. I am concerned about all sorts of crazy > > cached > > libs that might affect the correctness of the build. I just seen this too > > many > > times in Maven/Ivy world already > > > > Cos > > > > > IMHO Much more important than a few possible garbage entries in ~/.gradle > > > (Or is it only me falling over this sending GB of staff to docker when > > > building images on my toy machine?) > > > > > > Olaf > > > > > > > 2015-12-25 4:33 GMT+08:00 Olaf Flebbe <[email protected]>: > > > > > > > >> Hi > > > >> > > > >> I stumbled over fallout of BIGTOP-2110 > > > >> > > > >> IMHO this is absolutly weird to run gradle within gradle ... and pick > > up > > > >> side effects. > > > >> > > > >> * The output is misleading (Because I get the bigtop logo each time I > > run > > > >> bigtop-slaves). I thought that we have dependency issues within > > > >> build.gradle. > > > >> > > > >> Somehow the gradle.home is not created at current dir on ppc64le , > > or the > > > >> code interferes with gradle daemon. > > > >> > > > >> I vote to rework the patch... > > > >> > > > >> Why don't we just copy $HOME/.gradle ????? > > > >> > > > >> Olaf > > > >> > > > > > > > > >
signature.asc
Description: Digital signature
