On Mon, Dec 28, 2015 at 02:39AM, Evans Ye wrote: > Hi Olaf, > > That was my "masterpice". ;) > > 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.
Yup, we need a controlled environment and who know what might be hiding in
one's closet... err, I meant ~/.gradle.
> Maybe we can come up with an empty step to get rid of that annoying logo?
I reckon the logo is only showed if {{help}} task is called. So can call
something less verbose like {{all-components}} or simply add an empty task
just to trigger Gradle into downloading all its plugins.
The failure to properly detect -g settings on ppc doesn't look to me like its
our problem. Unsetting GRADLE_OPTS prevents the daemon from start and
everything then becomes fine: so it looks like the daemon interference.
Perhaps it is worthy to raise an issue with Gradle community?
Cos
> 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
