Thanks for reply - see inline
On 21/06/2011 11:27, B Smith-Mannschott wrote:
On Mon, Jun 20, 2011 at 19:54, Paul French<[email protected]> wrote:
Below is some filtered output from a maven build (showing maven meta data
being downloaded for one artifact). All my dependencies use version ranges
of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT)
In general the build fails with out of memory. I can increase the heap size
and the build is successful, but a relatively simple build is now requiring
500MB heap size.
First question is why is maven re-checking and downloading the same meta
data over and over again?
If I add additional version ranged dependencies to my pom then the problem
seems to get exponentially worse. For a larger build so many requests are
made so quickly to the nexus remote repository that I start to see "Error
transferring file: Address already in use: connect".
Any ideas how to reduce the memory usage? Do not say "do not use version
ranges". We use semantic versioning enforced by API analysis tools for each
of our modules (OSGi bundles) so we require version ranges.
If I change all version range dependencies to an exact dependency (a serious
amount of pom editing) then all is fine. As you can tell below we have 3
main internal remote repos setup (kirona, kirona-snapshot and
third.party.libraries). We do not specify version ranges on libraries that
are not in our control e.g. log4j etc etc
Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 21.6 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 6.6 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 10.0 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 11.2 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 9.7 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 10.8 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve...........
The above problems renders eclipse useless with m2e, it causes eclipse to
hang on start up (build automatically set to true) and eventually die!!
I'm starting to come to the conclusion that between maven and m2e version
ranges just do not work very well. I hope I am wrong!!
Thanks
Paul
In my a case I found Maven slurping metadata on every build was
related to how I had configured<updatePolicy>always</updatePolicy> in
repositories profile defined in my settings.xml (It had been a
"temporary" change which got forgotten...)
I did circumvent the problem as you suggest by setting my repos to have an
updatePolicy
of interval:10 so during a build, maven does not re-download the same
maven meta data file. However not very complicated builds are still failing
with out of memory even with 1024M of heap space. So this workaround just
speeds up the inevitable out of memory error appearing.
I got burned twice by version ranges. (It's at least a few years ago,
so I don't remember the specifics.) I haven't touched them since.
Also, their meaning hinges on how Maven chooses to sort versions, and
I've not yet seen a sufficiently unambiguous definition of that.
Consider that Maven will accept aNyOld3.2Crap-X1r as a version number.
Even if you stick to the 'parse-able' versions of the form
1.2.3-mumble.
1.2.3-SNAPSHOT< 1.2.3
1.2.3-beta10< 1.2.3-beta2
1.2.3-beta1-SNAPSHOT< 1.2.3-beta1
1.2.3-beta1>?< 1.2.3?
1.2.3-beta1-SNAPSHOT>?< 1.2.3-SNAPSHOT
Hence why we use ranges like [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) - i.e.
happily depend on a 1.X version including a work in progress
1.0.0.SNAPSHOT but do not depend
on any 2.0.0 version, hence why we have excluded 2.0.0.SNAPSHOT since
like you said 2.0.0.SNAPSHOT < 2.0.0
Take your best guess.
Sticking to using only SNAPSHOTs and single concrete versions is more
work if you have a large number of interdependent projects. It does
have the advantage of recording in your version control system very
specific information about which versions go (went) together.
All true, but at release time you can use the maven plugin
versions:resolve-ranges which will backup your pom and then modify with
the versions actually used.
// ben
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
