camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: Windows build completely working now
Date Mon, 15 Mar 2010 12:10:58 GMT
I would also like to see a more aggressive testing strategy, probably using 'once' instead
of 'pertest'.  The only major offender is indeed jmx which does not cleanup properly on shutdown,
you are correct. We should definitely look into the jmx cleanup, because we cannot always
assume the lifetime of the camel context to match the one of the hosting process.

My $0.02,

On Mar 15, 2010, at 3:33 AM, Christian Schneider wrote:

> Hi Willem,
> that is probably a good idea. I guess there are other modules that need this setting
too. I can report where I have failures now and you can then also set these modules to fork
per test.
> Many modules like core and spring do not seem to need the setting. So I guess it is a
good idea to keep the fork mode in a faster setting for them.
> Another possibility would be to set fork per test as default and set to a faster setting
for specific modules. I guess Claus would prefer this variant.
> Greetings
> Christian
> Am 15.03.2010 07:41, schrieb Willem Jiang:
>> The test became long because I changed the surefire plugin's fork mode to be "pertest"
from the camel root pom.xml. That is not necessary for most case, so I reverted my change
and let the camel-jetty module's fork mode to be "pertest".
>> Willem
>> Claus Ibsen wrote:
>>> On Mon, Mar 15, 2010 at 3:15 AM, Willem Jiang <>
>>>> Hi,
>>>> I just change the fork mode in the camel-jetty to be pertest, it will save
>>>> us some time of running the test.
>>> Why did you do that? Testing camel-jetty does not take that long.
>>> I would rather have a more stable and reliable build and test, than
>>> something that in some mysterious ways have errors which are caused by
>>> some side effects.
>>> I would like it to be reverted.
>>>> Willem
>>>> Christian Schneider wrote:
>>>>> Am 14.03.2010 10:42, schrieb Claus Ibsen:
>>>>>> Great this is good news. You can really get on a wild goose chase
>>>>>> testing is done without forking the JVM.
>>>>>> The bad news it takes much longer to test.
>>>>>> Well it does not take around 150 min to do a full build on my Mac.
>>>>>> used to be 120-130 min.
>>>>> Yes I also noticed the build takes longer now (about 240 minutes on my
>>>>> notebook). Perhaps the fork per test can be switched to a more moderate
>>>>> setting
>>>>> where we know the tests will work anyway.  There is another thing I also
>>>>> noticed. The fork per test hides some unclean shutdown sequences where
>>>>> all
>>>>> things are cleaned up. But I guess these could also be tested explicitly
>>>>> which is cleaner anyway. An example are the JMX tests which failed without
>>>>> the fork.
>>>>> I did not look into it in detail but I guess the JMX beans are not
>>>>> completely cleaned up on shutdown. Still I think it is a good thing that
>>>>> build runs stable now.
>>>>> Greetings
>>>>> Christian

View raw message