Thx Claus, I think that's really good to have separated the spring
stuff as it will allow blueprint users to not depend on spring at all
at testing.
Btw, I mentioned some time ago integration tests for archetypes, so
here's a pointer:
https://github.com/apache/karaf/blob/trunk/archetypes/itest
On Tue, Jan 24, 2012 at 4:36 PM, Hadrian Zbarcea wrote:
> Ok, let me clarify, there are a few points made here. Making camel-test
> standalone w/o spring dependencies is great, we should do that. Having a
> camel-test-spring is ok too and as you mentioned the primary audience for
> that would be S
On Wed, Jan 25, 2012 at 12:08 AM, Christian Müller
wrote:
> I like this improvement. This is the right way, IMO.
Yeah let me create a JIRA ticket so we capture this.
> I also share the opinion from Hadrian about the CamelSpringTestSupport.
> It's great for our users (I'm also one of them :-) )
I like this improvement. This is the right way, IMO.
I also share the opinion from Hadrian about the CamelSpringTestSupport.
It's great for our users (I'm also one of them :-) ) to test their routes.
And we need of course a few tests to make sure it works. We may need a few
more tests which have mo
Revision [3] is just the tip of the iceberg. There were other before
mostly related to using dynamic ports and proper cleanup that allowed
the forkMode='once'. One of the other components that would greatly
benefit from that is camel-jms.
On the hanging test on Windows, that's obviously an iss
Hadrian,
you mentioned a really good point regarding the improvements by camel-cxf
testing that I intended to bring into the discussion for today anyway:
Last night I was looking at my monitor as the full build on Windows (build
216) was running and was really stumped as the test:
org.apache.cam
Ok, let me clarify, there are a few points made here. Making camel-test
standalone w/o spring dependencies is great, we should do that. Having a
camel-test-spring is ok too and as you mentioned the primary audience
for that would be Spring *users*. The point I was making is that,
internally, we
On Tue, Jan 24, 2012 at 4:09 PM, Hadrian Zbarcea wrote:
> Actully, imo, a camel-test-spring should only be used for integration and by
> users, not for unit tests.
>
Do you mean Camel unit testing itself? Why should we not eat our own dog food?
camel-test-spring, is for any kind of Camel + Spri
Actully, imo, a camel-test-spring should only be used for integration
and by users, not for unit tests.
Hadrian
On 01/24/2012 06:16 AM, Claus Ibsen wrote:
On Tue, Jan 24, 2012 at 11:59 AM, Christian Müller
wrote:
In generall a good idea. But I doesn't like to lose the possibilities to
use t
On Tue, Jan 24, 2012 at 11:59 AM, Christian Müller
wrote:
> In generall a good idea. But I doesn't like to lose the possibilities to
> use the annotations like @EnpointInject, ...
>
https://issues.apache.org/jira/browse/CAMEL-4934 will allow to use the
Camel @EndpointInject annotations in pure Ja
In generall a good idea. But I doesn't like to lose the possibilities to
use the annotations like @EnpointInject, ...
One of my bigger intentions for Camel 2.10.0 is to speed up the tests (if
it's possible). In the past we was successful to reduce the time our unit
test needs. At present I don't h
11 matches
Mail list logo
