I have nothing against that, but I was making a slightly different point. Coding a framework is different than coding an application. With the latter, one pretty much knows what to expect. With frameworks things are a bit more complicated. I can see how a developer in a long running, managed application, would create/start/stop a camel context multiple times. We should not have side effects from previous executions of the camel context, i.e. camel should cleanup after itself. Done right, it will also have the fringe benefit of not needing to instantiate a jvm pertest. Having 2 profiles with different testing strategies is fine.
Cheers, Hadrian On Mar 15, 2010, at 8:53 AM, Claus Ibsen wrote: > On Mon, Mar 15, 2010 at 1:10 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: >> 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. >> > > No I dont think this is a good way. We end up with having unforseen > side effects which causes all kind of pain trying to look into it and > thinking there is a real problem. > > I would suggest if its possible with Maven to have a profile for > testing without "per test" that people can run if they like to run a > faster test, but with the potential of unforseen sideeffects. > Then all the CI servers can chunk using per test and have a longer but > reliable test run. > > > >> My $0.02, >> Hadrian >> >> 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 <willem.ji...@gmail.com> >>>>> 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 >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus
