You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Olaf Flebbe <of...@oflebbe.de> on 2015/12/24 21:33:05 UTC
BIGTOP-2110: gradle home
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
Re: BIGTOP-2110: gradle home
Posted by Konstantin Boudnik <co...@apache.org>.
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 <of...@oflebbe.de>:
>
> > 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
> >
Re: BIGTOP-2110: gradle home
Posted by Konstantin Boudnik <co...@apache.org>.
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" <co...@apache.org>寫道：
>
> > 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 <of...@oflebbe.de>:
> > > >
> > > >> 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
> > > >>
> > >
> >
> >
> >
Re: BIGTOP-2110: gradle home
Posted by Evans Ye <ev...@apache.org>.
> 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.
> 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" <co...@apache.org>寫道：
> 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 <of...@oflebbe.de>:
> > >
> > >> 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
> > >>
> >
>
>
>
Re: BIGTOP-2110: gradle home
Posted by Konstantin Boudnik <co...@apache.org>.
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 <of...@oflebbe.de>:
> >
> >> 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
> >>
>
Re: BIGTOP-2110: gradle home
Posted by Olaf Flebbe <of...@oflebbe.de>.
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.
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
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 <of...@oflebbe.de>:
>
>> 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
>>
Re: BIGTOP-2110: gradle home
Posted by Evans Ye <ev...@apache.org>.
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.
Maybe we can come up with an empty step to get rid of that annoying logo?
2015-12-25 4:33 GMT+08:00 Olaf Flebbe <of...@oflebbe.de>:
> 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
>