camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Windows build completely working now
Date Mon, 15 Mar 2010 07:33:00 GMT
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 



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 
>> <> wrote:
>>> 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 if
>>>>> 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. It
>>>>> 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 not
>>>> 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 the
>>>> build runs stable now.
>>>> Greetings
>>>> Christian

View raw message