Definitely on-topic, I hope you'll find the time some day to make a patch.
Kristian
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
This should be... IIRC, spreading test cases across cores in such a way that
the least number of cores are idle at the end.
Not sure if this is the full replacement for kk's maven-junit-plugin use case
yet... But hoping ;-)
Sent from my iPhone
On 29 Jan 2012, at 16:40, Jason van Zyl wrote:
>
That piece of code was implemented for ANT and only later ported into
a Maven plugin/ mojo. I have no doubt that taking the code directly
won't work because of architectural differences between the projects
and like most people I too have too much work and too little time so
delving into surefire's
If you want to submit any of your stuff as patches I can assure you it
will be reviewed,
patches w/tests in surefire get processed quickly.
Kristian
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional comman
> We don't have the two-way comms channel between the plugin and the fork in
> surefire which means it's all precalculated.
Yes, I know.
> There are certainly benefits/drawbacks
> to both approaches. My personal use-case involves extremely long-running
> tests and of
> extreme variation in run-t
We don't have the two-way comms channel between the plugin and the fork in
surefire which means it's all precalculated. There are certainly
benefits/drawbacks
to both approaches. My personal use-case involves extremely
long-running tests and of
extreme variation in run-time, which seems to fit bett
> Based on data from pervious runs, this setting optimizes the runorder
> of the tests to minimize total run-time.
This is a digression, but I think may be inspirational.
Kristian's description matches how I implemented per-jvm balancing in
our JUnit4 runner initially and I have a suggestion on h
It was suggested that I was less than clear about the
runOrder=balanced parameter, so here goes:
Based on data from pervious runs, this setting optimizes the runorder
of the tests to minimize total run-time.
Given for tests:
A 7 minutes
B 5 minutes
C 1 minute
D 1 minute
Previously you'd be *req
On Jan 29, 2012, at 8:43 AM, Kristian Rosenvold wrote:
> Given N parallel forks, it attempts to schedule tests so all forks
> will complete at the same time. It's runOrder=balanced in the docs.
> Great feature for users with long-running tests. We saved 20% run-time
> on our selenium tests. 2.11
Given N parallel forks, it attempts to schedule tests so all forks
will complete at the same time. It's runOrder=balanced in the docs.
Great feature for users with long-running tests. We saved 20% run-time
on our selenium tests. 2.11 supported balanced for regular parallel
runs, 2.12 adds support f
On Jan 29, 2012, at 6:03 AM, Kristian Rosenvold wrote:
> Hi,
>
> This is the first java 1.5 version of the surefire plugin. For Junit3
> it is still capable of forking down to java 1.3. Parallel forks are
> the new thing in this release,
> and it should now be possible to run balanced parallel f
Busted local repo on my "release" user; problem solved.
Kristian
2012/1/28 John Casey :
> On 1/27/12 5:14 PM, Kristian Rosenvold wrote:
>>
>> John !
>>
>> For some reason Surefire809GroupExpressionsIT always seems to work
>> nicely when running clean install, but the TestNG tests consistently
>>
Hi,
This is the first java 1.5 version of the surefire plugin. For Junit3
it is still capable of forking down to java 1.3. Parallel forks are
the new thing in this release,
and it should now be possible to run balanced parallel forks; a pretty
cool feature for people with long-running tests.
**
13 matches
Mail list logo
