out of memory space on a big build

[Steve Loughran <st...@apache.org>]

We're running out of memory in a big multi-module build, using rmic and 
ivy; its <ivy:configure /> or <rmic> that things break. I've tried ivy 
1.4.1 and 2.0.0-alpha1.


1. has anyone else encountered memory consumption problems (out of 
permgenspace)?
2. this seems most common on java1.6.

I'm not sure that ivy is the problem here, we will have to track it down 
(somehow), and am just checking before doing anything else (like 
profiling the build)

repreport configuration

[Nascif Abousalh-Neto <Na...@sas.com>]

 
Greetings,

If I am using multiple repositories, is there a way to configure repreport to report on just one?

I am using the "multi-project" example that comes with 1.4.1 and I started a repreport 45 minutes ago and it is still going, downloading information from (I think) ibiblio.

I just care about what is on my local, output repository. But I found no obvious way to configure repreport to narrow into it.

Thanks,
  Nascif

Re: out of memory space on a big build

[Gilles Scokart <gs...@gmail.com>]

I also noted that on a big multiproject build because I was reloading
ivy in each sub-project.  Fixing that solved my problem.

Gilles

2007/6/21, Jeffrey Blattman <je...@gmail.com>:
> yes we've seen this. i am not sure it has anything to do w/ Ivy. it is
> well noted that the ant and antcall tasks are memory intensive as they
> created new classloaders. you can get around this by increasing the
> permgen space for java when you run ant ...
>
> $ export ANT_OPTS="$ANT_OPTS -Xmx512m -XX:MaxPermSize=256m"
>
> you can probably make do w/ something <256M, but it depends on your build.
>
>
> Steve Loughran wrote:
> >
> > We're running out of memory in a big multi-module build, using rmic
> > and ivy; its <ivy:configure /> or <rmic> that things break. I've tried
> > ivy 1.4.1 and 2.0.0-alpha1.
> >
> >
> > 1. has anyone else encountered memory consumption problems (out of
> > permgenspace)?
> > 2. this seems most common on java1.6.
> >
> > I'm not sure that ivy is the problem here, we will have to track it
> > down (somehow), and am just checking before doing anything else (like
> > profiling the build)
> >
>


-- 
Gilles SCOKART

Re: out of memory space on a big build

[Jeffrey Blattman <je...@gmail.com>]

yes we've seen this. i am not sure it has anything to do w/ Ivy. it is 
well noted that the ant and antcall tasks are memory intensive as they 
created new classloaders. you can get around this by increasing the 
permgen space for java when you run ant ...

$ export ANT_OPTS="$ANT_OPTS -Xmx512m -XX:MaxPermSize=256m"

you can probably make do w/ something <256M, but it depends on your build.


Steve Loughran wrote:
>
> We're running out of memory in a big multi-module build, using rmic 
> and ivy; its <ivy:configure /> or <rmic> that things break. I've tried 
> ivy 1.4.1 and 2.0.0-alpha1.
>
>
> 1. has anyone else encountered memory consumption problems (out of 
> permgenspace)?
> 2. this seems most common on java1.6.
>
> I'm not sure that ivy is the problem here, we will have to track it 
> down (somehow), and am just checking before doing anything else (like 
> profiling the build)
>

RE: out of memory space on a big build

["Loehr, Ruel" <rl...@pointserve.com>]

Lots of things to check:

What are your memory settings set to?  Are you using the defaults?  
If so, bump them up and see what happens.  Increase your permgen space.
When does it happen in your build?   As soon as you download
dependencies?
After compilation?  

More info required.


-----Original Message-----
From: Steve Loughran [mailto:stevel@apache.org] 
Sent: Thursday, June 21, 2007 11:09 AM
To: ivy-user
Subject: out of memory space on a big build


We're running out of memory in a big multi-module build, using rmic and 
ivy; its <ivy:configure /> or <rmic> that things break. I've tried ivy 
1.4.1 and 2.0.0-alpha1.


1. has anyone else encountered memory consumption problems (out of 
permgenspace)?
2. this seems most common on java1.6.

I'm not sure that ivy is the problem here, we will have to track it down

(somehow), and am just checking before doing anything else (like 
profiling the build)