500Mb is not a lot of memory for a Java program.
We have noticed that some libraries such as Apache's CXF webservices
will require additional memory to be added to Maven if you are building
applications that include it.
Since virtual memory is virtually free, you might as well just accept
reality and increase the VM.
I can not imagine anyone doing software development with a modern IDE
that would have trouble finding 1Gb of VM.
We build under Eclipse STS but I don't think that it makes any
difference since Maven is running in its own VM.
I would not use version ranges since I like to know what I am putting
into production.
Once you initially set the versions of what you are supporting, it is
not difficult to maintain that list as you work your way through new
versions of third party code.
We do it at the start of each of our release cycles.
We usually stick with the existing set from the last release unless
there is a reason to move.
The version configuration for a new release is setup and managed by the
entire team (small part of the release startup) and unless something
catches fire, we stick with our set throughout the life of our release.
Ron
On 21/06/2011 8:59 AM, Benson Margulies wrote:
Yes this came to the list.
*someone* is going to have to run yourkit or jprofiler on a real
version of your problem.
Of course, the person best positioned to do that would be, ahem, you.
Unless you could give access to, well, me.
It would be a giant public service for there to be a sufficiently
complex example of this sort of thing available for development and
testing, .... and it would pay your organization off in the long run
in terms of maven working better for you.
On Tue, Jun 21, 2011 at 6:42 AM, Paul French<paul.fre...@kirona.com> wrote:
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<paul.fre...@kirona.com> 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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
