when your improvements are more related to some plugins, it's another type of
issue: currently, the issues that are worked on are issues on Maven core
preparing the full reactor model in memory, when there are many modules,
dependencies, dependencyManagement, eventually with high depth.
But we'
On Wed, Apr 24, 2019 at 9:20 PM Martijn Dashorst
wrote:
> It has a typical long build time, but not a very complicated setup
> (e.g. the depth of nested projects is about 3 max)
I think Maven should aim (and generate dummy projects for
testing/benchmarking) for even more complex projects. Apach
There's this umbrella of projects called Wicket Stuff at github.
https://github.com/wicketstuff/core
It has a typical long build time, but not a very complicated setup
(e.g. the depth of nested projects is about 3 max)
You might consider using this as a public benchmark.
Looking forward to impr
Yes, there's been reports some time ago about performance degradation in
newer versions. I'm not sure if there was an actual jira ticket or just
mail to the list. Iirc there was no actual end result to resolve it from
that though.
/Anders (mobile)
Den ons 24 apr. 2019 19:09Karl Heinz Marbaise sk
Great findings then!
It’s not easy to catch and my experience is that such big projects are
often in corporate environments which aren’t open at all and not really
working with oss projects thus it’s not surprising to have this surfacing
on Gradle support side.
Le mer. 24 avr. 2019 à 19:09, Karl H
Hi,
On 24.04.19 17:52, Robert Scholte wrote:
On Wed, 24 Apr 2019 12:45:42 +0200, Arnaud Héritier
wrote:
Just for my knowledge, is it a regression in a recent version or it is
like
this for ages ?
It is like this for ages. AFAIK nobody of the team monitored memory
consumption, focus was on c
On Wed, 24 Apr 2019 12:45:42 +0200, Arnaud Héritier
wrote:
Just for my knowledge, is it a regression in a recent version or it is
like
this for ages ?
It is like this for ages. AFAIK nobody of the team monitored memory
consumption, focus was on correct + "readable" code.
Robert
Le
>
> We need to find out who is interested in these kind improvements inside
> the Maven community.
Just wanted to throw my two cents in. My company is a relatively large
Maven user and we're very interested in these sorts of improvements. We've
tried to upstream improvements in the past, but have
Just for my knowledge, is it a regression in a recent version or it is like
this for ages ?
Le mer. 24 avr. 2019 à 10:56, Benedikt Ritter a écrit :
> Am Mi., 24. Apr. 2019 um 10:50 Uhr schrieb Benedikt Ritter <
> brit...@apache.org>:
>
> > Hello,
> >
> > this is a summary of a video conference
Am Mi., 24. Apr. 2019 um 10:50 Uhr schrieb Benedikt Ritter <
brit...@apache.org>:
> Hello,
>
> this is a summary of a video conference call that happened yesterday
> (April 24).
>
Sorry, actually yesterday was April 23... :o)
>
> Topic:
> Discussion about performance improvements that have been
Hello,
this is a summary of a video conference call that happened yesterday (April
24).
Topic:
Discussion about performance improvements that have been proposed by Stefan
Oehme, namely:
- [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource (
https://github.com/apache/maven/pull/244)
- [MN
Hi Jason,
Jason van Zyl wrote:
> Jörg,
>
> If you are going to use the maven-eclipse-plugin as your benchmark I think
> it's going to be very hard to pin point where the bottleneck is. It's a
> little universe unto itself. Could be the shared components, resolution
> code, the plugin itself. I s
.
On Apr 27, 2010, at 8:10 AM, Jörg Schaible wrote:
> Hi guys,
>
> it's not the first time I complain about Maven performance, but it seems M3
> is heading the right direction. Yet, still not on the 2.0.x level:
>
> %< =
> $ MAVEN_OPTS="-Xmx
eritier.net
On Tue, Apr 27, 2010 at 2:10 PM, Jörg Schaible wrote:
> Hi guys,
>
> it's not the first time I complain about Maven performance, but it seems M3
> is heading the right direction. Yet, still not on the 2.0.x level:
>
> %< =
> $ MAVEN
@maven.apache.org
Subject: Maven performance
Hi guys,
it's not the first time I complain about Maven performance, but it seems M3 is
heading the right direction. Yet, still not on the 2.0.x level:
%< =
$ MAVEN_OPTS="-Xmx768m -XX:MaxPermSize=128m" mvn-2.0 eclipse:ecl
Hi guys,
it's not the first time I complain about Maven performance, but it seems M3
is heading the right direction. Yet, still not on the 2.0.x level:
%< =
$ MAVEN_OPTS="-Xmx768m -XX:MaxPermSize=128m" mvn-2.0 eclipse:eclipse
Apache Maven 2.0.11
Java vers
16 matches
Mail list logo
