• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Please advice Maven downloading each version of artifact resulting in out of memory error

 
Ranch Hand
Posts: 123
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello All,

We just moved to maven 3. We have artifact mentioned in ranges, the issue is maven is downloading each and every version of artifact on my local resulting in the build going on forever, and outof memory exception.

Any idea how to force maven to use/download only the latest version.

Thanks
 
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First, Maven usually doesn't download every version of an artifact. It usually downloads only the POMs for the version range you specified, and then usually downloads only the JAR with the highest version number.

Second, Maven builds a classpath that includes the transitive list of dependencies and uses that for compiling and testing. If you have a lot of depdnencies, and they in turn include numerous dependencies, you could use up a lot of memeory.

Third, you gave us no clue as to what OOME you are getting. Are you running out of heap space? Or out of permgen space? Exactly how to fix the issue depends on which one you are running out of. But either way, you can create a ~/mavenrc_pre.bat (or .sh) file and in there set MAVEN_OPTS to any JVM options that you need. For example, if you are running out of heap space, try (in Windows):

set MAVEN_OPTS=-Xmx1024m
 
Darvesh Niz
Ranch Hand
Posts: 123
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are right it mightly only downlaods the pom file.
i am getting Java heap space i tried setting memory till 1024M, but still even the pom are quite a handful.

In order to make things more faster we have also mentioned the minor version.
if the max version of the artifact was 1.2.22 we changed the ranges to something like
[1.2 - 1.3) was changed to [1.2.22 - 1.3)

Thanks
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Maven may download, but it downloads to a disk-based cache. So regardless of what annoyance the downloading process may result in, simple downloading isn't sufficient to blow out RAM.

In order to actually run out of memory, you'd actually have to not only be downloading, you'd have to be actually attempting to use all those jars in the project being built.

There are ways to see what artifacts are being invited in for a given POM, although I'd have to google to remember what they are. The m2eclipse IDE plugin can also show them in graphic displays, but being that you're running short on RAM and Eclipse is pretty memory-hungry itself, I'm not sure you'd enjoy that.

On the whole, however, I don't recommend specifying version ranges in POM dependencies. The whole point of versioning is that things change between versions. If you give an explicit version in the POM, it may not retrieve the latest-and-greatest, but it will retrieve a version with specific behaviors as opposed to whatever can be grabbed. More importantly, if there are transitivity issues, you could certainly end up with cases of multiple versions being pulled in from the different secondary dependencies. I have a problem with a project right now where 2 different versions of a JAR are being tagged and I didn't even specify version ranges.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic