Yes, you're correct.
I've updated the wiki. Should take a little bit to refresh.
Thanks for catching that.
Christian
On Sat, Aug 17, 2013 at 1:36 PM, Zemian Deng wrote:
> Hi,
>
> On latest jdbc component it added named parameters feature, but the doc
> seems to have couple typo.
>
> http://c
Hi,
On latest jdbc component it added named parameters feature, but the doc
seems to have couple typo.
http://camel.apache.org/jdbc.html
1) The doc says use ":#param_name" format for named parameters binding, but
it doesn't work. It seems the code is expecting ":?param_name" format
instead. Howe
I just played with that maven plugin.
The problem is that it loads the properties after the validation phase.
That wont work:
4.0.0
just-test
version-test
1.0
org.codehaus.mojo
properties-maven-plugin
1.0-alpha-2
Hi
what I'm aware of for this purpose is the following plugin:
http://mojo.codehaus.org/properties-maven-plugin/usage.html
However it's not maintained anymore since 2009!
The other option would be to use the Kuali's plugin but I'm not sure about
it's licence (it's already available in central r
Sounds good. I will give it another try with Java 7 and make sure
appropriate profiles get enabled.
Thanks Babak!
On Saturday, August 17, 2013, Babak Vahdat wrote:
> Aha now I see, well if you make use of Java 7 and IntelliJ can't handle
> this
> then that sounds like a IntelliJ bug to me becaus
Aha now I see, well if you make use of Java 7 and IntelliJ can't handle this
then that sounds like a IntelliJ bug to me because in that case the apt
profile IS enabled and IntelliJ should take the apt module dependency into
account like any other POM dependencies. There was also a user reporting th
Very interesting. That sounds like lots of headaches, so keeping optional
is fine if it solves that.
I was just noticing in Intellij that it couldn't compile camel-sql because
it didn't bring in that dependency since it was marked optional. But that's
an easy headache to fix compared to the ones yo
Yes
We have many Camel components so it would be great for ppl if they can
see more easily which versions has changed, when they upgrade from
Camel 2.12.0 to 2.13.1
Camel 2.12.1 to 2.13.5
Camel 2.12.1 to 2.14.2
PS: Dont mind the version 2.13 and 2.14, just for demo purpose, to say
that you can
So, the goal here is to be able to provide a list of version numbers
that change much easier for any release?
On Sat, Aug 17, 2013 at 3:09 AM, Claus Ibsen wrote:
> On Sat, Aug 17, 2013 at 12:01 AM, Christian Müller
> wrote:
>> What do you propose the "list of all the camel components and some ot
Hi Christian,
I think having the optional flag set to true is indeed good as we used to
have problems to build & run the tests using Java 6 profile on the
CI-Server, e.g. the profile "Camel.trunk.fulltest". See also here:
https://github.com/apache/camel/blob/master/components/pom.xml#L221
Also n
On Sat, Aug 17, 2013 at 9:30 AM, Jan Matèrne (jhm) wrote:
>> > What do you propose the "list of all the camel components and some
>> > other stuff" should go?
>> >
>>
>> They should stay where they are. Its just all the versions that gets
>> moved into its own file, so the file ONLY has the versio
> > What do you propose the "list of all the camel components and some
> > other stuff" should go?
> >
>
> They should stay where they are. Its just all the versions that gets
> moved into its own file, so the file ONLY has the versions. And that
> makes the diff much easier.
Do you mean to exter
On Sat, Aug 17, 2013 at 12:01 AM, Christian Müller
wrote:
> What do you propose the "list of all the camel components and some other
> stuff" should go?
>
They should stay where they are. Its just all the versions that gets
moved into its own file, so the file ONLY has the versions. And that
make
13 matches
Mail list logo
