On Sun, Jan 20, 2013 at 7:52 PM, Raul Kripalani wrote:
> Hi,
>
> Discussion about those failures on this ticket: CAMEL-5974. I made an
> improvement on the threading model of the camel-jms component, but
> committed outdated code :( This morning I backed out the changes on both
> camel-2.10.x and
Yes, it makes sense.
BTW, It could be connivence for the people to know which version of camel-extra
works for the patch release version of camel.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.b
Karma granted. Verified email address associated to account to match the
asf records. It's actually your confluence (cwiki) account that gives
you permissions to change the wiki.
Thanks for your contributions,
Hadrian
On 01/20/2013 08:17 PM, Scott Cranton wrote:
I'm seeing a number of typos o
I'm seeing a number of typos on the doc pages that I'd like to fix such as
http://camel.apache.org/throttler.html
This option must be provided **and** a positive number => This option
must be provided **as** a positive number
and
http://camel.apache.org/message-filter.html
The property has the
+1
Sent from a mobile device
Am 20.01.2013 20:06 schrieb "Henryk Konsek" :
> > I dont think we need to fix camel-extra at every matching ASF Camel
> release.
> > There is a camel-extra 2.10.0 release and that is fine IMHO.
>
> Actually I would vote for syncing *all* releases of Extra Camel with
>
Hi
actually the trunk is currently not that much bad and again back to the
stable. The latest "Camel.trunk.fulltest" made it with one single failure:
https://builds.apache.org/job/Camel.trunk.fulltest/1197/
and "Camel.trunk.fulltest.java7" did it with 8 failures but only by
camel-sjms which was
> +1 for having discussion on mailing list.
Oh, and the idea with separated wiki pages - just great :) .
--
Henryk Konsek
http://henryk-konsek.blogspot.com
> Discussions *should* happen on the @dev mailing list, so everybody can
> be in the loop and participate.
> Its the Apache way.
+1 for having discussion on mailing list.
Not only due to the fact that I want to be in the loop, but also
because the discussion should be "googlable" for users intere
> I dont think we need to fix camel-extra at every matching ASF Camel release.
> There is a camel-extra 2.10.0 release and that is fine IMHO.
Actually I would vote for syncing *all* releases of Extra Camel with
ASF Camel. The pros are as follows:
a) It is more intuitive for end-users to use single
> Have in mind the trunk is already 2.11-SNAPSHOT. You have to create a
> camel-extra-2.10.x maintenane branch first and merge your changes from
> trunk into this branche.
Certainly, I am aware of this :) .
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Hi,
Discussion about those failures on this ticket: CAMEL-5974. I made an
improvement on the threading model of the camel-jms component, but
committed outdated code :( This morning I backed out the changes on both
camel-2.10.x and trunk. I'm now testing locally and will commit again
during this ev
The last successful build on Jenkins for Camel trunk full-test was on Dec.
13th - more than one month ago...
:-(
Best,
Christian
On Thu, Jan 17, 2013 at 6:28 PM, Hadrian Zbarcea wrote:
> I started dry run builds in preparation of release. There are a bunch of
> failures on my machine, especial
Did you also start the bundle? To my understanding a bundle-tracker is only
able to kick in when a bundle is fully resolved. Therefore a start is
needed. You might also do this right when installing with osgi:instll -s
mvn:
regards, Achim
2013/1/18 Claus Ibsen
> Hi
>
>
>
> On Fri, Jan 18,
Yes, that will work.
But as I understood from Guillaume, Karaf already provides the "feature
deployer". The question is: Why it doesn't work? ;-)
It would be great if you (or another Karaf committer) could have a look why
it doesn't work for Claus example.
Best,
Christian
On Sat, Jan 19, 2013 at
14 matches
Mail list logo
