Hi Got home, sitting in the shade with a beer ;) and reading the mail.
What if we leave the *Support classes as is and just shrink the camel-core-tests.jar to contain what it should, only the support stuff. Then end-users have a nice and small .jar for unit testing with plain old junit POJU - Did I just make a new acrym there ;) Okay a 500kb jar is nothing today but end-users might get confused that it contain unit tests for camel-core and then can import some MyBean.class or whatever we have in this big jar. So if we can get Maven to package the jar without all that then it's great. Then later when the world is finally ready for something better than junit for unit testing then we can have xxxSupport classes in the camel-hamcrest or whatever is the norm. James I am biased towards your suggestions. Leave as is. Voting -1 And Med venlig hilsen Claus Ibsen ...................................... Silverbullet Skovsgårdsvænget 21 8362 Hørning Tlf. +45 2962 7576 Web: www.silverbullet.dk -----Original Message----- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: 2. juli 2008 17:00 To: camel-dev@activemq.apache.org Subject: Re: [VOTE] Release apache-camel-1.4 So I don't think the *Support classes should be in camel-core/src/main; they should stay in src/test so that camel-core builds fine; but if other modules wanna reuse them and we don't want to have folks reuse camel-core-test.jar we can copy them to camel-hamcrest. 2008/7/2 Willem Jiang <[EMAIL PROTECTED]>: > I see the recursive dependency, so I just upload a patch for *CAMEL-648 > </activemq/browse/CAMEL-648>*[1] by moving the *Support class into the main > directory and removing the dependecy of camel-core and camel-spring test > jars. > > Please review it. > > [1]https://issues.apache.org/activemq/browse/CAMEL-648 > > Willem > > James Strachan wrote: >> >> 2008/7/2 Willem Jiang <[EMAIL PROTECTED]>: >> >>> >>> We could set the scope to be test, it will not effect the compiling, >>> testing >>> and packaging. >>> Any thought ? >>> >> >> Am still thinking it might be a recursive dependency. >> >> Just stepping back a bit - whats the issue of camel-core-test.jar >> being big? Longer term I hope we can migrate most camel modules to use >> either spring-test or camel-hamcrest for testing and remove the >> dependency on camel-core-test.jar. Its just a tad complicated for the >> camel-core module due to circular dependencies (the *Support classes >> depend on the camel-core APIs and need to be built before camel-core >> can be tested etc); I wonder is it a biggie (since they are mostly >> legacy classes anyway) to just copy them into camel-hamcrest - but >> leave camel-core tests as it is? >> >> > > -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
