camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen">
Subject RE: [VOTE] Release apache-camel-1.4
Date Wed, 02 Jul 2008 15:11:39 GMT

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


Med venlig hilsen
Claus Ibsen
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
-----Original Message-----
From: James Strachan [] 
Sent: 2. juli 2008 17:00
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

2008/7/2 Willem Jiang <>:
> 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]
> Willem
> James Strachan wrote:
>> 2008/7/2 Willem Jiang <>:
>>> 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?


Open Source Integration

View raw message