The Apache Jenkins build system has built Camel.trunk.notest (build #1590)
Status: Fixed
Check console output at https://builds.apache.org/job/Camel.trunk.notest/1590/
to view the results.
Hello Henryk, hello Dan,
@Henryk: Thanks for your work!
@Dan: I will go forward with this tomorrow (or may be Henryk if he find
some time) and change this line from the license header. Than I would
suggest to use the following license header:
/
+1
If Camel 2.11 is released in October (or may be later), I could imagine
Spring 3.1 is widely used.
Best,
Christian
On Tue, Jul 10, 2012 at 9:00 AM, Claus Ibsen wrote:
> Hi
>
> I wonder if we should upgrade Camel 2.11 to use Spring 3.1.x as
> default out of the box.
> Camel 2.11 should still
> Check my commit please :) .
>
> [1] Small version of license:
>
As I stated before, this license header is likely wrong. The code in the
files is most likely NOT copyright "Camel Extra Team" and thus that line
needs to be removed. Unless there is a specific copyright transfer, the
origi
> Ok done. I only need to reformat the POM XML to look nicer and then can
> commit.
Ok, commit submitted (rev896).
I've added 'withRatCheck' profile to the project so you can check it
against RAT validation issuing 'mvn install -PwithRatCheck'. This is a
good alternative for calling 'mvn
org.apa
On Tuesday, July 10, 2012 04:47:37 PM Łukasz Dywicki wrote:
> I am not sure if svnmerge is needed with git. With svn all informations
> about previous commits are lost after merge on new branch so it's hard to
> get the commits included in merge commit. With git where you have
> multiple branches y
I am not sure if svnmerge is needed with git. With svn all informations about
previous commits are lost after merge on new branch so it's hard to get the
commits included in merge commit. With git where you have multiple branches you
just use merge without fast forward. In this case issues can b
Hi again Johan,
If you are referring to the nested classes, yes, as the patterns of
reusability have appeared I have refactoring the code base. My initial
efforts started with trying to develop the pooling logic in a more generic
manner external to the producer and consumer classes but all the po
Hi Johan,
For me It comes down to the same reason as "why not Spring"; reduce
external dependencies and influences, increased resiliency & simplified
maintenance. Aside from creating a Camel JMS component free from the
Spring messaging APIs and its known limitations, one of my principal goals
in
The Apache Jenkins build system has built Camel.trunk.notest (build #1589)
Status: Still Failing
Check console output at https://builds.apache.org/job/Camel.trunk.notest/1589/
to view the results.
Hi Christian,
I'm pinging Olivier and the infra to see if we can do something.
I keep you posted.
Regards
JB
On 07/09/2012 11:37 PM, Christian Müller wrote:
Because ubuntu1, ubuntu2, ubuntu4 and ubuntu5 are down, many of the Apache
Camel build failed, e.g. this one [1].
Is there something we
Hi
I wonder if we should upgrade Camel 2.11 to use Spring 3.1.x as
default out of the box.
Camel 2.11 should still be compatible with Spring 3.0.x.
We just need to ensure the OSGi import range for camel-spring is [3,4)
etc. I think its already that.
In the old days with Spring 2.x we had some it
12 matches
Mail list logo
