ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mandie Smith <>
Subject Re: subant holds onto classloaders
Date Fri, 10 Sep 2010 18:29:03 GMT
We actually use ivy:buildlist/exec instead of subant to avoid that exact
scenario.  This also allows you to pass in custom JVM args to the
subprocesses.  We use ant-contrib to do a for loop through the sorted build

Here's a condensed example:

<ivy:buildlist reference="build-path" haltonerror="true"
  <fileset refid="buildFiles.fileset" />

<for list="${toString:build-path}" param="moduleBuildFile" delimiter=":">
    <exec executable="ant" dir="${projects.dir}/${}"
outputproperty="exec.output" resultproperty="exec.result">
      <arg line="${module.buildproperties}" />
      <arg line="${module.targets}" />


On Wed, Sep 8, 2010 at 8:44 AM, Troy Self <> wrote:

> I am using the ivy:buildlist / subant combination to operate the build for
> a
> large project. The project consists of about 20 different sub-projects. The
> sub-projects each depend on a combination of other sub-projects as well as
> some 3rd party libraries. Ivy takes care of building them in order for me.
> That's all great.
> The issue I have is that subant does all of this in a single process. As a
> result, as each sub-project resolves its compile dependencies and then
> later
> resolves its junit dependencies, the primary JVM process is retaining all
> of
> the classloaders and never unloading them. The result is that my build
> eventually fails due to running out of memory in the PermGen space.
> Does anyone know of a way that I can get the sub-projects to build in the
> correct order, but still have ant fork a new process for each one? This way
> the primary JVM would not keep adding and retaining classloaders.
> Btw, when running manually, I can get around the issue by increasing the
> PermGen space using -XX:MaxPermSize=256m. However, my continuous build
> system (Cruise Control) seems to want to run ant with the default JVM
> parameters and this solution only delays the issue anyway.
> Thanks,
> -- tBs

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message