publishInstallationPublicationToMavenRepository task fails with OutOfMemoryError: Java Heap Space

Hello, my Gradle build uses the publish task in order to upload a 250 MB zip file to nexus which works well in the first place. But in release mode I use another gradle script that does the whole checkout/commit stuff and in the middle it calls the regular build via Gradle tooling api. This works also pretty well for other projects.

But the 250MB upload (which works if not invoked via tooling api) always fails with an OutOfMemoryError when executing task publishInstallationPublicationToMavenRepository with Maven-Wagon in the callstack.

Even the jvm settings set DEFAULT_JVM_OPTS=-XX:MaxPermSize=1024M -Xmx6G doesn’t change this behavior. I see with jconsole that this setting is effective.

I see also no spawned jvm which could get lost of the memory settings.

From my Maven experience I know that this Wagon thing doesn’t play well with large file because it loads it completely into memory. But I gave it 6GB and the sole artifact to upload is 250MB in size.

I run out of ideas. David

I’ve solved this problem by passing jvmArguments to the BuildLauncher. Now it spawns a separate jvm and it works.

But still not understand why it should be necessary to spawn a jvm in order to get it working. The initial jvm has the same memory settings of -XX:MaxPermSize=1024M -Xmx6G which should be quite enough. Now that I can see the effective memory usage for uploading 250MB is 1.2GB which should fit into 6GB.

Hi I have the Windows 2003 server PC with 2G RAM onboard.

I try to upload the artifacts into Nexus using Gradle.

When the artifact become larger - I started to get Java Heap Size Error when uploading artifact into Nexus.

I tried to play with the JVM parameters and found, that the maximum artifact size could be about 500M and should

set JAVA_OPTS=-Xmx1536m

It is funny, that the Gradle reads full artifact into the memory before uploading. So it requires 3 times more free memory than the size of artifact. And it is inexplicably that the problem reported in 2010 is still present in gradle world and not fixed yet.