Re: [Camel-MLLP] New Apache Camel Component

[Hadrian Zbarcea]

If I recall correctly the need for a more specialized mllp functionality 
with camel-hl7 was pointed out a few times in the past years in camel. 
There was even a contribution [1] that for some reason was not included.


From my direct interaction with the healthcare industry, camel is 
heavily used there. There are other components hosted by other 
organizations (I implemented myself a couple, not HL7 based, different 
protocols and codecs) and I think hosting them in Camel proper is a 
better option.


Since this proposal doesn't have any weird dependencies, I think it 
would be a good fit. I already looked at the code, there a few 
improvements I would recommend, but it looks good already.


If your intention is to donate the code, I would submit a PR.

Cheers,
Hadrian


[1] https://issues.apache.org/jira/browse/CAMEL-5296


On 12/10/2015 03:33 PM, Jamie G. wrote:

Hi All,

I've been working with Quinn Steveson upon a new Apache Camel
Component for working with MLLP endpoints.

The source code is currently a work in progress, however we'd like to
obtain feed back from the community. If this component appears to have
general interest, we'd like to discuss donating to the Apache Camel
community for inclusion with the rest of Camel components.

Git Repo:
https://github.com/hqstevenson/camel-mllp

Cheers,
Jamie

Re: Edit rights to Apache Confluence

[Hadrian Zbarcea]

Done.
Jyrki, please let me know if it doesn't work. Christian, enjoy the vacation.

Cheers,
Hadrian


On 11/22/2014 04:51 PM, Christian Müller wrote:

I'm in vacation without access to a PC/Mac. Could one of the other PMC
please grant the karma.

Best,
Christian
Am 21.11.2014 09:10 schrieb Jyrki Ruuskanen yur...@kotikone.fi:


Hi,

My ICLA has been received and filed at ASF. Now I would like to get edit
rights for Apache Confluence Wiki to write documentation on using Camel
with SCR as suggested by Claus Ibsen in https://issues.apache.org/
jira/browse/CAMEL-7997.

If possible I'd like to create the preliminary page in a personal space
before publishing it in Camel space.

My username in Apache Wiki and Apache JIRA is yuruki.

Regards,
Jyrki Ruuskanen

Re: [DISCUSS] - Camel 2.12.5 and 2.13.3 releases

[Hadrian Zbarcea]

Christian, I'll be a standby second if for whatever reason you won't be 
able to make it.


Thanks,
Hadrian


On 10/14/2014 03:39 PM, Christian Müller wrote:

I could do the 2.12.5 release (last planned patch release of the 2.12.x
branch).
If nobody has an important ticket which should be included, I will start
the release in 24 hours.

Best,
Christian


On Tue, Oct 14, 2014 at 3:21 AM, Willem Jiang willem.ji...@gmail.com
wrote:


Yeah, I totally agree with that.
As my schedule is occupied this two weeks, the release will be scheduled
at the last week of this month.
If other release managers have time before that, any help will be
appreciated.

--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem



On October 1, 2014 at 2:45:07 PM, Claus Ibsen (claus.ib...@gmail.com)
wrote:

Hi

Now that we have 2.14.0 out of the door, I think its time we do a
round of patch releases.

Camel 2.12.5 would be the last planned patch release of the 2.12.x

branch.

Camel 2.13.3 is a patch release.

Its 3 months ago since we last release patch releases for these two

branches.

Any thoughts?


--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/

Re: [VOTE] Release Apache Camel 2.12.3 (second try)

[Hadrian Zbarcea]

+1

Too late to count, but builds from sources produce the expected results 
with both Java 6 and Java 7. Signatures are good, features work, 
examples work.


Hadrian


On 02/25/2014 12:44 AM, Willem Jiang wrote:

The vote passes with:
[4] +1 (ningjiang, davsclaus, bvahdat, mueller)
[0] -1

I will proceed with publishing the artifacts today and make public
announcement of the release after the mirrors sync up.

Many thanks to all contributors,

--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/) 
(English)
http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem



On February 23, 2014 at 8:17:59 PM, Christian Müller 
(christian.muel...@gmail.com) wrote:
  
+1
  
The signatures are good and the manual looks good too.
  
Best,
  
Christian

-
  
Software Integration Specialist
  
Apache Member

V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
Apache Incubator PMC Member
  
https://www.linkedin.com/pub/christian-mueller/11/551/642
  
  
On Fri, Feb 21, 2014 at 3:59 PM, Willem Jiang wrote:
  

This is a vote to release Apache Camel 2.12.3, a patch release

coming

with about 140 issues fixed.

Release notes:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325593


Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-1004

Tarballs:

https://repository.apache.org/content/repositories/orgapachecamel-1004/org/apache/camel/apache-camel/2.12.3/


Tag:

https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=4bf31d2e2cbc34fda60d68c0dd33cb39d63ba1c6


Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.12.3
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem




  

Re: [CANCEL][VOTE] Release Apache Camel 2.12.3

[Hadrian Zbarcea]

My point is this: if we say that Camel supports 1.6 then it should be 
built with 1.6 with the expected results, including the html doc if we 
claim that to be part of the release. Otherwise we support 1.6 only for 
runtime, which is not what we say actually. I think this has to be 
clarified before the next 2.12.x release. Without this fixed, I will -1 
the next 2.12.x release, because part of testing the release I will 
build from sources.


Cheers,
Hadrian


On 02/20/2014 02:43 AM, Willem Jiang wrote:

Supports JDK 6 could mean from the source and binary level, but we still need 
to choice one version of JDK to build the kit. There is a known javadoc issue[1] which we 
cannot get fix from public released JDK6, so I prefer to build the kit with JDK7 and make 
sure the classes are target to 1.6.

I can cut a new version Camel 2.12.3 this week but we need to postpone the 
release of Camel 2.13.0 , as I don’t have enough time to do two release this 
month.

--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/) 
(English)
http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem



On February 20, 2014 at 11:03:42 AM, Hadrian Zbarcea (hzbar...@gmail.com) wrote:
  
While we had enough votes to pass this release I chose not to. I

don't
have cycles to cut another release in the next week week or so.
This
release is also blocking the AMQ release.
  
I would not release with 1.7 anyway, so maybe it would be a good

idea to
look into fixing the html doc stuff with 1.6 if it's that important
to
you guys. There are many users who rebuild Camel from sources
and what
you are saying is that while we support 1.6, we actually don't.
  
Cheers,

Hadrian
  
  
  
On 02/19/2014 09:53 PM, Hadrian Zbarcea wrote:

On 02/15/2014 11:16 PM, Hadrian Zbarcea wrote:

This is a vote to release Apache Camel 2.12.3, a patch release

coming

with about 128 issues fixed.

Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325593


Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-1002

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-1002/org/apache/camel/apache-camel/2.12.3/


Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=4bf31d2e2cbc34fda60d68c0dd33cb39d63ba1c6


Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.12.3
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian
  
  

Re: [VOTE] Release Apache Camel 2.12.3

[Hadrian Zbarcea]

Willem, if that problem was so important to you to block a release then 
it needs to be fixed. Until it's fixed I will -1 a release. It either is 
important or it isn't.


Hadrian

On 02/20/2014 12:26 PM, Willem Jiang wrote:

Hi Dan,

Thanks for the inputs.

The annotation is already RetentionPolicy.RUNTIME.

Current the html generator is based the APT processor, But it looks like
JDK6 has some trouble to load the APT processor when compile the code, I’m
not sure if I can fix it tomorrow.

At mean while, I suggest we can spend some time to address this JDK compile
issue after Camel 2.12.3 is released, so it won’t block the ActiveMQ
release.

Re: [RESULT][VOTE] Release Apache Camel 2.11.4

[Hadrian Zbarcea]

Yes, working on it.
Hadrian

On 02/20/2014 12:33 PM, Claus Ibsen wrote:

Hi

As 2.11.4 passed. Should we not add some notes on the Camel web site
and announce this release?
The JARs has been synced to maven central.
I assume the ASF mirror sync is done also?

On Wed, Feb 19, 2014 at 4:22 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:

The vote passes with:
[10] +1 (joed, bvahdat, joed, cschneider, cmueller, raulk, janstey, dkulp,
ningjiang, hadrian)
[1] +1 - non-binding (ceposta)
[0] -1

I will proceed with publishing the artifacts today and make public
announcement of the release tomorrow, after the mirrors sync up.

Many thanks to all contributors,
Hadrian



On 02/15/2014 11:16 PM, Hadrian Zbarcea wrote:

This is a vote to release Apache Camel 2.11.4, a patch release coming with
about 26 issues fixed.

Release notes:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325645

Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-1003/

Tarballs:

https://repository.apache.org/content/repositories/orgapachecamel-1003/org/apache/camel/apache-camel/2.11.4/

Tag:

https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=ae26285a0f597c6fdc8ab8fcc7a9d0cbae71567d

Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.11.4
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

Re: [VOTE] Release Apache Camel 2.12.3

[Hadrian Zbarcea]

Babak,

We're past the 72 hours mark and I would like to close this vote with a 
consensus is possible. Do you still think we have an issue, or you want 
to consider reverting your vote?


Cheers,
Hadrian


On 02/17/2014 05:06 AM, Babak Vahdat wrote:

Hi Willem,

can you please elaborate your explanation a bit? Currently what we've on the
2.12.x. as well as 2.11.x branches is this:

 cxf-version2.7.10/cxf-version
 cxf-version-range[2.6,2.9)/cxf-version-range

Now to my understanding this should become:

 cxf-version2.7.10/cxf-version
 cxf-version-range[2.6,3)/cxf-version-range

I think the current range is a problem for the OSGi folks because if e.g.
there's a bug-fix being provided in CXF 2.7.10, currently they can't force
the Container to make use of CXF 2.7.10 while they install the camel-cxf
feature version 2.12.3 or 2.11.4 (e.g. in the context of a dependency of
their own Karaf feature my-cool-app-karaf-feature) because the current
range does NOT include 2.7.10.

Babak


Willem.Jiang wrote

There are some patches of supporting CXF 3.x are not merged to
camel-2.12.x and camel-2.11.x.
So the cxf version rang of camel-2.12.x and camel-2.11.x is right.

I don’t think it’s a show-stopper.

--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem



On February 16, 2014 at 11:35:56 PM, Babak Vahdat (
babak.vahdat@
) wrote:
  
O.K. the build has been definetly done using Java 6 as this's how

MANIFEST.MF
of camel-core-2.12.3.jar looks like:
  
Manifest-Version: 1.0

Bnd-LastModified: 1392475192207
Build-Jdk: 1.6.0_45
Built-By: hadrian
...
  
  
Other than that the backport of the fix for CAMEL-7170 did NOT

adjust the
maven property accordingly, so on the
master branch
we've got:
  
2.7.10

[2.6,4.0)
  
Which is fine, however on the 2.12.x as well as the 2.11.x branch

we've got:
  
2.7.10

[2.6,2.9)
  
So here's my -1
  
Babak
  
  
Babak Vahdat wrote

Hi

The HTML component documentation inside the JARs are missing.

I assume

Java 6 has been used for building this release candidate. See

also the

first Note @ http://camel.apache.org/release-guide.html

Babak
hadrian wrote

This is a vote to release Apache Camel 2.12.3, a patch release

coming

with about 128 issues fixed.

Release notes:


https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325593

Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-1002

Tarballs:


https://repository.apache.org/content/repositories/orgapachecamel-1002/org/apache/camel/apache-camel/2.12.3/

Tag:


https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=4bf31d2e2cbc34fda60d68c0dd33cb39d63ba1c6

Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.12.3
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian
  
  
  
  
  
--

View this message in context:
http://camel.465427.n5.nabble.com/VOTE-Release-Apache-Camel-2-12-3-tp5747361p5747375.html
Sent from the Camel Development mailing list archive at Nabble.com.






--
View this message in context: 
http://camel.465427.n5.nabble.com/VOTE-Release-Apache-Camel-2-12-3-tp5747361p5747421.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: [VOTE] Release Apache Camel 2.11.4

[Hadrian Zbarcea]

Forgot my +1.

On 02/15/2014 11:16 PM, Hadrian Zbarcea wrote:
This is a vote to release Apache Camel 2.11.4, a patch release coming 
with about 26 issues fixed.


Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325645 



Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-1003/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-1003/org/apache/camel/apache-camel/2.11.4/ 



Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=ae26285a0f597c6fdc8ab8fcc7a9d0cbae71567d 



Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.11.4
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

[RESULT][VOTE] Release Apache Camel 2.11.4

[Hadrian Zbarcea]

The vote passes with:
[10] +1 (joed, bvahdat, joed, cschneider, cmueller, raulk, janstey, 
dkulp, ningjiang, hadrian)

[1] +1 - non-binding (ceposta)
[0] -1

I will proceed with publishing the artifacts today and make public 
announcement of the release tomorrow, after the mirrors sync up.


Many thanks to all contributors,
Hadrian


On 02/15/2014 11:16 PM, Hadrian Zbarcea wrote:
This is a vote to release Apache Camel 2.11.4, a patch release coming 
with about 26 issues fixed.


Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325645 



Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-1003/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-1003/org/apache/camel/apache-camel/2.11.4/ 



Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=ae26285a0f597c6fdc8ab8fcc7a9d0cbae71567d 



Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.11.4
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

Re: [VOTE] Release Apache Camel 2.12.3

[Hadrian Zbarcea]

Babak, per the ASF policy we can release 2.12.3 even with -1s.
However, I usually shoot for consensus. Here's what I am going to do in 
this case, because yours is the only -1 with an overwhelming majority of 
+1s. I'll give it another 12 hours and if nothing changes I will close 
the vote and release 2.12.3. If within this time you convince another 
PMC member to change his vote I will cancel this vote.


We had two releases in the past, years ago (1.4 and 1.5 time) that were 
built with a newer version that the oldest supported and we got burned 
by the version of the class file format. (I was the one who messed up, 
had to redo the releases and learned my lesson). I personally don't 
release with a newer java version than the oldest supported.


Cheers,
Hadrian

[1] http://www.apache.org/dev/release.html


On 02/19/2014 10:19 AM, Babak Vahdat wrote:

Hi Harian,

I'm actually still -1 to this release candidate as the HTML documentation
inside the bundles are missing (as a side effect of Java 6 being used for
building instead of Java 7). This requirement has been clearly stated inside
our release guides (yes, I was the one who added that note):

http://camel.apache.org/release-guide.html

And we've also discussed this many times @ the dev-forum as well:

http://camel.465427.n5.nabble.com/improving-Endpoint-documentation-and-tooling-td5731334.html
http://camel.465427.n5.nabble.com/Our-builds-looks-really-bad-tp5731673p5731743.html

That all said, I may sound too pedantic, sorry for that!

Last but not least I ask for apologies by the Apache Camel PMC because of
the STUPID mistake I made while voting for the 2.11.4 release candidate:

http://camel.465427.n5.nabble.com/VOTE-Release-Apache-Camel-2-11-4-tp5747362p5747430.html

As I had A LOT OF BEERS the night before that vote of mine. So I guess that
was why my brain went terribly wrong :)

Many thanks for your effort to prepare these two release candidates!

Babak


hadrian wrote

Babak,

We're past the 72 hours mark and I would like to close this vote with a
consensus is possible. Do you still think we have an issue, or you want
to consider reverting your vote?

Cheers,
Hadrian


On 02/17/2014 05:06 AM, Babak Vahdat wrote:

Hi Willem,

can you please elaborate your explanation a bit? Currently what we've on
the
2.12.x. as well as 2.11.x branches is this:

  

cxf-version
2.7.10
/cxf-version
  

cxf-version-range
[2.6,2.9)
/cxf-version-range

Now to my understanding this should become:

  

cxf-version
2.7.10
/cxf-version
  

cxf-version-range
[2.6,3)
/cxf-version-range

I think the current range is a problem for the OSGi folks because if e.g.
there's a bug-fix being provided in CXF 2.7.10, currently they can't
force
the Container to make use of CXF 2.7.10 while they install the
camel-cxf
feature version 2.12.3 or 2.11.4 (e.g. in the context of a dependency of
their own Karaf feature my-cool-app-karaf-feature) because the current
range does NOT include 2.7.10.

Babak


Willem.Jiang wrote

There are some patches of supporting CXF 3.x are not merged to
camel-2.12.x and camel-2.11.x.
So the cxf version rang of camel-2.12.x and camel-2.11.x is right.

I don’t think it’s a show-stopper.

--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem



On February 16, 2014 at 11:35:56 PM, Babak Vahdat (
babak.vahdat@
) wrote:
   
O.K. the build has been definetly done using Java 6 as this's how

MANIFEST.MF
of camel-core-2.12.3.jar looks like:
   
Manifest-Version: 1.0

Bnd-LastModified: 1392475192207
Build-Jdk: 1.6.0_45
Built-By: hadrian
...
   
   
Other than that the backport of the fix for CAMEL-7170 did NOT

adjust the
maven property accordingly, so on the
master branch
we've got:
   
2.7.10

[2.6,4.0)
   
Which is fine, however on the 2.12.x as well as the 2.11.x branch

we've got:
   
2.7.10

[2.6,2.9)
   
So here's my -1
   
Babak
   
   
Babak Vahdat wrote

Hi

The HTML component documentation inside the JARs are missing.

I assume

Java 6 has been used for building this release candidate. See

also the

first Note @ http://camel.apache.org/release-guide.html

Babak
hadrian wrote

This is a vote to release Apache Camel 2.12.3, a patch release

coming

with about 128 issues fixed.

Release notes:


https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325593

Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-1002

Tarballs:


https://repository.apache.org/content/repositories/orgapachecamel-1002/org/apache/camel/apache-camel/2.12.3/

Tag:


https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=4bf31d2e2cbc34fda60d68c0dd33cb39d63ba1c6

Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.12.3
[ ] -1 Veto the release (provide specific comments)
Vote is open for at 

[CANCEL][VOTE] Release Apache Camel 2.12.3

[Hadrian Zbarcea]

On 02/15/2014 11:16 PM, Hadrian Zbarcea wrote:
This is a vote to release Apache Camel 2.12.3, a patch release coming 
with about 128 issues fixed.


Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325593 



Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-1002

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-1002/org/apache/camel/apache-camel/2.12.3/ 



Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=4bf31d2e2cbc34fda60d68c0dd33cb39d63ba1c6 



Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.12.3
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

Re: [CANCEL][VOTE] Release Apache Camel 2.12.3

[Hadrian Zbarcea]

While we had enough votes to pass this release I chose not to. I don't 
have cycles to cut another release in the next week week or so. This 
release is also blocking the AMQ release.


I would not release with 1.7 anyway, so maybe it would be a good idea to 
look into fixing the html doc stuff with 1.6 if it's that important to 
you guys. There are many users who rebuild Camel from sources and what 
you are saying is that while we support 1.6, we actually don't.


Cheers,
Hadrian



On 02/19/2014 09:53 PM, Hadrian Zbarcea wrote:

On 02/15/2014 11:16 PM, Hadrian Zbarcea wrote:
This is a vote to release Apache Camel 2.12.3, a patch release coming 
with about 128 issues fixed.


Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325593 



Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-1002

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-1002/org/apache/camel/apache-camel/2.12.3/ 



Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=4bf31d2e2cbc34fda60d68c0dd33cb39d63ba1c6 



Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.12.3
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

[VOTE] Release Apache Camel 2.11.4

[Hadrian Zbarcea]

This is a vote to release Apache Camel 2.11.4, a patch release coming 
with about 26 issues fixed.


Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325645 



Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-1003/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-1003/org/apache/camel/apache-camel/2.11.4/ 



Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=ae26285a0f597c6fdc8ab8fcc7a9d0cbae71567d

Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.11.4
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

[VOTE] Release Apache Camel 2.12.3

[Hadrian Zbarcea]

This is a vote to release Apache Camel 2.12.3, a patch release coming 
with about 128 issues fixed.


Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325593

Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-1002

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-1002/org/apache/camel/apache-camel/2.12.3/

Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=4bf31d2e2cbc34fda60d68c0dd33cb39d63ba1c6

Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.12.3
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

[HEADS-UP] Camel 2.12.3 and 2.11.4

[Hadrian Zbarcea]

Hi,

I am planning on releasing patch versions later in the afternoon today 
(it may spill into the weekend). Any objections or other patches you 
still need to get in?


Cheers,
Hadrian

Re: git commit: Update to qpid 0.24. Expand test to test both 0.10/0.9 client and the new 1.0 client.

[Hadrian Zbarcea]

Dan,

I assume this is re: CAMEL-5891 [1]. I assigned it to you. Please add 
the issue id in the commit comment.


Cheers,
Hadrian

[1] https://issues.apache.org/jira/browse/CAMEL-5891


On 02/07/2014 01:10 PM, dk...@apache.org wrote:

Updated Branches:
   refs/heads/master f74e28160 - 5ecbfe920


Update to qpid 0.24.   Expand test to test both 0.10/0.9 client and the new 1.0 
client.


Project: http://git-wip-us.apache.org/repos/asf/camel/repo
Commit: http://git-wip-us.apache.org/repos/asf/camel/commit/5ecbfe92
Tree: http://git-wip-us.apache.org/repos/asf/camel/tree/5ecbfe92
Diff: http://git-wip-us.apache.org/repos/asf/camel/diff/5ecbfe92

Branch: refs/heads/master
Commit: 5ecbfe920eefe7336092c1d623f579230db08a00
Parents: f74e281
Author: Daniel Kulp dk...@apache.org
Authored: Fri Feb 7 13:05:30 2014 -0500
Committer: Daniel Kulp dk...@apache.org
Committed: Fri Feb 7 13:09:57 2014 -0500

--
  components/camel-amqp/pom.xml   | 10 +
  .../camel/component/amqp/AMQPComponent.java | 22 
  .../camel/component/amqp/AMQPRouteTest.java | 19 ++---
  .../camel-amqp/src/test/resources/config.json   |  2 +-
  parent/pom.xml  |  2 +-
  5 files changed, 38 insertions(+), 17 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/camel/blob/5ecbfe92/components/camel-amqp/pom.xml
--
diff --git a/components/camel-amqp/pom.xml b/components/camel-amqp/pom.xml
index bdd9d3c..e054f8d 100644
--- a/components/camel-amqp/pom.xml
+++ b/components/camel-amqp/pom.xml
@@ -46,13 +46,15 @@
  /dependency
  dependency
groupIdorg.apache.qpid/groupId
-  artifactIdqpid-client/artifactId
+  artifactIdqpid-amqp-1-0-client-jms/artifactId
version${qpid-version}/version
+  optionaltrue/optional
  /dependency
  dependency
-  groupIdorg.apache.qpid/groupId
-  artifactIdqpid-common/artifactId
-  version${qpid-version}/version
+groupIdorg.apache.qpid/groupId
+artifactIdqpid-client/artifactId
+version${qpid-version}/version
+optionaltrue/optional
  /dependency
  
  !-- testing --


http://git-wip-us.apache.org/repos/asf/camel/blob/5ecbfe92/components/camel-amqp/src/main/java/org/apache/camel/component/amqp/AMQPComponent.java
--
diff --git 
a/components/camel-amqp/src/main/java/org/apache/camel/component/amqp/AMQPComponent.java
 
b/components/camel-amqp/src/main/java/org/apache/camel/component/amqp/AMQPComponent.java
index cfd77e0..cd37132 100644
--- 
a/components/camel-amqp/src/main/java/org/apache/camel/component/amqp/AMQPComponent.java
+++ 
b/components/camel-amqp/src/main/java/org/apache/camel/component/amqp/AMQPComponent.java
@@ -16,10 +16,16 @@
   */
  package org.apache.camel.component.amqp;
  
+import java.net.MalformedURLException;

+import java.net.URISyntaxException;
+
+import javax.jms.ConnectionFactory;
+
  import org.apache.camel.CamelContext;
  import org.apache.camel.Component;
  import org.apache.camel.component.jms.JmsComponent;
  import org.apache.camel.component.jms.JmsConfiguration;
+import org.apache.qpid.amqp_1_0.jms.impl.ConnectionFactoryImpl;
  import org.apache.qpid.client.AMQConnectionFactory;
  import org.apache.qpid.url.URLSyntaxException;
  
@@ -41,13 +47,21 @@ public class AMQPComponent extends JmsComponent {

  super(context);
  }
  
-public AMQPComponent(AMQConnectionFactory connectionFactory) {

+public AMQPComponent(ConnectionFactory connectionFactory) {
  setConnectionFactory(connectionFactory);
  }
  
-public static Component amqpComponent(String uri) throws URLSyntaxException {

-AMQConnectionFactory connectionFactory = new AMQConnectionFactory(uri);
-return new AMQPComponent(connectionFactory);
+public static Component amqpComponent(String uri, boolean old) throws 
MalformedURLException, URISyntaxException {
+if (old) {
+return amqpComponentOld(uri);
+}
+return new AMQPComponent(ConnectionFactoryImpl.createFromURL(uri));
+}
+public static Component amqpComponentOld(String uri) throws 
URISyntaxException {
+return new AMQPComponent(new AMQConnectionFactory(uri));
+}
+public static Component amqpComponent(String uri) throws 
MalformedURLException {
+return new AMQPComponent(ConnectionFactoryImpl.createFromURL(uri));
  }
  
  }


http://git-wip-us.apache.org/repos/asf/camel/blob/5ecbfe92/components/camel-amqp/src/test/java/org/apache/camel/component/amqp/AMQPRouteTest.java
--
diff --git 

Re: [DISCUSS] release date for either 2.12.3 or 2.13.0

[Hadrian Zbarcea]

I have a few issues assigned to me. Please don't move them, the 
camel-kafka component in particular (but not only).


Thanks,
Hadrian


On 02/04/2014 12:33 PM, Christian Müller wrote:

I just upgraded my local workspace to CXF 2.7.9 which I would like to see
in the next Camel versions [1]. The test suite is still running...

Afterwards I would like to give Camel 2.12.3 a dry run...

At present, we have 8 outstanding issues for 2.12.3 [2] (my one included).
Only one is classified as bug [3], but with minor priority. Any problems
with moving these issues to 2.12.4?

[1] https://issues.apache.org/jira/browse/CAMEL-7170
[2]
https://issues.apache.org/jira/browse/CAMEL-6807?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%20%222.12.3%22%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29
[3] https://issues.apache.org/jira/browse/CAMEL-6807

Best,
Christian
-

Software Integration Specialist

Apache Member
V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
Apache Incubator PMC Member

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Tue, Feb 4, 2014 at 9:39 AM, Claus Ibsen claus.ib...@gmail.com wrote:


On Mon, Feb 3, 2014 at 5:48 PM, Jack jrmpatw...@gmail.com wrote:

Hi,

Can anyone tell me when either of these planned releases (2.12.3, 2.13.0)
will be happening?


Later this year :)

Okay people is busy and there is winter vacation for some and others
have chinese new-year.
But a new batch of releases for 2.12 / 2.11 and likely 2.13 is being
discussed and released in due time.
Hopefully later this month, but surely the aim would be for releases
out in Q1 2014.



We¹re affected by the memory leak in the BacklogTracer and just need to

know

how long it will be before a fix is released.
https://issues.apache.org/jira/browse/CAMEL-7062


You can just patch it yourself and then upgrade when there is a public
release.




Thanks,

Jack





--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Make your Camel applications look hawt, try: http://hawt.io

Re: [DISCUSS] Remove the camel:dot goal

[Hadrian Zbarcea]

This was a discuss thread. Since it wasn't a vote, there was no formal 
[result] message. I assume that the reason for the end of discussion is 
that nobody had anything to add. The not so lazy consensus was to remove 
the camel:dot goal.


The only one who expressed an opinion as to when to remove the camel:dot 
goal was you, Babak. As nobody challenged your request it will be done 
for 2.13.0. We should probably document it as deprecated now, although 
it doesn't matter too much, as it hasn't been used since forever. Feel 
free to take care of it if you want, although there's plenty of time 
until the release.


I hope my $0.02 are of some help,
Hadrian


On 01/12/2014 05:26 AM, Babak Vahdat wrote:

Hi

Does anybody know where we ended up with this?

Babak


Babak Vahdat wrote

+1 for 2.13.0

Babak
hadrian wrote

The camel:dot goal provided by the camel-maven-plugin has not been
maintained in 5+ years, produces poor quality output and, most
importantly, doesn't seem to be used. I propose to remove it.

Hadrian






--
View this message in context: 
http://camel.465427.n5.nabble.com/DISCUSS-Remove-the-camel-dot-goal-tp5744057p5745865.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: [DISCUSS] Remove the camel:dot goal

[Hadrian Zbarcea]

Even better. Thanks,
Hadrian

On 01/12/2014 07:04 PM, Babak Vahdat wrote:

Hi

Actually we've already marked this as deprecated since ages (see the section
... is *@deprecated*.):


http://camel.465427.n5.nabble.com/CONF-Apache-Camel-gt-Camel-Maven-Plugin-td5715931.html

However as a result of the recent css/javascript changes on the website
itself that's probably not that much readable:

http://camel.apache.org/camel-maven-plugin.html

Babak


hadrian wrote

This was a discuss thread. Since it wasn't a vote, there was no formal
[result] message. I assume that the reason for the end of discussion is
that nobody had anything to add. The not so lazy consensus was to remove
the camel:dot goal.

The only one who expressed an opinion as to when to remove the camel:dot
goal was you, Babak. As nobody challenged your request it will be done
for 2.13.0. We should probably document it as deprecated now, although
it doesn't matter too much, as it hasn't been used since forever. Feel
free to take care of it if you want, although there's plenty of time
until the release.

I hope my $0.02 are of some help,
Hadrian


On 01/12/2014 05:26 AM, Babak Vahdat wrote:

Hi

Does anybody know where we ended up with this?

Babak


Babak Vahdat wrote

+1 for 2.13.0

Babak
hadrian wrote

The camel:dot goal provided by the camel-maven-plugin has not been
maintained in 5+ years, produces poor quality output and, most
importantly, doesn't seem to be used. I propose to remove it.

Hadrian






--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-Remove-the-camel-dot-goal-tp5744057p5745865.html
Sent from the Camel Development mailing list archive at Nabble.com.







--
View this message in context: 
http://camel.465427.n5.nabble.com/DISCUSS-Remove-the-camel-dot-goal-tp5744057p5745870.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: [VOTE] Release Apache Camel 2.11.3

[Hadrian Zbarcea]

+1


On Tue, Jan 7, 2014 at 7:09 PM, Hadrian Zbarcea hadr...@apache.org wrote:

A bit overdue, this is a vote to release Apache Camel 2.11.3, a patch
release coming with about 116 issues fixed.

Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325024

Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-019/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-019/org/apache/camel/apache-camel/2.11.3/

Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=e2c2c7db74dc8f3409df74618946ead72b05733b

Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.11.3
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

[RESULT][VOTE] Release Apache Camel 2.11.3

[Hadrian Zbarcea]

The vote passes with:
[7] +1 (dkulp, ningjiang, joed, janstey, hadrian, bvahdat, cmueller)
[1] +1 - non-binding (ceposta)
[0] -1

I will proceed with publishing the artifacts today and make public 
announcement of the release tomorrow, after the mirrors sync up.


Many thanks to all contributors,
Hadrian


On 01/07/2014 10:09 PM, Hadrian Zbarcea wrote:

A bit overdue, this is a vote to release Apache Camel 2.11.3, a patch
release coming with about 116 issues fixed.

Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325024


Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-019/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-019/org/apache/camel/apache-camel/2.11.3/


Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=e2c2c7db74dc8f3409df74618946ead72b05733b


Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.11.3
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

[VOTE] Release Apache Camel 2.11.3

[Hadrian Zbarcea]

A bit overdue, this is a vote to release Apache Camel 2.11.3, a patch 
release coming with about 116 issues fixed.


Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325024

Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-019/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-019/org/apache/camel/apache-camel/2.11.3/

Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=e2c2c7db74dc8f3409df74618946ead72b05733b

Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.11.3
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

Re: git commit: CAMEL-7023: Added hawtio goal to camel maven plugin.

[Hadrian Zbarcea]

There are two outstanding vetoes. Please revert the patch until the 
conclusion of this discussion.


Hadrian


On 12/01/2013 03:46 AM, Rob Davies wrote:

dk...@apache.org wrote

Having no way for this PMC to control the display of the Camel route *IS*
a technical justification.   If we as a PMC wanted to remove columns, add
new columns for new features, change the order of stuff, etc….   *WE* have
no way to do so.

Having no way to change the branding of what is displayed *IS* a technical
justification.   We cannot have links popping up and icons and such that
promote something else.

Having no way to remove all the “cruft” that is unrelated to Camel *IS*  a
technical justification.   Claus’s screen shot on the wiki has an AcitveMQ
tab, Wiki tab, etc…  which would need to be removed if the goal is to have
a Camel route display.

That’s all technical justification.This needs to be removed until they
can all be addressed.

Oh… and the maven goal cannot be camel:hawtio.   It would need to be
camel:run-webconsole or similar to remove the branding part from that as
well.


So any 3rd party tool that aids developers, can't be run as a maven target
unless its completely branded and controlled by the Camel PMC is the stance
you are taking.





--
View this message in context: 
http://camel.465427.n5.nabble.com/Re-git-commit-CAMEL-7023-Added-hawtio-goal-to-camel-maven-plugin-tp5744029p5744126.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: git commit: CAMEL-7023: Added hawtio goal to camel maven plugin.

[Hadrian Zbarcea]

While we discuss, with two vetoes pending, first step is to revert the 
patch.


Cheers,
Hadrian


On 11/30/2013 02:35 AM, Robert Davies wrote:

It seems a couple of people are getting a head of themselves.
Firstly, the -1 vote  of Dan and Hadrian are invalid without a technical 
justification,  and it seems they are trying to justify a -1 on some policy by 
the Camel PMC that I for one are not aware of.
We have discussed removing the camel console [1], but that discussion is 
insufficient to cover the case of adding a maven target to different console - 
its not being distributed as part of Apache Camel, its just making it easier to 
run if you want to.  I understand the concerns about hawtio,  but lets discuss 
that first - and on a different thread and get some formality into this please.

Rob
[1] 
http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-Does-camel-need-a-web-console-tt5726280.html#a5727053

On 29 Nov 2013, at 18:07, Daniel Kulp dk...@apache.org wrote:



On Nov 28, 2013, at 8:42 AM, James Strachan james.strac...@gmail.com wrote:


Should we back out the use of graphviz too? Do you think generating images
for camel routes should be -1'd too?


No.   Graphviz is a graphics library.   ALL the code for taking the camel 
routes and feeding the information into graphiz lives in camel and is under the 
Camel PMC control and direction.   How the graph is presented to the user is 
under the Camel PMC direction.   Thus, it’s “OK”.

In this case, all of the code for presenting the Camel UI is NOT in control of 
the Camel PMC.   It’s not part of Camel.  It’s completely under the control of 
an external party.   That is NOT OK.

If HawtIO was just a console framework (or whatever you want to call it) and 
all of the “Camel” value-add was a plugin or was built upon that and that code 
was in Camel, I’d have “less” of a concern (certain branding and links and doc 
things would need to be resolved as well).Basically, if it was like Spring 
where Spring has a core and all the camel value add stuff to spring (namespace 
handlers, spring integration stuff, etc…) is part of Camel, then it would be OK.

So, in summary, if a user wants a nice graphics view of a Camel route, as far 
as the Camel project goes, there are three options:

1) Claim it’s not an issue and do nothing…..   It’s not one of our “itches” for 
us to scratch.

2) Claim it is an issue, but outside the scope of our project and point people 
the third party applications page we have on the website for options that are 
available.

3) Expand the scope of Camel to include this, but in this case, it HAS to be 
controlled, managed, documented,  branded, etc…. completely by the Camel PMC.  
How it’s presented to the user, etc… must be completely “Apache Camel”, not 
hawtio or what ever.


Take your pick.

Dan




On 28 November 2013 13:41, James Strachan james.strac...@gmail.com wrote:


On 28 November 2013 13:32, Daniel Kulp dk...@apache.org wrote:



I’m -1 to this commit.   I don’t think we should be adding a bunch of
targets for all the various container/platform integrations.



If that were true I'd maybe -1 it too; but this commit looks to be about
making it easy for Camel users to visualise  debug Camel routes in a web
browser - from inside their existing maven camel project. i.e. its a camel
thing; just needs a web server to host some static HTML/CSS/JS (which is
purely an implementation detail).

Though its nothing really to do with mimicking runtime platforms like
tomcat:run / karaf:run / jetty:run.

--
James
---
Red Hat

Email: jstra...@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration





--
James
---
Red Hat

Email: jstra...@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration


--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Rob Davies
-
Red Hat, Inc
Twitter: rajdavies
Blog: http://rajdavies.blogspot.com
ActiveMQ in Action: http://www.manning.com/snyder/

Re: git commit: CAMEL-7023: Added hawtio goal to camel maven plugin.

[Hadrian Zbarcea]

Actually, funny you should ask. The camel:dot goal (DotMojo.java) has 
not been maintained for 5+ years, is not used and produces output of 
very poor quality.


We agreed to remove the camel console from the camel distro and RedHat 
intends, I assume, to promote the hawtio solution. Other parties may 
promote their own. That should happen outside the Apache Camel project. 
I think that was Dan's point, which I consider valid. Please feel free 
to create a maven-hawtio-plugin with whatever goodies you deem useful.


Here's a -1 from me too [1]. And a +1 to removing the DotMojo. I will 
start a separate thread proposing to remove it.


Hadrian

[1] http://www.apache.org/foundation/voting.html#Veto


On 11/28/2013 08:42 AM, James Strachan wrote:

Should we back out the use of graphviz too? Do you think generating images
for camel routes should be -1'd too?


On 28 November 2013 13:41, James Strachan james.strac...@gmail.com wrote:


On 28 November 2013 13:32, Daniel Kulp dk...@apache.org wrote:



I’m -1 to this commit.   I don’t think we should be adding a bunch of
targets for all the various container/platform integrations.



If that were true I'd maybe -1 it too; but this commit looks to be about
making it easy for Camel users to visualise  debug Camel routes in a web
browser - from inside their existing maven camel project. i.e. its a camel
thing; just needs a web server to host some static HTML/CSS/JS (which is
purely an implementation detail).

Though its nothing really to do with mimicking runtime platforms like
tomcat:run / karaf:run / jetty:run.

--
James
---
Red Hat

Email: jstra...@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration

[DISCUSS] Remove the camel:dot goal

[Hadrian Zbarcea]

The camel:dot goal provided by the camel-maven-plugin has not been 
maintained in 5+ years, produces poor quality output and, most 
importantly, doesn't seem to be used. I propose to remove it.


Hadrian

Re: [ANNOUNCE] Apache Camel 2.12.2 Released

[Hadrian Zbarcea]

My mistake. Sorry and thanks David for reporting so quickly. It's fixed 
now, the site should refresh in a couple of hours.


Hadrian

On 11/27/2013 07:43 PM, David Karlsen wrote:

The release page has wrong link (version) into JIRA for the fixed issues
28. nov. 2013 01:03 skrev hadr...@apache.org følgende:


The Apache Camel project [1] is a powerful open source integration
framework based on known Enterprise Integration Patterns [2].

The Camel community announces the immediate availability of the new patch
release camel-2.12.2.

The artifacts are published and ready for you to download [3] either from
the Apache mirrors or from the Central Maven repository.
For more details please take a look at the release notes [4].

Many thanks to the Camel community for the hard work.

Hadrian

[1] http://camel.apache.org/
[2] http://camel.apache.org/enterprise-integration-patterns.html
[3] http://camel.apache.org/download.html
[4] http://camel.apache.org/camel-2122-release.html

Re: [VOTE] Release Apache Camel 2.12.2

[Hadrian Zbarcea]

+1
Hadrian

On 11/22/2013 10:52 PM, Hadrian Zbarcea wrote:

This is a vote to release Apache Camel 2.12.2, a patch release coming
with about 143 issues fixed.

Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325018


Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-167/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-167/org/apache/camel/apache-camel/2.12.2/


Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=3b7a3c635fe568571a5c96560ff320fada5198e4


Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.12.2
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

[RESULT][VOTE] Release Apache Camel 2.12.2

[Hadrian Zbarcea]

The vote passes with:
[5] +1 (ningjiang, davsclaus, hadrian, cschneider, cmueller)
[2] +1 - non-binding (ay, scranton)
[0] -1

I will proceed with publishing the artifacts today and make public 
announcement of the release tomorrow, after the mirrors sync up.


Many thanks to all contributors,
Hadrian

On 11/22/2013 10:52 PM, Hadrian Zbarcea wrote:

This is a vote to release Apache Camel 2.12.2, a patch release coming
with about 143 issues fixed.

Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325018


Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-167/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-167/org/apache/camel/apache-camel/2.12.2/


Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=3b7a3c635fe568571a5c96560ff320fada5198e4


Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.12.2
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

Re: [DISCUSS] - Apache Camel 2.12.2 release later this month?

[Hadrian Zbarcea]

Done. Next is camel-2.11.3 this week.
Hadrian


On 11/22/2013 10:44 PM, Hadrian Zbarcea wrote:

The release is done, but for some reason the apache repo doesn't let me
close the staging repo:

The server did not close the staging repository.
Nexus returned an error: ERROR 502: Proxy Error

I'll try again in the morning and take it with infra if necessary. I
will start the vote as soon as the staging repo is closed.

Hadrian


On 11/11/2013 01:33 PM, Claus Ibsen wrote:

Hi

I think we should cut a new 2.12.2 release later this month. We have
so far 115 jira's resolved.

Any thoughts?

Re: git commit: CAMEL-6987: Fixed browse as xml not returning files if includeBody=true.

[Hadrian Zbarcea]

For some reason, the context for me is localhost/camel-1.
I fixed the test, but I am curious how this works for others now.
This is I think/hope the last failing test and now I can cut the release.


Hadrian


On 11/20/2013 10:42 AM, davscl...@apache.org wrote:

Updated Branches:
   refs/heads/master f29888779 - 37e0e6bb8


CAMEL-6987: Fixed browse as xml not returning files if includeBody=true.


Project: http://git-wip-us.apache.org/repos/asf/camel/repo
Commit: http://git-wip-us.apache.org/repos/asf/camel/commit/37e0e6bb
Tree: http://git-wip-us.apache.org/repos/asf/camel/tree/37e0e6bb
Diff: http://git-wip-us.apache.org/repos/asf/camel/diff/37e0e6bb

Branch: refs/heads/master
Commit: 37e0e6bb8371f313db3d5d2642288acfa645b8db
Parents: f298887
Author: Claus Ibsen davscl...@apache.org
Authored: Wed Nov 20 16:44:05 2013 +0100
Committer: Claus Ibsen davscl...@apache.org
Committed: Wed Nov 20 16:44:05 2013 +0100

--
  .../org/apache/camel/util/MessageHelper.java|  4 +-
  .../ManagedBrowsableEndpointAsXmlFileTest.java  | 67 
  2 files changed, 70 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/camel/blob/37e0e6bb/camel-core/src/main/java/org/apache/camel/util/MessageHelper.java
--
diff --git a/camel-core/src/main/java/org/apache/camel/util/MessageHelper.java 
b/camel-core/src/main/java/org/apache/camel/util/MessageHelper.java
index 3e38d23..c81b53b 100644
--- a/camel-core/src/main/java/org/apache/camel/util/MessageHelper.java
+++ b/camel-core/src/main/java/org/apache/camel/util/MessageHelper.java
@@ -223,7 +223,9 @@ public final class MessageHelper {
  } else if (obj instanceof Writer) {
  return prepend + [Body is instance of java.io.Writer];
  } else if (obj instanceof WrappedFile || obj instanceof File) {
-return prepend + [Body is file based:  + obj + ];
+if (!allowFiles) {
+return prepend + [Body is file based:  + obj + ];
+}
  }
  }


http://git-wip-us.apache.org/repos/asf/camel/blob/37e0e6bb/camel-core/src/test/java/org/apache/camel/management/ManagedBrowsableEndpointAsXmlFileTest.java
--
diff --git 
a/camel-core/src/test/java/org/apache/camel/management/ManagedBrowsableEndpointAsXmlFileTest.java
 
b/camel-core/src/test/java/org/apache/camel/management/ManagedBrowsableEndpointAsXmlFileTest.java
new file mode 100644
index 000..292bdb0
--- /dev/null
+++ 
b/camel-core/src/test/java/org/apache/camel/management/ManagedBrowsableEndpointAsXmlFileTest.java
@@ -0,0 +1,67 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.camel.management;
+
+import javax.management.MBeanServer;
+import javax.management.ObjectName;
+
+import org.apache.camel.Exchange;
+import org.apache.camel.builder.RouteBuilder;
+
+/**
+ * @version
+ */
+public class ManagedBrowsableEndpointAsXmlFileTest extends 
ManagementTestSupport {
+
+@Override
+protected void setUp() throws Exception {
+deleteDirectory(target/files);
+super.setUp();
+}
+
+public void testBrowseableEndpointAsXmlAllIncludeBody() throws Exception {
+// JMX tests dont work well on AIX CI servers (hangs them)
+if (isPlatform(aix)) {
+return;
+}
+
+template.sendBodyAndHeader(direct:start, Hello World, Exchange.FILE_NAME, 
hello.txt);
+
+MBeanServer mbeanServer = getMBeanServer();
+
+ObjectName name = 
ObjectName.getInstance(org.apache.camel:context=camel-1,type=endpoints,name=\file://target/files\);
+
+String out = (String) mbeanServer.invoke(name, browseAllMessagesAsXml, new 
Object[]{true}, new String[]{java.lang.Boolean});
+assertNotNull(out);
+log.info(out);
+
+assertTrue(Should contain the body, out.contains(Hello 
World/body));
+}
+
+@Override
+protected RouteBuilder createRouteBuilder() throws Exception {
+return 

Re: [DISCUSS] - Apache Camel 2.12.2 release later this month?

[Hadrian Zbarcea]

The release is done, but for some reason the apache repo doesn't let me 
close the staging repo:


The server did not close the staging repository.
Nexus returned an error: ERROR 502: Proxy Error

I'll try again in the morning and take it with infra if necessary. I 
will start the vote as soon as the staging repo is closed.


Hadrian


On 11/11/2013 01:33 PM, Claus Ibsen wrote:

Hi

I think we should cut a new 2.12.2 release later this month. We have
so far 115 jira's resolved.

Any thoughts?

[VOTE] Release Apache Camel 2.12.2

[Hadrian Zbarcea]

This is a vote to release Apache Camel 2.12.2, a patch release coming 
with about 143 issues fixed.


Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12325018

Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-167/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-167/org/apache/camel/apache-camel/2.12.2/

Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=3b7a3c635fe568571a5c96560ff320fada5198e4

Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.12.2
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian


--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Re: [DISCUSS] - Apache Camel 2.12.2 release later this month?

[Hadrian Zbarcea]

Longer day than I hoped. I think a new bug was introduced this week.
Other than that I looks like we're ready for the release. I am planning 
on building it tomorrow.


Claus any luck with CAMEL-6988? Please advice if it could get in this 
release or not.


Hadrian



On 11/20/2013 02:23 PM, 7erry wrote:

Ideally 2.12.2 will resolve an issue that 2.12.1 introduced. We need the
ability to disable the caching of groovy that was introduced in 2.12.1 since
it fails to invoke the groovy OGNL call and thus returns dirty data.

See CAMEL-6988


7erry





--
View this message in context: 
http://camel.465427.n5.nabble.com/DISCUSS-Apache-Camel-2-12-2-release-later-this-month-tp5743058p5743584.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: [DISCUSS] - Apache Camel 2.12.2 release later this month?

[Hadrian Zbarcea]

I am taking care of it now.
Hadrian

On 11/19/2013 10:35 AM, Sergey Beryozkin wrote:

Hi Willem

Can yourself or someone else apply a patch to
https://issues.apache.org/jira/browse/CAMEL-6878 please ?

Thanks, Sergey




On 11/12/2013 08:11 PM, Willem jiang wrote:


+1,
BTW, it looks Camel 2.12.x is catch up the release cycle of Camel
2.11.x.


--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com
(http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem





On Wednesday, November 13, 2013 at 5:13 AM, Christian Müller wrote:

  +1


Best,
Christian



On Tue, Nov 12, 2013 at 5:24 PM, Claus Ibsen
claus.ib...@gmail.com(mailto:
claus.ib...@gmail.com) wrote:

  On Mon, Nov 11, 2013 at 7:52 PM, Hadrian Zbarcea
hzbar...@gmail.com(mailto:

hzbar...@gmail.com)
wrote:


I wanted to say the same thing. Maybe even sooner in the month. How
about
shooting to build the release end of this week. I can take care
of this
release.

Hadrian



Yeah that works for me too. Just thought it was about time we cut a
new patch release for the 2.12 branch now that we have 100+ jiras
resolved.






On 11/11/2013 01:33 PM, Claus Ibsen wrote:



Hi

I think we should cut a new 2.12.2 release later this month. We
have
so far 115 jira's resolved.

Any thoughts?






--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com (mailto:cib...@redhat.com)
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [DISCUSS] - Apache Camel 2.12.2 release later this month?

[Hadrian Zbarcea]

After Willem's fix last night all tests are now passing (with one 
intermittent test failure in camel-jms, I believe timing related). 
Please let me know today, what are the issues you're working on we must 
have in 2.12.2 so we could close down on the release.


Thanks,
Hadrian

On 11/17/2013 07:54 PM, Hadrian Zbarcea wrote:

There are test failure(s) I need to look at:

Are there any other issues you absolutely need in 2.12.2?

Hadrian




On 11/12/2013 08:11 PM, Willem jiang wrote:

+1,
BTW, it looks Camel 2.12.x is catch up the release cycle of Camel 2.11.x.


--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com
(http://willemjiang.blogspot.com/) (English)
   http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem





On Wednesday, November 13, 2013 at 5:13 AM, Christian Müller wrote:


+1

Best,
Christian



On Tue, Nov 12, 2013 at 5:24 PM, Claus Ibsen claus.ib...@gmail.com
(mailto:claus.ib...@gmail.com) wrote:


On Mon, Nov 11, 2013 at 7:52 PM, Hadrian Zbarcea hzbar...@gmail.com
(mailto:hzbar...@gmail.com)
wrote:

I wanted to say the same thing. Maybe even sooner in the month. How
about
shooting to build the release end of this week. I can take care of
this
release.

Hadrian


Yeah that works for me too. Just thought it was about time we cut a
new patch release for the 2.12 branch now that we have 100+ jiras
resolved.






On 11/11/2013 01:33 PM, Claus Ibsen wrote:


Hi

I think we should cut a new 2.12.2 release later this month. We have
so far 115 jira's resolved.

Any thoughts?




--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com (mailto:cib...@redhat.com)
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [DISCUSS] - Apache Camel 2.12.2 release later this month?

[Hadrian Zbarcea]

We usually do all the patch releases at roughly the same time, so I was 
planning on doing that too.


Hadrian


On 11/18/2013 03:46 AM, Christian Müller wrote:

Not for me. I'm fine with the assigned issues for 2.12.2.

I'm wondering whether we should also release 2.11.3 in short term. I could
do this next week or so (comming back to a normal work load in my day
job...).

Best,
Christian



On Mon, Nov 18, 2013 at 1:54 AM, Hadrian Zbarcea hzbar...@gmail.com wrote:


There are test failure(s) I need to look at:

Are there any other issues you absolutely need in 2.12.2?

Hadrian





On 11/12/2013 08:11 PM, Willem jiang wrote:


+1,
BTW, it looks Camel 2.12.x is catch up the release cycle of Camel 2.11.x.


--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem





On Wednesday, November 13, 2013 at 5:13 AM, Christian Müller wrote:

  +1


Best,
Christian



On Tue, Nov 12, 2013 at 5:24 PM, Claus Ibsen claus.ib...@gmail.com(mailto:
claus.ib...@gmail.com) wrote:

  On Mon, Nov 11, 2013 at 7:52 PM, Hadrian Zbarcea hzbar...@gmail.com(mailto:

hzbar...@gmail.com)
wrote:


I wanted to say the same thing. Maybe even sooner in the month. How
about
shooting to build the release end of this week. I can take care of this
release.

Hadrian



Yeah that works for me too. Just thought it was about time we cut a
new patch release for the 2.12 branch now that we have 100+ jiras
resolved.






On 11/11/2013 01:33 PM, Claus Ibsen wrote:



Hi

I think we should cut a new 2.12.2 release later this month. We have
so far 115 jira's resolved.

Any thoughts?






--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com (mailto:cib...@redhat.com)
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: About 2 commits of today...

[Hadrian Zbarcea]

Good catch Babak. Thanks,
Hadrian

On 11/18/2013 02:59 PM, Babak Vahdat wrote:

Hi

Just spotted couple of things on the commit mailing list of today:

http://git-wip-us.apache.org/repos/asf/camel/diff/000581e6

This commit now makes the following asserts passing:

   assertStartsWith((String[]) null, foo);
   assertStartsWith(new String[] {}, foo);
   assertStartsWith((CollectionString) null, foo);
   assertStartsWith(new ArrayListString(), foo);

Which is actually wrong as that would be wrong to claim that e.g. the
String foo is an element of a given empty collection. Other than that
this change does not actually fix the failing test as the problem is
something else, namely there're elements inside the given array/collection
which do NOT start with the given prefix. So maybe a better approach would
be to change the asserts from:

   assertTrue(value.startsWith(prefix));

to:

   assertTrue(' + value + ' does not start with the prefix: ' + prefix
+ '!, value.startsWith(prefix));

So we get an idea about what actually is going wrong on ubuntu. See also
the note inside the checkProtocols() method of this test class.

http://git-wip-us.apache.org/repos/asf/camel/diff/8a080c97

- The following getters are missing: getProvider() / getSchemaLocation() /
getSchemaLocations() for the properties being newly introduced.
- Instead of:

   @SuppressWarnings(rawtypes)
   JSONProvider jsonProvider = new JSONProvider();

We could better do:

   JSONProviderObject jsonProvider = new JSONProviderObject();

- There's no benefit of the following generic List type newly introduced
by the API:

   public void setProviders(List? extends Object providers)...

As ? is as good as ? extends Object so maybe better do:

   public void setProviders(List? providers)...

See http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.4

...Every type variable declared as a type parameter has a bound. If no
bound is declared for a type variable, Object is assumed.

Babak

Re: About 2 commits of today...

[Hadrian Zbarcea]

For what is worth, the test was failing with all JDKs not just OpenJDK. 
Not sure if hardcoding the cipher suite is the best fix in the long run, 
but it does work.


Hadrian


On 11/18/2013 09:56 PM, Willem jiang wrote:

Hi Babak,

Thanks for the review, I just updated the code with some suggestion of you.
For the SSLContextParametersTest it is caused by the different JDKs handles the 
SSL related setting differently, I just updated the code to avoid the null 
collection returned.


--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
   http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem





On Tuesday, November 19, 2013 at 3:59 AM, Babak Vahdat wrote:


Hi

Just spotted couple of things on the commit mailing list of today:

http://git-wip-us.apache.org/repos/asf/camel/diff/000581e6

This commit now makes the following asserts passing:

assertStartsWith((String[]) null, foo);
assertStartsWith(new String[] {}, foo);
assertStartsWith((CollectionString) null, foo);
assertStartsWith(new ArrayListString(), foo);

Which is actually wrong as that would be wrong to claim that e.g. the
String foo is an element of a given empty collection. Other than that
this change does not actually fix the failing test as the problem is
something else, namely there're elements inside the given array/collection
which do NOT start with the given prefix. So maybe a better approach would
be to change the asserts from:

assertTrue(value.startsWith(prefix));

to:

assertTrue(' + value + ' does not start with the prefix: ' + prefix
+ '!, value.startsWith(prefix));

So we get an idea about what actually is going wrong on ubuntu. See also
the note inside the checkProtocols() method of this test class.

http://git-wip-us.apache.org/repos/asf/camel/diff/8a080c97

- The following getters are missing: getProvider() / getSchemaLocation() /
getSchemaLocations() for the properties being newly introduced.
- Instead of:

@SuppressWarnings(rawtypes)
JSONProvider jsonProvider = new JSONProvider();

We could better do:

JSONProviderObject jsonProvider = new JSONProviderObject();

- There's no benefit of the following generic List type newly introduced
by the API:

public void setProviders(List? extends Object providers)...

As ? is as good as ? extends Object so maybe better do:

public void setProviders(List? providers)...

See http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.4

...Every type variable declared as a type parameter has a bound. If no
bound is declared for a type variable, Object is assumed.

Babak

Re: [DISCUSS] - Apache Camel 2.12.2 release later this month?

[Hadrian Zbarcea]

There are test failure(s) I need to look at:

Are there any other issues you absolutely need in 2.12.2?

Hadrian




On 11/12/2013 08:11 PM, Willem jiang wrote:

+1,
BTW, it looks Camel 2.12.x is catch up the release cycle of Camel 2.11.x.


--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
   http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem





On Wednesday, November 13, 2013 at 5:13 AM, Christian Müller wrote:


+1

Best,
Christian



On Tue, Nov 12, 2013 at 5:24 PM, Claus Ibsen claus.ib...@gmail.com 
(mailto:claus.ib...@gmail.com) wrote:


On Mon, Nov 11, 2013 at 7:52 PM, Hadrian Zbarcea hzbar...@gmail.com 
(mailto:hzbar...@gmail.com)
wrote:

I wanted to say the same thing. Maybe even sooner in the month. How about
shooting to build the release end of this week. I can take care of this
release.

Hadrian


Yeah that works for me too. Just thought it was about time we cut a
new patch release for the 2.12 branch now that we have 100+ jiras
resolved.






On 11/11/2013 01:33 PM, Claus Ibsen wrote:


Hi

I think we should cut a new 2.12.2 release later this month. We have
so far 115 jira's resolved.

Any thoughts?




--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com (mailto:cib...@redhat.com)
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: AW: CAMEL-6648

[Hadrian Zbarcea]

Jan,

Personally I don't think there is a need for one in camel core. As a 
framework, camel should stay very simple and provide solutions/helpers 
for the common use cases. Such a dsl, while useful in your context adds 
unnecessary (imho) complexity for camel. That's the beauty of camel, it 
is pluggable and extensible, but not all extensions are good candidates 
for inclusion back in the core for various reasons (some depend on non 
compatible licenses, and hosted at camel-extra, some are application 
specific, etc).


FWIW, I've been using variations of the builder pattern for a long 
while, but to build domain specific messages and then use the generic 
ProducerTemplate to send them to an Endpoint. I consider it a better 
approach, as it is tied to the (semantics of the) domain vs the lower 
level Camel api.


Your work is noted though and appreciated.
Hadrian



On 11/11/2013 04:14 AM, Jan Matèrne (jhm) wrote:

Is there no need any more for that builder?
https://issues.apache.org/jira/browse/CAMEL-6648

I am asking for feedback for two months now ...


Jan 


-Ursprüngliche Nachricht-
Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
Gesendet: Freitag, 11. Oktober 2013 07:25
An: 'dev@camel.apache.org'
Betreff: AW: CAMEL-6648

Another ping ;)

Jan


-Ursprüngliche Nachricht-
Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
Gesendet: Freitag, 27. September 2013 12:20
An: dev@camel.apache.org
Betreff: AW: CAMEL-6648

Ok, thanks for the explanation.

Jan


-Ursprüngliche Nachricht-
Von: Raul Kripalani [mailto:r...@evosent.com]
Gesendet: Freitag, 27. September 2013 12:03
An: dev@camel.apache.org
Betreff: Re: CAMEL-6648

I'm overloaded these days with client work. If someone else wants

to

take a stab, you're welcome.
Otherwise, I'm hopeful I'll be able to review next week.

Regards,
Raúl.

2013/9/26 Jan Matèrne (jhm) apa...@materne.de


Another ping ;)

Jan


-Ursprüngliche Nachricht-
Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
Gesendet: Dienstag, 17. September 2013 13:44
An: dev@camel.apache.org
Betreff: CAMEL-6648

I want to ask for feedback for
https://issues.apache.org/jira/browse/CAMEL-6648



cheers

Jan

Re: [DISCUSS] - Apache Camel 2.12.2 release later this month?

[Hadrian Zbarcea]

I wanted to say the same thing. Maybe even sooner in the month. How 
about shooting to build the release end of this week. I can take care of 
this release.


Hadrian


On 11/11/2013 01:33 PM, Claus Ibsen wrote:

Hi

I think we should cut a new 2.12.2 release later this month. We have
so far 115 jira's resolved.

Any thoughts?

Re: AW: AW: CAMEL-6648

[Hadrian Zbarcea]

Will do. The default is 'Major' so pretty much all issues are like that. 
Few are changed to a different level (usually to draw attention to 
something that has a more serious impact). It's hard to be pedantic with 
the issue severities, because, we are a self managed community (like all 
others at the ASF) and the severity is in the eye of the beholder, not 
driven by a business impact as is usually the case with commercial software.


Cheers,
Hadrian


On 11/11/2013 02:32 PM, Jan Matèrne (jhm) wrote:

Personally I don't think there is a need for one in camel core. As a
framework, camel should stay very simple and provide solutions/helpers
for the common use cases. Such a dsl, while useful in your context adds
unnecessary (imho) complexity for camel. That's the beauty of camel, it
is pluggable and extensible, but not all extensions are good candidates
for inclusion back in the core for various reasons (some depend on non
compatible licenses, and hosted at camel-extra, some are application
specific, etc).

FWIW, I've been using variations of the builder pattern for a long
while, but to build domain specific messages and then use the generic
ProducerTemplate to send them to an Endpoint. I consider it a better
approach, as it is tied to the (semantics of the) domain vs the lower
level Camel api.

Your work is noted though and appreciated.
Hadrian


Then please close that issue.
I wonder why this was prioritized as major 
https://issues.apache.org/jira/browse/CAMEL-6648


Jan

Re: Camel Extra CI server proposal

[Hadrian Zbarcea]

Sounds great!
Hadrian

On 09/26/2013 04:29 PM, Henryk Konsek wrote:

Hi,

People associated with Camel Extra might be interested in this [1] forum thread.

Thanks  laters.

[1] 
http://camel-extra.1091541.n5.nabble.com/Camel-Extra-CI-server-at-Cloudbees-td50.html

Re: [VOTE] Release Apache Camel 2.12.1

[Hadrian Zbarcea]

+1
Hadrian

On 09/19/2013 01:25 AM, Christian Müller wrote:

After 9 days of development, we have a new bug fix release candidate
apache-camel-2.12.1 ready.
It comes with 47 issues resolved: new features, improvements and bug fixes
[1]. You can find the release notes here [2].

We release this version in short term after 2.12.0 to provide the latest
fixes for the upcoming Apache ActiveMQ 5.9.0 release.

Please find the staging repo here:
https://repository.apache.org/content/repositories/orgapachecamel-075/

The tarballs are here
https://repository.apache.org/content/repositories/orgapachecamel-075/org/apache/camel/apache-camel/2.12.1/

Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=7a036ef8ecede539d384586f501208f5e651

Please review, help out with testing and vote to approve this release
binary. Please mention what you tested to prevent duplicate work. Your vote
counts!

[ ] +1 Release the binary as Apache Camel 2.12.1
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks in advance,
Christian

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%20%222.12.1%22
[2]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12324857

Re: [VOTE] Release Apache Camel 2.10.7

[Hadrian Zbarcea]

+1 (not sure why the reply-to private@)
Hadrian

On 09/15/2013 05:25 PM, Christian Müller wrote:

After 2 month of development, we have a new bug fix release candidate
apache-camel-2.10.7 ready.
It comes with 63 issues resolved: new features, improvements and bug fixes
[1].
You can find the release notes here [2].
This will be the last planned Camel 2.10.x release. We will discontinue the
support for the camel-2.10.x branch afterwards.

Please find the staging repo here:
https://repository.apache.org/content/repositories/orgapachecamel-048/

The tarballs are here
https://repository.apache.org/content/repositories/orgapachecamel-048/org/apache/camel/apache-camel/2.10.7/

Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=5d46d83f26fec7c06a9e531aee45e1048fed84af

Please review, help out with testing and vote to approve this release
binary. Please mention what you tested to prevent duplicate work. Your vote
counts!

[ ] +1 Release the binary as Apache Camel 2.10.7
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks in advance,
Christian

[1]
https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20%222.10.7%22%20AND%20project%20%3D%20CAMEL
[2]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12324667

Re: [DISCUSS] - Apache Camel 2.11.2 release, and one last 2.10.7 release

[Hadrian Zbarcea]

Agree, I'll take care of it this week.
Hadrian

On 09/10/2013 06:00 AM, Claus Ibsen wrote:

Hi

I think its time we cut a new patch release of 2.11 branch. We have
100+ resolved tickets since last release.

And 2.11.1 was released about 2 months ago
http://camel.apache.org/2013/07/17/apache-camel-2111-released.html

So if we get some time then we could consider cutting a patch release
in the near future, such as in a couple of weeks or so.

And for 2.10.7 I suggest we cut one last release later this fall, and
then stop supporting this branch, as we already have 2.12 and 2.11
branches as active supported.

Any thoughts?

Re: [CANCEL][VOTE] Release Apache Camel 2.12.0

[Hadrian Zbarcea]

What about considering developing in progress work on a branch and only 
merge it to a stable branch (master or maintenance) when ready? Using 
branches is much easier with git and was one of the reasons to migrate 
to git.


My $0.02,
Hadrian

On 08/29/2013 10:21 AM, Claus Ibsen wrote:

Hi Willem

This is on purpose

camel-netty4 is WORK IN PROGRESS. Its not migrated yet. That work is
planned AFTER Camel 2.12.0 release.

And the camel-example-servlet-tomcat-blueprintweb is also WORK IN PROGRESS.

These 2 should NOT be in the release. They are not ready!

On Thu, Aug 29, 2013 at 4:10 PM, Willem jiang willem.ji...@gmail.com wrote:

Hi,

I just found the camel-netty4 and camel-example-servlet-tomcat-blueprintweb 
module's version is not changed when I released the Camel 2.12.0.
So I had to cancel this vote as I need to do the release cut again.
I just setup the camel-2.12.x branch for the new coming up release. Please just 
merge the critical patch into this branch and don't break the build, as I'm 
planing to do recut in next 10 hours if there is no any other objection.


--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
   http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem





On Wednesday, August 28, 2013 at 5:45 PM, Willem jiang wrote:


After 5 month of development, we have a new minor release candidate
apache-camel-2.12.0 ready.
It comes with 320 issues resolved: new features, improvements and bug fixes
[1]. You can find the release notes here [2].

Please find the staging repo here:
https://repository.apache.org/content/repositories/orgapachecamel-119/

The tarballs are here
https://repository.apache.org/content/repositories/orgapachecamel-119/org/apache/camel/apache-camel/2.12.0/

Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=af4c05ec6df0f1d562a8d21d0355678ca3a892d4

Please review, help out with testing and vote to approve this release
binary. Please mention what you tested to prevent duplicate work. Your vote
counts!

[ ] +1 Release the binary as Apache Camel 2.12.0
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks in advance,
Willem

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%20%222.12.0%22
[2]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12323968projectId=12311211



--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem

Re: Release of Camel 2.12.0

[Hadrian Zbarcea]

I would strongly suggest building the release with 1.6. I had problems 
in the past releasing with a JDK release newer than the oldest supported 
one.


I am mostly off the grid until the end of next week (most likely) and I 
won't be able to help with a release until then.


My $0.02,
Hadrian



On 08/23/2013 05:41 AM, Willem jiang wrote:

I will take care of the OSGi bundle upgrading work.
BTW, I'm planing to use JDK 1.7 to build the release and I will run some tests 
with JDK 1.6.


--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
   http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem





On Friday, August 23, 2013 at 5:34 PM, Claus Ibsen wrote:


Hi

Also the SMX team have recently released some new OSGi bundles. Maybe
we should upgrade the features file to use newer versions?

On Wed, Aug 21, 2013 at 11:39 AM, Willem jiang willem.ji...@gmail.com 
(mailto:willem.ji...@gmail.com) wrote:

Hi team,

As Camel 2.12-SNAPSHOT is sharped [1], I suggest we would consider the release 
of Camel 2.12.0 this month.
I'd like to be the release manager this time if you don't mind.
I'm planing to start the build cut at the earlier next week, any thought?

[1]https://issues.apache.org/jira/browse/CAMEL/fixforversion/12323968

Regards,

--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem






--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com (mailto:cib...@redhat.com)
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: Release of Camel 2.12.0

[Hadrian Zbarcea]

Willem, I believe the new version on the trunk should be 2.13-SNAPSHOT 
and the 2.12.1 branch created off of the tag.


Hadrian


On 08/23/2013 05:41 AM, Willem jiang wrote:

I will take care of the OSGi bundle upgrading work.
BTW, I'm planing to use JDK 1.7 to build the release and I will run some tests 
with JDK 1.6.


--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
   http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem





On Friday, August 23, 2013 at 5:34 PM, Claus Ibsen wrote:


Hi

Also the SMX team have recently released some new OSGi bundles. Maybe
we should upgrade the features file to use newer versions?

On Wed, Aug 21, 2013 at 11:39 AM, Willem jiang willem.ji...@gmail.com 
(mailto:willem.ji...@gmail.com) wrote:

Hi team,

As Camel 2.12-SNAPSHOT is sharped [1], I suggest we would consider the release 
of Camel 2.12.0 this month.
I'd like to be the release manager this time if you don't mind.
I'm planing to start the build cut at the earlier next week, any thought?

[1]https://issues.apache.org/jira/browse/CAMEL/fixforversion/12323968

Regards,

--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem






--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com (mailto:cib...@redhat.com)
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [VOTE] Release Apache Camel 2.11.1

[Hadrian Zbarcea]

+1
Hadrian


On 07/09/2013 11:34 PM, Hadrian Zbarcea wrote:

This is a vote to release Apache Camel 2.11.1, a patch release coming
with about 110 issues fixed.

Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12323967


Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-126/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-126/org/apache/camel/apache-camel/2.11.1/


Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=0297415ca80622b9d695217a6c6679c119049a3c


Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.11.1
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

[RESULT][VOTE] Release Apache Camel 2.11.1

[Hadrian Zbarcea]

The vote passes with:
[8] +1 (ningjiang, davsclaus, hadrian, dkulp, janstey, cschneider, 
cmueller, raulk)

[0] -1

I will proceed with publishing the artifacts and the public announcement 
of the release.


Many thanks to all contributors,
Hadrian


On 07/09/2013 11:34 PM, Hadrian Zbarcea wrote:

This is a vote to release Apache Camel 2.11.1, a patch release coming
with about 110 issues fixed.

Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12323967


Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-126/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-126/org/apache/camel/apache-camel/2.11.1/


Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=0297415ca80622b9d695217a6c6679c119049a3c


Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.11.1
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

Re: [DISCUSS] - Apache Camel 2.11.1 release

[Hadrian Zbarcea]

Probably an 'if' missing somewhere.
Hadrian

On 07/09/2013 05:06 AM, Babak Vahdat wrote:

And now after pulling your commit 3-- remains 3-- and doesn't result
in 2.

Babak

Am 09.07.13 11:00 schrieb Babak Vahdat unter
babak.vah...@swissonline.ch:


Hi

Thanks for the clarification, though still a question: if we stop
supporting
literal by the unary operators, then wouldn't this be a regression?  As an
example the documentation (http://camel.apache.org/simple) says the
following for --:

To decrement a number by one. The left hand side must be a function,
otherwise parsed as literal.

Or do I misunderstand the documentation?

Babak


Claus Ibsen-2 wrote

The unary operators should really only be used on functions.

And when people do logging they may use dashes in their logs, eg as
this example with ---
And in these cases we should improve the parser, to be more lenient
whether its an unary operator in use or not.

So I am improving this to only apply unary operators if the left hand
side is a function. And that the operator is followed by a whitespace
or EOL.

Then you can still do inc counters

eg some people needs this:
setHeader headerName=counter

simple
${counter}++
/simple
/setHeader
And for dec (which possible isnt as often used as ++)
setHeader headerName=counter

simple
${counter}--
/simple
/setHeader

On Mon, Jul 8, 2013 at 9:56 PM, Babak Vahdat
lt;



babak.vahdat@



gt; wrote:

Hi

To my understanding this is worked as designed and we should close
CAMEL-6414 as Not a Problem because the unary operator String -- is
part
of the language itself so that Camel simple parser tries to decrement
isA
by
1 which apparently fails as the conversion of isA to a java.lang.Number
fails (see

https://github.com/apache/camel/blob/master/camel-core/src/main/java/org
/apache/camel/language/simple/ast/UnaryExpression.java#L114).
For example if you would change the ignored test you've added as
following
then it would run green:

Š
 SimpleExpressionParser parser = new SimpleExpressionParser(THE
MSG
ID ${header.JMSMessageID}3--, true);
Š
 assertEquals(THE MSG ID JMSMessageID-1232,
exp.evaluate(exchange,
String.class));

As you see we just decremented 3 by 1 which results to 2. In this case
we
decremented a literal but as well you can also decrement a function,
see
SimpleDecHeaderTest for an example of this.

I'm sure Claus can correct me if I'm wrong here :-)

Babak


Christian Mueller wrote

Hadrian, go ahead for doing this release...

I reported one of the issues and added an unit test (ignored at
present),
but I didn't assigned the ticket to myself. I think we have other
committers who could fix this with less effort than me...

Best,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Mon, Jul 8, 2013 at 5:24 PM, Hadrian Zbarcea lt;



hzbarcea@



gt; wrote:


I could do it too, got back from vacation.

One of the issues is yours Christian, I will look into it after
finishing
this build. The other one is just doc, I think.

Running a full test now, all good so far (almost forgot how long it
takes
:( ).

Hadrian


On 07/08/2013 10:59 AM, Christian Müller wrote:


I can do it. What's with the two outstanding issues? Could you have
a
look
and fix them or postpone them to 2.11.2?

Best,
Christian

Sent from a mobile device
Am 08.07.2013 14:58 schrieb Claus Ibsen lt;



claus.ibsen@



gt;:


  Hi


Christian do you have time to work on the 2.11.1 release? Would be
great to get this out as well.


On Mon, Jul 1, 2013 at 12:09 AM, Christian Müller
lt;



christian.mueller@



gt; wrote:



Thanks Hadrian for the offer. If we are not able to start the
release


this


week, I'm happy to take this over to you :-).

I updated the maven release plugin configuration for the 2.11.x


maintenance


branch to use the Git repo and merged Dan's change to only
generate
the
HTML manual. I tested it and it works fine.

Claus and me pushed a few issues to Camel 2.11.2 and now, we only
have
9
outstanding issues scheduled for Camel 2.11.1.
2 of these issues are classified as bug and should be fixed.
2 other issues addressing missing documentation for new components
(ical
and scala-extraz).

All other issues are 'nice to have' in Camel 2.11.1, but not
'required',


in


my opinion.

Best,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel:

https://www.apache.org/**foundation/lt;https://www.apache.org/foun
dation/gt;
Apache Member:

https://www.apache.org/**foundation/members.htmllt;https://www.apa
che.org/foundation/members.htmlgt;


https://www.linkedin.com/pub/**christian-mueller/11/551/642lt;http
s://www.linkedin.com/pub/christian-mueller/11/551/642gt;


On Fri, Jun 28, 2013 at 12:06 AM

[VOTE] Release Apache Camel 2.11.1

[Hadrian Zbarcea]

This is a vote to release Apache Camel 2.11.1, a patch release coming 
with about 110 issues fixed.


Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12323967

Staging repo:
https://repository.apache.org/content/repositories/orgapachecamel-126/

Tarballs:
https://repository.apache.org/content/repositories/orgapachecamel-126/org/apache/camel/apache-camel/2.11.1/

Tag:
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=0297415ca80622b9d695217a6c6679c119049a3c

Please test this release candidate and cast your vote.
[ ] +1 Release the binary as Apache Camel 2.11.1
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks,
Hadrian

--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Re: [DISCUSS] - Apache Camel 2.11.1 release

[Hadrian Zbarcea]

I could do it too, got back from vacation.

One of the issues is yours Christian, I will look into it after 
finishing this build. The other one is just doc, I think.


Running a full test now, all good so far (almost forgot how long it 
takes :( ).


Hadrian

On 07/08/2013 10:59 AM, Christian Müller wrote:

I can do it. What's with the two outstanding issues? Could you have a look
and fix them or postpone them to 2.11.2?

Best,
Christian

Sent from a mobile device
Am 08.07.2013 14:58 schrieb Claus Ibsen claus.ib...@gmail.com:


Hi

Christian do you have time to work on the 2.11.1 release? Would be
great to get this out as well.


On Mon, Jul 1, 2013 at 12:09 AM, Christian Müller
christian.muel...@gmail.com wrote:

Thanks Hadrian for the offer. If we are not able to start the release

this

week, I'm happy to take this over to you :-).

I updated the maven release plugin configuration for the 2.11.x

maintenance

branch to use the Git repo and merged Dan's change to only generate the
HTML manual. I tested it and it works fine.

Claus and me pushed a few issues to Camel 2.11.2 and now, we only have 9
outstanding issues scheduled for Camel 2.11.1.
2 of these issues are classified as bug and should be fixed.
2 other issues addressing missing documentation for new components (ical
and scala-extraz).

All other issues are 'nice to have' in Camel 2.11.1, but not 'required',

in

my opinion.

Best,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Fri, Jun 28, 2013 at 12:06 AM, Hadrian Zbarcea hzbar...@gmail.com
wrote:


Hi Christian,

Next week I'll be in vacation, but I can do the 2.11.1 after I come

back.

It should be ok, I assume the 22 issues will not be all resolved next

week.


Cheers,
Hadrian



On 06/27/2013 05:02 PM, Christian Müller wrote:


We agreed to not build the PDF manual starting with Camel 2.12.0. We

still

have to discuss whether the HTML manual should still created or not.
However, because we only publish the HTML/PDF manual for major/minor
releases, it's not important for Camel 2.11.1.

We have 22 unresolved issues assigned to Camel 2.11.1 [1]. Could

everybody

please have a look and mention the issues which should be included in

this

release. I will move all others to 2.11.2, probably at the weekend...

And I could do the release or support the release manager, if someone

else

would like to do it.

[1]
https://issues.apache.org/**jira/issues/?jql=project%20%**
3D%20CAMEL%20AND%20resolution%**20%3D%20Unresolved%20AND%**
20fixVersion%20%3D%20%222.11.**1%22

https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%222.11.1%22




Best,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/**foundation/

https://www.apache.org/foundation/

Apache Member: https://www.apache.org/**foundation/members.html

https://www.apache.org/foundation/members.html


https://www.linkedin.com/pub/**christian-mueller/11/551/642

https://www.linkedin.com/pub/christian-mueller/11/551/642



On Thu, Jun 27, 2013 at 3:21 PM, Daniel Kulp dk...@apache.org wrote:



On Jun 27, 2013, at 6:04 AM, Claus Ibsen claus.ib...@gmail.com

wrote:


  Hi


We recently released the 2.10.5 release after our git migration.
It would be great if we could start working on a 2.11.1 release as

well.




I certainly support the idea of a 2.11.1 release, but we *DO* need to
figure out what we want to do with the PDF manual first.   We can no
longer
produce a usable manual.

Dan






--
Claus Ibsen
-
www.camelone.org: The open source integration conference.

Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen



--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com









--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [DISCUSS] - Apache Camel 2.11.1 release

[Hadrian Zbarcea]

Ok, I will give another 24 hours for any other issues that anybody wants 
to see in 2.11.1. I will start the builds tomorrow around 2pm est. If 
anybody wants do delay this release some more, please shout now.


I ran full tests today and everything passed with flying colors.

Cheers,
Hadrian



On 07/08/2013 03:03 PM, Christian Müller wrote:

Hadrian, go ahead for doing this release...

I reported one of the issues and added an unit test (ignored at present),
but I didn't assigned the ticket to myself. I think we have other
committers who could fix this with less effort than me...

Best,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Mon, Jul 8, 2013 at 5:24 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:


I could do it too, got back from vacation.

One of the issues is yours Christian, I will look into it after finishing
this build. The other one is just doc, I think.

Running a full test now, all good so far (almost forgot how long it takes
:( ).

Hadrian


On 07/08/2013 10:59 AM, Christian Müller wrote:


I can do it. What's with the two outstanding issues? Could you have a look
and fix them or postpone them to 2.11.2?

Best,
Christian

Sent from a mobile device
Am 08.07.2013 14:58 schrieb Claus Ibsen claus.ib...@gmail.com:

  Hi


Christian do you have time to work on the 2.11.1 release? Would be
great to get this out as well.


On Mon, Jul 1, 2013 at 12:09 AM, Christian Müller
christian.muel...@gmail.com wrote:


Thanks Hadrian for the offer. If we are not able to start the release


this


week, I'm happy to take this over to you :-).

I updated the maven release plugin configuration for the 2.11.x


maintenance


branch to use the Git repo and merged Dan's change to only generate the
HTML manual. I tested it and it works fine.

Claus and me pushed a few issues to Camel 2.11.2 and now, we only have 9
outstanding issues scheduled for Camel 2.11.1.
2 of these issues are classified as bug and should be fixed.
2 other issues addressing missing documentation for new components (ical
and scala-extraz).

All other issues are 'nice to have' in Camel 2.11.1, but not 'required',


in


my opinion.

Best,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: 
https://www.apache.org/**foundation/https://www.apache.org/foundation/
Apache Member: 
https://www.apache.org/**foundation/members.htmlhttps://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/**christian-mueller/11/551/642https://www.linkedin.com/pub/christian-mueller/11/551/642


On Fri, Jun 28, 2013 at 12:06 AM, Hadrian Zbarcea hzbar...@gmail.com
wrote:

  Hi Christian,


Next week I'll be in vacation, but I can do the 2.11.1 after I come


back.



It should be ok, I assume the 22 issues will not be all resolved next



week.





Cheers,
Hadrian



On 06/27/2013 05:02 PM, Christian Müller wrote:

  We agreed to not build the PDF manual starting with Camel 2.12.0. We



still



have to discuss whether the HTML manual should still created or not.

However, because we only publish the HTML/PDF manual for major/minor
releases, it's not important for Camel 2.11.1.

We have 22 unresolved issues assigned to Camel 2.11.1 [1]. Could


everybody



please have a look and mention the issues which should be included in



this



release. I will move all others to 2.11.2, probably at the weekend...


And I could do the release or support the release manager, if someone


else



would like to do it.


[1]
https://issues.apache.org/jira/issues/?jql=project%20%**
3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20AND%**
20fixVersion%20%3D%20%222.11.1%22


https://issues.apache.org/**jira/issues/?jql=project%20%**

3D%20CAMEL%20AND%20resolution%**20%3D%20Unresolved%20AND%**
20fixVersion%20%3D%20%222.11.**1%22https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%222.11.1%22





Best,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: 
https://www.apache.org/foundation/https://www.apache.org/**foundation/



https://www.apache.org/**foundation/https://www.apache.org/foundation/





Apache Member: 
https://www.apache.org/foundation/members.htmlhttps://www.apache.org/**foundation/members.html




https://www.apache.org/**foundation/members.htmlhttps://www.apache.org/foundation/members.html







https://www.linkedin.com/pub/christian-mueller/11/551/642https://www.linkedin.com/pub/**christian-mueller/11/551/642



https://www.linkedin.com/pub/**christian-mueller/11/551/642https://www.linkedin.com/pub/christian-mueller/11/551/642

Re: Camel manual in pdf....

[Hadrian Zbarcea]

#5 +1 agree

Hadrian

On 06/27/2013 10:07 AM, Claus Ibsen wrote:

I vote for #5

It will just keep haunting us in the future. With new problems etc.

Its 2013 and people read online docs / google / stackoverflow / watch
videos / etc.
The camel pdf manual is not a good manual but just a big dump of the
web site, thats not readable, and I dont see any people use it.

And in the last 2.11.0 release we had the manual 2 times, eg with
2.11.0 and 2.11-SNAPSHOT as version. But nobody noticed during the
testing phase etc. Also a little hint that the manual is not really
used from our releases.



On Wed, Jun 26, 2013 at 5:37 PM, Daniel Kulp dk...@apache.org wrote:


With the latest confluence (and also once they actually update to 5.1.x), the 
Camel manual is no longer producible.   The main problem is the javascript that 
is used to format all the {code} and {snippet} macros.   The old version of 
confluence rendered them into static HTML which prince handled fine.   The new 
versions require some javascript to render it.

I tried updating the html for the manual to add the javascript into it and pass 
the --javascript flag to prince.   With the 8.1r3 version of prince I had, it 
would segfault.   Updating to 8.1r5 (latest from prince) goes into an infinite 
loop.Thus, there are a few options:

1) When converting from book-in-one-page.html to the manual.html, we can try and 
adjust the script  tags that confluence now generates to convert them to 
something prince can render.   There may be a different javascript based highlighter 
that prince can handle.   Not really sure, would require a bit of investigation and 
experimentation.

2) Similar to (1), I could try updating the CXF site-exporter to use a 
different syntax highlighter.  I currently just use the same one as confluence 
to make sure it works.

3) Experiment with different HTML - PDF renderers.  There are several out 
there, not sure if any of them can handle the javascript any better.

4) Report issues to prince and hope for a new version of prince that can handle 
it.

5) Drop the PDF manual entirely.  We can keep the html manual if we really want 
it.

I did try the Confluence Export to PDF option and that didn't render the code 
blocks either.   So no help there.

1-3 would require a bit of work and I really don't want to go down those routes if #5 is the 
best option for us.I don't recommend #4.I'm personally in favor of #5 as I 
really don't see much value in the PDF manual at this point.

Thoughts?

--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: Camel manual in pdf....

[Hadrian Zbarcea]

Give the fact that it uses precious compile time, I would drop the html 
manual too. It's not as well formated as the PDF one and equally useless.


Just my $0.02,
Hadrian

On 06/27/2013 12:30 PM, Christian Müller wrote:

+1 for #5 but would like to keep html manual.

Best,
Christian

Sent from a mobile device
Am 26.06.2013 17:38 schrieb Daniel Kulp dk...@apache.org:



With the latest confluence (and also once they actually update to 5.1.x),
the Camel manual is no longer producible.   The main problem is the
javascript that is used to format all the {code} and {snippet} macros.
The old version of confluence rendered them into static HTML which prince
handled fine.   The new versions require some javascript to render it.

I tried updating the html for the manual to add the javascript into it and
pass the --javascript flag to prince.   With the 8.1r3 version of prince I
had, it would segfault.   Updating to 8.1r5 (latest from prince) goes into
an infinite loop.Thus, there are a few options:

1) When converting from book-in-one-page.html to the manual.html, we can
try and adjust the script  tags that confluence now generates to convert
them to something prince can render.   There may be a different javascript
based highlighter that prince can handle.   Not really sure, would require
a bit of investigation and experimentation.

2) Similar to (1), I could try updating the CXF site-exporter to use a
different syntax highlighter.  I currently just use the same one as
confluence to make sure it works.

3) Experiment with different HTML - PDF renderers.  There are several out
there, not sure if any of them can handle the javascript any better.

4) Report issues to prince and hope for a new version of prince that can
handle it.

5) Drop the PDF manual entirely.  We can keep the html manual if we really
want it.

I did try the Confluence Export to PDF option and that didn't render the
code blocks either.   So no help there.

1-3 would require a bit of work and I really don't want to go down those
routes if #5 is the best option for us.I don't recommend #4.I'm
personally in favor of #5 as I really don't see much value in the PDF
manual at this point.

Thoughts?

--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: [DISCUSS] - Apache Camel 2.11.1 release

[Hadrian Zbarcea]

Hi Christian,

Next week I'll be in vacation, but I can do the 2.11.1 after I come 
back. It should be ok, I assume the 22 issues will not be all resolved 
next week.


Cheers,
Hadrian


On 06/27/2013 05:02 PM, Christian Müller wrote:

We agreed to not build the PDF manual starting with Camel 2.12.0. We still
have to discuss whether the HTML manual should still created or not.
However, because we only publish the HTML/PDF manual for major/minor
releases, it's not important for Camel 2.11.1.

We have 22 unresolved issues assigned to Camel 2.11.1 [1]. Could everybody
please have a look and mention the issues which should be included in this
release. I will move all others to 2.11.2, probably at the weekend...

And I could do the release or support the release manager, if someone else
would like to do it.

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%222.11.1%22

Best,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Thu, Jun 27, 2013 at 3:21 PM, Daniel Kulp dk...@apache.org wrote:



On Jun 27, 2013, at 6:04 AM, Claus Ibsen claus.ib...@gmail.com wrote:


Hi

We recently released the 2.10.5 release after our git migration.
It would be great if we could start working on a 2.11.1 release as well.


I certainly support the idea of a 2.11.1 release, but we *DO* need to
figure out what we want to do with the PDF manual first.   We can no longer
produce a usable manual.

Dan






--
Claus Ibsen
-
www.camelone.org: The open source integration conference.

Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen


--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: [VOTE] Release Apache Camel 2.10.5

[Hadrian Zbarcea]

+1 (reversal of vote)

* I got to run the full test suite too. Everything works except one 
test, but it's a test issue not a product issue.

* Checked signatures, all looks good.
* I checked with Dan this morning. For him everything looked good. Dan 
mentioned that there was a discussion on the maven lists related to what 
I experienced, but there is no good solution. After picking the first 
2.10.5 tag, I only did a `git pull`, without a `git fetch --tags`, so 
the tag in my local clone was not refreshed and hence the version I got 
to see. This would not happen on a fresh copy, therefore it's not an 
issue as far as the release is concerned.
* The camel-itests are still an issue that needs resolving, but not a 
blocker for the release. It needs to be resolved though. For instance 
camel-itest-osgi was a released artifact up until 2.10.2, we should 
probably move it somewhere else if we don't plan to release. Anyway, a 
discussion for another time.

* Singing the tag still an issue to be resolved, not a blocker.

Thanks Christian for the first release from the git repo!
Hadrian


On 06/25/2013 03:18 PM, Christian Müller wrote:

Hello Hadrian!

Can you please share a link to the faulty pom.xml files!? I checked Nexus
[1] and Git [2] and they look good.

[1]
https://repository.apache.org/content/repositories/orgapachecamel-058/org/apache/camel/camel-core/2.10.5/camel-core-2.10.5.pom
[2]
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=blob;f=camel-core/pom.xml;h=c1cf6b896c47ddb6cd256327a3be25452937cc31;hb=b080909f1db853e5d91e67f78a248a9950481d18

Best,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Tue, Jun 25, 2013 at 3:37 AM, Hadrian Zbarcea hzbar...@gmail.com wrote:


-1 (reluctantly)

* Checking out the tag I see that all poms use 2.10.5-SNAPSHOT. Not good
for a release.
* Building from the tag went fine (didn't run all tests yet, but I plan to
tomorrow). However, in ./tests, both camel-itest-osgi and camel-itest-karaf
are excluded from the build, and what's worse, point to older versions of
the parent. We should have caught this earlier.
* Signing the tag is important (imho), but that's not a blocker, that's
only a -0.

Hadrian



On 06/23/2013 05:35 AM, Christian Müller wrote:


After 4 month of development, we have a new bug fix release candidate
apache-camel-2.10.5 ready.
It comes with 108 issues resolved [1]. You can find the release notes here
[2].

Please find the staging repo here:
https://repository.apache.org/**content/repositories/**
orgapachecamel-058/https://repository.apache.org/content/repositories/orgapachecamel-058/

The tarballs are here
https://repository.apache.org/**content/repositories/**
orgapachecamel-058/org/apache/**camel/apache-camel/2.10.5/https://repository.apache.org/content/repositories/orgapachecamel-058/org/apache/camel/apache-camel/2.10.5/

Tag:
http://svn.apache.org/repos/**asf/camel/tags/camel-2.10.5/http://svn.apache.org/repos/asf/camel/tags/camel-2.10.5/

Please review, help out with testing and vote to approve this release
binary. This is our first release which uses the new Camel Git repository
at 
https://git-wip-us.apache.org/**repos/asf?p=camel.githttps://git-wip-us.apache.org/repos/asf?p=camel.git
.
Please mention what you tested to prevent duplicate work. Your vote
counts!

Some notable remarks:
- At present, we don't use signed tags in Git. I don't think it's possible
at  present because of the unresolved issue [3]. I also don't think this
is
necessary, because we did had a similar thing in SVN.
- Because I didn't push my local changes to the central repository until
today morning and Claus did some changes on the camel-2.10.x branch (no
blaming ;-) ), it now looks like the tag 2.10.5 is not part of the
camel-2.10.x branch because I had to do a rebase before I could push the
changes. Not sure whether this is an issue. If it's, I will will change
the
maven-release-plugin settings to push the changes immediately by doing the
release:prepare and undo the release.
- The Camel manual still looks good. May be the Confluence update wasn't
started/done at the time I build the release.

[ ] +1 Release the binary as Apache Camel 2.10.5
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

[1]
https://issues.apache.org/**jira/issues/?jql=project%20%**
3D%20CAMEL%20AND%20fixVersion%**20%3D%20%222.10.5%22https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%20%222.10.5%22
[2]
https://issues.apache.org/**jira/secure/ReleaseNote.jspa?**
projectId=12311211version=**12324024https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12324024
[3] 
http://jira.codehaus.org/**browse/SCM-486http://jira.codehaus.org/browse/SCM-486

Re: [VOTE] Release Apache Camel 2.10.5

[Hadrian Zbarcea]

-1 (reluctantly)

* Checking out the tag I see that all poms use 2.10.5-SNAPSHOT. Not good 
for a release.
* Building from the tag went fine (didn't run all tests yet, but I plan 
to tomorrow). However, in ./tests, both camel-itest-osgi and 
camel-itest-karaf are excluded from the build, and what's worse, point 
to older versions of the parent. We should have caught this earlier.
* Signing the tag is important (imho), but that's not a blocker, that's 
only a -0.


Hadrian


On 06/23/2013 05:35 AM, Christian Müller wrote:

After 4 month of development, we have a new bug fix release candidate
apache-camel-2.10.5 ready.
It comes with 108 issues resolved [1]. You can find the release notes here
[2].

Please find the staging repo here:
https://repository.apache.org/content/repositories/orgapachecamel-058/

The tarballs are here
https://repository.apache.org/content/repositories/orgapachecamel-058/org/apache/camel/apache-camel/2.10.5/

Tag:
http://svn.apache.org/repos/asf/camel/tags/camel-2.10.5/

Please review, help out with testing and vote to approve this release
binary. This is our first release which uses the new Camel Git repository
at https://git-wip-us.apache.org/repos/asf?p=camel.git.
Please mention what you tested to prevent duplicate work. Your vote counts!

Some notable remarks:
- At present, we don't use signed tags in Git. I don't think it's possible
at  present because of the unresolved issue [3]. I also don't think this is
necessary, because we did had a similar thing in SVN.
- Because I didn't push my local changes to the central repository until
today morning and Claus did some changes on the camel-2.10.x branch (no
blaming ;-) ), it now looks like the tag 2.10.5 is not part of the
camel-2.10.x branch because I had to do a rebase before I could push the
changes. Not sure whether this is an issue. If it's, I will will change the
maven-release-plugin settings to push the changes immediately by doing the
release:prepare and undo the release.
- The Camel manual still looks good. May be the Confluence update wasn't
started/done at the time I build the release.

[ ] +1 Release the binary as Apache Camel 2.10.5
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%20%222.10.5%22
[2]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12324024
[3] http://jira.codehaus.org/browse/SCM-486

Thanks in advance,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642

Re: [DISCUSS] - Apache Camel 2.10.5 release

[Hadrian Zbarcea]

Did you remove the camel-2.10.5 tag prior to re-running release:prepare?

The previous tag was not signed. Can you look if it'd be possible to 
sign the tag as well?


Cheers,
Hadrian


On 06/22/2013 10:48 AM, Christian Müller wrote:

Probably I was running into another/other issues of the
maven-release-plugin in combination with GIT:
http://jira.codehaus.org/browse/MRELEASE-812

I'm back to version 2.4.1 and use the following setting:

LANG='en_US.UTF-8'

Now the tag contains the right version. Will running the
mvn release:perform
in a few hours (I have to move now - with my machine...).

Best,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Sat, Jun 22, 2013 at 2:00 PM, Christian Müller 
christian.muel...@gmail.com wrote:


It looks like I run into this issue:
http://jira.codehaus.org/browse/MRELEASE-695
Will downgrade the maven-release-plugin to 2.2.1 (the version we used
before).

Keep you posted...

Best,
Christian


-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Fri, Jun 21, 2013 at 7:57 PM, Christian Müller 
christian.muel...@gmail.com wrote:


This first run didn't went well. The artifacts were not uploaded to Nexus
and the tagged Camel 2.10.5 release had the version number
2.10.5-SNAPSHOT...

Next try later today...

Best,
Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Fri, Jun 21, 2013 at 12:02 AM, Christian Müller 
christian.muel...@gmail.com wrote:


The
mvn release:prepare -DdryRun=true
went well yet.

Running
mvn release:prepare
now...

Best,
  Christian
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Wed, Jun 19, 2013 at 11:10 PM, Christian Müller 
christian.muel...@gmail.com wrote:


I'm working on it...

Best,
Christian

-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Mon, Jun 17, 2013 at 4:43 PM, Claus Ibsen claus.ib...@gmail.comwrote:


Hi

It would be great to get the 2.10.5 release started as this will help
iron out any glitches we have after the git migration.

There will always be X number of tickets that ppl want to be
fixed/backported/implemented etc. We cannot do them all. So doing a
release is better than not.




On Fri, Jun 14, 2013 at 5:45 PM, Christian Müller
christian.muel...@gmail.com wrote:

The Camel 2.10.5 release is overdue. We released Camel 2.10.4 almost

4

month ago...

The git mirror issue is resolved.

CAMEL-6309 and CAMEL-6309 are still open. Do we consider these as

critical?

If yes, somebody familiar with the camel-ftp component (Claus?)

should have

a look and fix this soon.

Do we wait for something else?

If we are ready beginning of next week, I could try to cut our first
release using GIT if Hadrian hasn't the time to do it. Otherwise I'm

happy

to support him by testing the release candidate...

Best,

Christian Müller
-

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Sun, May 26, 2013 at 7:10 PM, Hadrian Zbarcea hzbar...@gmail.com

wrote:



We have some time, as I am still waiting for infra to resolve the

git

mirror issue and I need to switch the release builds to use git tags
instead of svn.

Cheers,
Hadrian



On 05/25/2013 10:26 AM, Christian Müller wrote:


The two issues mentioned by Bengt are still open, but I can give

it a

try...

Christian

Sent from a mobile device
Am 24.05.2013 13:52 schrieb Claus Ibsen claus.ib...@gmail.com:

  Hi


Any news on the possibility of a 2.10.5 release.

The next release will actually be out 50th release. So that is a

good

milestone to reach :)



On Wed, May 15, 2013 at 2:32 PM, Hadrian Zbarcea 

hzbar...@gmail.com

wrote:

  Yep, it's about time. I will take care of the necessary

Re: git commit: CAMEL-6428: The camel-salesforce code base should support Java 6.

[Hadrian Zbarcea]

Thanks Babak for fixing the broken builds (w/ java 6).
Hadrian


On 06/05/2013 04:14 PM, bvah...@apache.org wrote:

Updated Branches:
   refs/heads/master ddb599ea4 - 5463fb1d2


CAMEL-6428: The camel-salesforce code base should support Java 6.

Project: http://git-wip-us.apache.org/repos/asf/camel/repo
Commit: http://git-wip-us.apache.org/repos/asf/camel/commit/5463fb1d
Tree: http://git-wip-us.apache.org/repos/asf/camel/tree/5463fb1d
Diff: http://git-wip-us.apache.org/repos/asf/camel/diff/5463fb1d

Branch: refs/heads/master
Commit: 5463fb1d2d2ae067920d1132a15557f72599e2fd
Parents: ddb599e
Author: Babak Vahdat bvah...@apache.org
Authored: Wed Jun 5 22:14:33 2013 +0200
Committer: Babak Vahdat bvah...@apache.org
Committed: Wed Jun 5 22:14:33 2013 +0200

--
  .../camel-salesforce-component/pom.xml |   10 +-
  .../salesforce/api/PicklistEnumConverter.java  |   10 +-
  parent/pom.xml |5 +
  3 files changed, 11 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/camel/blob/5463fb1d/components/camel-salesforce/camel-salesforce-component/pom.xml
--
diff --git a/components/camel-salesforce/camel-salesforce-component/pom.xml 
b/components/camel-salesforce/camel-salesforce-component/pom.xml
index 03db485..5d6c831 100644
--- a/components/camel-salesforce/camel-salesforce-component/pom.xml
+++ b/components/camel-salesforce/camel-salesforce-component/pom.xml
@@ -43,22 +43,18 @@
  dependency
groupIdorg.apache.camel/groupId
artifactIdcamel-core/artifactId
-  version${project.version}/version
  /dependency
  dependency
groupIdorg.eclipse.jetty/groupId
artifactIdjetty-client/artifactId
-  version${jetty-version}/version
  /dependency
  dependency
groupIdorg.eclipse.jetty/groupId
artifactIdjetty-util/artifactId
-  version${jetty-version}/version
  /dependency
  dependency
groupIdorg.eclipse.jetty/groupId
artifactIdjetty-io/artifactId
-  version${jetty-version}/version
  /dependency
  dependency
groupIdorg.codehaus.jackson/groupId
@@ -68,7 +64,6 @@
  dependency
groupIdcom.thoughtworks.xstream/groupId
artifactIdxstream/artifactId
-  version${xstream-version}/version
  /dependency
  dependency
groupIdorg.cometd.java/groupId
@@ -90,30 +85,27 @@
artifactIdjoda-time/artifactId
version${jodatime2-bundle-version}/version
  /dependency
+
  !-- logging --
  dependency
groupIdorg.slf4j/groupId
artifactIdslf4j-api/artifactId
-  version${slf4j-api-version}/version
  /dependency

  !-- testing --
  dependency
groupIdorg.slf4j/groupId
artifactIdslf4j-log4j12/artifactId
-  version${slf4j-api-version}/version
scopetest/scope
  /dependency
  dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
-  version${log4j-version}/version
scopetest/scope
  /dependency
  dependency
groupIdorg.apache.camel/groupId
artifactIdcamel-test/artifactId
-  version${project.version}/version
scopetest/scope
  /dependency
/dependencies

http://git-wip-us.apache.org/repos/asf/camel/blob/5463fb1d/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/api/PicklistEnumConverter.java
--
diff --git 
a/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/api/PicklistEnumConverter.java
 
b/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/api/PicklistEnumConverter.java
index 6b5c95b..9594e3d 100644
--- 
a/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/api/PicklistEnumConverter.java
+++ 
b/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/api/PicklistEnumConverter.java
@@ -37,7 +37,7 @@ public class PicklistEnumConverter implements Converter {
  try {
  Method getterMethod = aClass.getMethod(value);
  writer.setValue((String) getterMethod.invoke(o));
-} catch (ReflectiveOperationException e) {
+} catch (Exception e) {
  throw new IllegalArgumentException(
  String.format(Exception writing pick list value %s of type 
%s: %s,
  o, o.getClass().getName(), e.getMessage()),
@@ -53,14 +53,14 @@ public class PicklistEnumConverter implements Converter {
  Method factoryMethod = 

Re: [DISCUSS] - Apache Camel 2.10.5 release

[Hadrian Zbarcea]

Yep, it's about time. I will take care of the necessary changes to be 
build system and get ready for the release. What are the issues that 
still need to be finished for 2.10.5? Let's start closing down.


Hadrian



On 05/15/2013 03:10 AM, Claus Ibsen wrote:

Hi

Its been 2.5 months ago we released 2.10.4.

I think we should start considering doing a 2.10.5 release. Which is
also needed by the ServiceMix team for any new 4.5.x releases of
theirs.

And since we migrated to git, it would be a good idea to cut a release
to ensure that we can still do releases, and that we iron out any
issues we encounter after the svn - git change.

Any thoughts?

--
Claus Ibsen
-
www.camelone.org: The open source integration conference.

Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [DISCUSS] Move to a pure git based repo

[Hadrian Zbarcea]

Thanks Jon. Could we please get another nod?

Hadrian

On 05/06/2013 07:24 AM, Jon Anstey wrote:

Git repo at https://git-wip-us.apache.org/repos/asf/camel.git looks good to
me.


On Sun, May 5, 2013 at 10:41 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:


The migration is done. It looks ok to me and I would recommend asking
infra to make the git repo writable and close the issue [1]. My full test
over the weekend failed, but the problem was with our tests. After
completing the migration there are a few changes necessary for supporting
the release and I can take care of that.

Do we need to give more time for testing the repo, or we have enough
committers comfortable with the change?

Hadrian

[1] 
https://issues.apache.org/**jira/browse/INFRA-6197https://issues.apache.org/jira/browse/INFRA-6197


On 04/24/2013 04:36 PM, Hadrian Zbarcea wrote:


Actually, we may save some time and skip a vote, let's see if infra asks
for one. I created an issue for infra as a first step [1].

Cheers,
Hadrian

[1] 
https://issues.apache.org/**jira/browse/INFRA-6197https://issues.apache.org/jira/browse/INFRA-6197


On 04/24/2013 03:57 PM, Hadrian Zbarcea wrote:


Will do. Let's start with a formal vote.
Hadrian

On 04/24/2013 03:51 PM, Christian Müller wrote:


Hi Hadrian!

Do you consider to drive this topic after you collect many +1? ;-)

Best,
Christian


On Wed, Mar 27, 2013 at 9:01 PM, Hadrian Zbarcea hzbar...@gmail.com
wrote:

  Would that something that sounds appealing to most? I think most of us

already use mostly git anyway. The ASF infra now offers the choice.

Same question goes about camel-extra, I opened an issue there [1]
and as
much as I dislike bringing that on this list, well, I did it for lack
of a
better forum.

[1] 
http://code.google.com/a/apache-extras.org/p/camel-**http://code.google.com/a/**apache-extras.org/p/camel-**
extra/issues/detail?id=38http**://code.google.com/a/apache-**
extras.org/p/camel-extra/**issues/detail?id=38http://code.google.com/a/apache-extras.org/p/camel-extra/issues/detail?id=38






--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Re: [DISCUSS] Move to a pure git based repo

[Hadrian Zbarcea]

I added a comment to the INFRA jira, we should be back in business 
shortly. Thanks for everybody's patience.


Hadrian

On 05/06/2013 09:47 AM, Johan Edstrom wrote:

Cloned nicely. (And danged fast).

On May 6, 2013, at 7:45 AM, Christian Müller christian.muel...@gmail.com 
wrote:


The Git repository looks good to me too (master, branches, tags).

I tried to update our CI builds to use our new Git repository, but I got an
exception. There is also no explanation at https://git-wip-us.apache.org.
Could someone try whether he has more luck than me...

Best,
Christian


On Mon, May 6, 2013 at 3:43 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:


Thanks Jon. Could we please get another nod?

Hadrian


On 05/06/2013 07:24 AM, Jon Anstey wrote:


Git repo at 
https://git-wip-us.apache.org/**repos/asf/camel.githttps://git-wip-us.apache.org/repos/asf/camel.gitlooks
 good to
me.


On Sun, May 5, 2013 at 10:41 PM, Hadrian Zbarcea hzbar...@gmail.com
wrote:

The migration is done. It looks ok to me and I would recommend asking

infra to make the git repo writable and close the issue [1]. My full test
over the weekend failed, but the problem was with our tests. After
completing the migration there are a few changes necessary for supporting
the release and I can take care of that.

Do we need to give more time for testing the repo, or we have enough
committers comfortable with the change?

Hadrian

[1] 
https://issues.apache.org/jira/browse/INFRA-6197https://issues.apache.org/**jira/browse/INFRA-6197
https:/**/issues.apache.org/jira/**browse/INFRA-6197https://issues.apache.org/jira/browse/INFRA-6197





On 04/24/2013 04:36 PM, Hadrian Zbarcea wrote:

Actually, we may save some time and skip a vote, let's see if infra asks

for one. I created an issue for infra as a first step [1].

Cheers,
Hadrian

[1] 
https://issues.apache.org/jira/browse/INFRA-6197https://issues.apache.org/**jira/browse/INFRA-6197
https:/**/issues.apache.org/jira/**browse/INFRA-6197https://issues.apache.org/jira/browse/INFRA-6197





On 04/24/2013 03:57 PM, Hadrian Zbarcea wrote:

Will do. Let's start with a formal vote.

Hadrian

On 04/24/2013 03:51 PM, Christian Müller wrote:

Hi Hadrian!


Do you consider to drive this topic after you collect many +1? ;-)

Best,
Christian


On Wed, Mar 27, 2013 at 9:01 PM, Hadrian Zbarcea hzbar...@gmail.com
wrote:

  Would that something that sounds appealing to most? I think most of
us


already use mostly git anyway. The ASF infra now offers the choice.

Same question goes about camel-extra, I opened an issue there [1]
and as
much as I dislike bringing that on this list, well, I did it for lack
of a
better forum.

[1] 
http://code.google.com/a/**apache-extras.org/p/camel-**http://code.google.com/a/apache-extras.org/p/camel-**
h**ttp://code.google.com/a/apache-extras.org/p/camel-**http://code.google.com/a/**apache-extras.org/p/camel-**



extra/issues/detail?id=38**http**://code.google.com/a/**apache-**http://code.google.com/a/apache-**
extras.org/p/camel-extra/issues/detail?id=38http://extras.org/p/camel-extra/**issues/detail?id=38
http://**code.google.com/a/apache-**extras.org/p/camel-extra/**
issues/detail?id=38http://code.google.com/a/apache-extras.org/p/camel-extra/issues/detail?id=38










--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Re: [DISCUSS] Move to a pure git based repo

[Hadrian Zbarcea]

All set. We are officially running on git now. Please shout if you 
experience any issues. Christian, do you want to announce it on the main 
site or you want me to? We need to start updating the site, I'll do it 
in the evening if no one beasts me to it.


Cheers
Hadrian


On 05/06/2013 11:33 AM, Hadrian Zbarcea wrote:

I added a comment to the INFRA jira, we should be back in business
shortly. Thanks for everybody's patience.

Hadrian

On 05/06/2013 09:47 AM, Johan Edstrom wrote:

Cloned nicely. (And danged fast).

On May 6, 2013, at 7:45 AM, Christian Müller
christian.muel...@gmail.com wrote:


The Git repository looks good to me too (master, branches, tags).

I tried to update our CI builds to use our new Git repository, but I
got an
exception. There is also no explanation at
https://git-wip-us.apache.org.
Could someone try whether he has more luck than me...

Best,
Christian


On Mon, May 6, 2013 at 3:43 PM, Hadrian Zbarcea hzbar...@gmail.com
wrote:


Thanks Jon. Could we please get another nod?

Hadrian


On 05/06/2013 07:24 AM, Jon Anstey wrote:


Git repo at
https://git-wip-us.apache.org/**repos/asf/camel.githttps://git-wip-us.apache.org/repos/asf/camel.gitlooks
good to
me.


On Sun, May 5, 2013 at 10:41 PM, Hadrian Zbarcea hzbar...@gmail.com
wrote:

The migration is done. It looks ok to me and I would recommend asking

infra to make the git repo writable and close the issue [1]. My
full test
over the weekend failed, but the problem was with our tests. After
completing the migration there are a few changes necessary for
supporting
the release and I can take care of that.

Do we need to give more time for testing the repo, or we have enough
committers comfortable with the change?

Hadrian

[1]
https://issues.apache.org/jira/browse/INFRA-6197https://issues.apache.org/**jira/browse/INFRA-6197

https:/**/issues.apache.org/jira/**browse/INFRA-6197https://issues.apache.org/jira/browse/INFRA-6197






On 04/24/2013 04:36 PM, Hadrian Zbarcea wrote:

Actually, we may save some time and skip a vote, let's see if
infra asks

for one. I created an issue for infra as a first step [1].

Cheers,
Hadrian

[1]
https://issues.apache.org/jira/browse/INFRA-6197https://issues.apache.org/**jira/browse/INFRA-6197

https:/**/issues.apache.org/jira/**browse/INFRA-6197https://issues.apache.org/jira/browse/INFRA-6197






On 04/24/2013 03:57 PM, Hadrian Zbarcea wrote:

Will do. Let's start with a formal vote.

Hadrian

On 04/24/2013 03:51 PM, Christian Müller wrote:

Hi Hadrian!


Do you consider to drive this topic after you collect many +1? ;-)

Best,
Christian


On Wed, Mar 27, 2013 at 9:01 PM, Hadrian Zbarcea
hzbar...@gmail.com
wrote:

  Would that something that sounds appealing to most? I think
most of
us


already use mostly git anyway. The ASF infra now offers the
choice.

Same question goes about camel-extra, I opened an issue there [1]
and as
much as I dislike bringing that on this list, well, I did it
for lack
of a
better forum.

[1]
http://code.google.com/a/**apache-extras.org/p/camel-**http://code.google.com/a/apache-extras.org/p/camel-**

h**ttp://code.google.com/a/apache-extras.org/p/camel-**http://code.google.com/a/**apache-extras.org/p/camel-**




extra/issues/detail?id=38**http**://code.google.com/a/**apache-**http://code.google.com/a/apache-**

extras.org/p/camel-extra/issues/detail?id=38http://extras.org/p/camel-extra/**issues/detail?id=38

http://**code.google.com/a/apache-**extras.org/p/camel-extra/**
issues/detail?id=38http://code.google.com/a/apache-extras.org/p/camel-extra/issues/detail?id=38











--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Re: svn commit: r1477321 - in /camel/trunk: camel-core/src/main/java/org/apache/camel/component/bean/ camel-core/src/main/java/org/apache/camel/impl/ camel-core/src/main/java/org/apache/camel/processo

[Hadrian Zbarcea]

The notifications still go to commits@, but the subject is git commit: 
[comment]. Just if anybody wonders.


Cheers,
Hadrian



On 05/06/2013 03:46 PM, Christian Müller wrote:

Done.
My first commit into our brand new Git repo was a revert... :-(

Best,
Christian


On Thu, May 2, 2013 at 10:36 PM, Christian Müller 
christian.muel...@gmail.com wrote:


Will do...

Christian


On Tue, Apr 30, 2013 at 4:12 PM, Claus Ibsen claus.ib...@gmail.comwrote:


Hi Babak

Yeah I noticed this as well this morning. The good code comments which
made sense now is gone.
I think the code was easier to read and understand before.

I think we should revert it, or at least most part of it.



On Tue, Apr 30, 2013 at 4:06 PM, Babak Vahdat
babak.vah...@swissonline.ch wrote:

Hi,

Didn't have much luck with the commit mailing list so that trying this

way:




http://camel.465427.n5.nabble.com/svn-commit-r1477321-in-camel-trunk-camel-core-src-main-java-org-apache-camel-component-bean-camel-co-tp5731756p5731798.html


Babak



--
View this message in context:

http://camel.465427.n5.nabble.com/RE-svn-commit-r1477321-in-camel-trunk-camel-core-src-main-java-org-apache-camel-component-bean-camel-tp5731799.html

Sent from the Camel Development mailing list archive at Nabble.com.




--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [DISCUSS] Move to a pure git based repo

[Hadrian Zbarcea]

The migration is done. It looks ok to me and I would recommend asking 
infra to make the git repo writable and close the issue [1]. My full 
test over the weekend failed, but the problem was with our tests. After 
completing the migration there are a few changes necessary for 
supporting the release and I can take care of that.


Do we need to give more time for testing the repo, or we have enough 
committers comfortable with the change?


Hadrian

[1] https://issues.apache.org/jira/browse/INFRA-6197

On 04/24/2013 04:36 PM, Hadrian Zbarcea wrote:

Actually, we may save some time and skip a vote, let's see if infra asks
for one. I created an issue for infra as a first step [1].

Cheers,
Hadrian

[1] https://issues.apache.org/jira/browse/INFRA-6197


On 04/24/2013 03:57 PM, Hadrian Zbarcea wrote:

Will do. Let's start with a formal vote.
Hadrian

On 04/24/2013 03:51 PM, Christian Müller wrote:

Hi Hadrian!

Do you consider to drive this topic after you collect many +1? ;-)

Best,
Christian


On Wed, Mar 27, 2013 at 9:01 PM, Hadrian Zbarcea hzbar...@gmail.com
wrote:


Would that something that sounds appealing to most? I think most of us
already use mostly git anyway. The ASF infra now offers the choice.

Same question goes about camel-extra, I opened an issue there [1]
and as
much as I dislike bringing that on this list, well, I did it for lack
of a
better forum.

[1] http://code.google.com/a/**apache-extras.org/p/camel-**
extra/issues/detail?id=38http://code.google.com/a/apache-extras.org/p/camel-extra/issues/detail?id=38



--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

[Hadrian Zbarcea]

Hi,

You can of course implement a processor (or an endpoint) that 
encapsulates an execution engine powered by scxml (or bpel, or other 
language for that matter).


That discussion however took place in a different context, externalizing 
the dsl. But you are correct, we could implement support for scxml today 
in 2.x. Supporting scxml as a camel first class dsl though would require 
the refactoring we intend for 3.0.


In a similar context I had a few chats with Tammo from ODE, who has some 
very interesting ideas about refactoring the model, based on use cases 
they for BPEL with models simply too large to fit in memory (100+ Mb 
iirc). I think camel doesn't come even close to support such usecases 
because we don't support partial execution models.


I will talk about using Camel for long running processes at CamelOne 
2013 [1] (thanks to organizers for accepting my talk) and I could 
comment a bit on the need for partial execution models if there would be 
any interest in that.


Cheers,
Hadrian


[1] http://fusesource.com/apache-camel-conference-2013/

On 05/04/2013 06:56 AM, Murray.hughes wrote:

[19:23:13] hadrian another thing i looked at recently is scxml, i'll
write a component for it too, probably at acon

Does scxml really need v3?   Surely it can work just fine in camel 2?
I imagined two interfaces -
A producer that sends an event to an scxml executer, and a eventDispatcher
that receives sends from scxml, sending them to consumers.

examples using jexl:
  state id=state6
transition event=exchange target=state7
cond=_eventdata.getProperty('key') eq 7/
transition event=exchange target=state8
cond=_eventdata.in.body eq 7/
  /state
  state id=state7 final=true/

A producer drives it by triggering an event:
 //exchange.setProperty(key, new Integer(7));
 Message message = new DefaultMessage();
 message.setBody(new Integer(7));
 exchange.setIn(message);
 te = new TriggerEvent(exchange, TriggerEvent.SIGNAL_EVENT,
exchange);
 exec.triggerEvent(te);
Which transitions from state6 to state7.

Exchange headers can be saved in the state context domain model:
 message.setHeader(key, val);
 te = new TriggerEvent(exchange, TriggerEvent.SIGNAL_EVENT,
exchange);
 exec.triggerEvent(te);
  state id=state9 final=true
onentry
   assign name=dmone expr=_eventdata.in.header['key'] /
   /send
/onentry
  /state
But the exchange can't be updated and returned to camel (that I know of), so
its a one way trip.

To go from scxml to camel the scxml Send Event calls a custom
EventDispatcher:
  state id=state9 final=true
onentry
   assign name=dmone expr=_eventdata.in.header['key'] /
   send event='body' type='t' target='jms:x'
targettype='camelEndPoint' namelist=dmone dmtwo
   /send
/onentry
  /state
The scxml domain model items must be named on the send namelist (dmone,
dmtwo in the above example).

   EventDispatcher eventDispatcher = new EventDispatcher() {
public void cancel(String sendId) {
}
public void send(String sendId, String target, String 
targetType,
String event, Map params, Object hints, 
long delay,
List externalNodes) {
}};
An implementation of the EventDispatcher should be able to create an
exchange, assign the event to the body, the params to the exchange
headers/properties, look up the endpoint.
Again its a one-way trip.














--
View this message in context: 
http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-tp5727462p5732013.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Camel ical data format

[Hadrian Zbarcea]

Lukasz,

It looks good, it's not that big actually. Could you please create a JIRA?

Did you use it with camel-mail to send invites? Do you have some more 
complex example as well?


Cheers,
Hadrian

On 04/25/2013 11:39 AM, Hadrian Zbarcea wrote:

Interesting contribution. I will take a look later today. I did some
work with ics data in the past.

Cheers,
Hadrian


On 04/24/2013 04:39 PM, Łukasz Dywicki wrote:

Hey all,
I would like to ask if camel project is interested in picking up
another component to source repository. The component I am talking
about is created by me and allows use ical data structures.  You may
find camel-ical sources at github. [1]

It's tiny since all work is done in ical4j library (ASL compatible).
Hopefuly it's gonna be more osgi friendly [2] soon.

[1] https://github.com/splatch/camel-ical
[2] https://issues.apache.org/jira/browse/SMX4-1449

Cheers,
Lukasz

Re: [VOTE] Release Apache Camel 2.9.7

[Hadrian Zbarcea]

+1
Hadrian

On 04/24/2013 05:32 PM, Christian Müller wrote:

After 6 weeks of development, we have a new patch release candidate
apache-camel-2.9.7 ready. It comes with 14 issues resolved [1].
This will be the last planned Camel 2.9.x release. We will discontinue the
support for the camel-2.9.x branch afterwards.

Please find the staging repo here:
https://repository.apache.org/content/repositories/orgapachecamel-134/

The tarballs are here
https://repository.apache.org/content/repositories/orgapachecamel-134/org/apache/camel/apache-camel/2.9.7/

Tag:
http://svn.apache.org/repos/asf/camel/tags/camel-2.9.7/

Please review, help out with testing and vote to approve this release
binary. Please mention what you tested to prevent duplicate work. Your vote
counts!

[ ] +1 Release the binary as Apache Camel 2.9.7
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Thanks in advance,
Christian

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%20%222.9.7%22

Re: Camel ical data format

[Hadrian Zbarcea]

Interesting contribution. I will take a look later today. I did some 
work with ics data in the past.


Cheers,
Hadrian


On 04/24/2013 04:39 PM, Łukasz Dywicki wrote:

Hey all,
I would like to ask if camel project is interested in picking up another 
component to source repository. The component I am talking about is created by 
me and allows use ical data structures.  You may find camel-ical sources at 
github. [1]

It's tiny since all work is done in ical4j library (ASL compatible). Hopefuly 
it's gonna be more osgi friendly [2] soon.

[1] https://github.com/splatch/camel-ical
[2] https://issues.apache.org/jira/browse/SMX4-1449

Cheers,
Lukasz

Re: [DISCUSS] Move to a pure git based repo

[Hadrian Zbarcea]

Will do. Let's start with a formal vote.
Hadrian

On 04/24/2013 03:51 PM, Christian Müller wrote:

Hi Hadrian!

Do you consider to drive this topic after you collect many +1? ;-)

Best,
Christian


On Wed, Mar 27, 2013 at 9:01 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:


Would that something that sounds appealing to most? I think most of us
already use mostly git anyway. The ASF infra now offers the choice.

Same question goes about camel-extra, I opened an issue there [1] and as
much as I dislike bringing that on this list, well, I did it for lack of a
better forum.

[1] http://code.google.com/a/**apache-extras.org/p/camel-**
extra/issues/detail?id=38http://code.google.com/a/apache-extras.org/p/camel-extra/issues/detail?id=38

--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Re: [DISCUSS] Move to a pure git based repo

[Hadrian Zbarcea]

Actually, we may save some time and skip a vote, let's see if infra asks 
for one. I created an issue for infra as a first step [1].


Cheers,
Hadrian

[1] https://issues.apache.org/jira/browse/INFRA-6197


On 04/24/2013 03:57 PM, Hadrian Zbarcea wrote:

Will do. Let's start with a formal vote.
Hadrian

On 04/24/2013 03:51 PM, Christian Müller wrote:

Hi Hadrian!

Do you consider to drive this topic after you collect many +1? ;-)

Best,
Christian


On Wed, Mar 27, 2013 at 9:01 PM, Hadrian Zbarcea hzbar...@gmail.com
wrote:


Would that something that sounds appealing to most? I think most of us
already use mostly git anyway. The ASF infra now offers the choice.

Same question goes about camel-extra, I opened an issue there [1] and as
much as I dislike bringing that on this list, well, I did it for lack
of a
better forum.

[1] http://code.google.com/a/**apache-extras.org/p/camel-**
extra/issues/detail?id=38http://code.google.com/a/apache-extras.org/p/camel-extra/issues/detail?id=38


--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Re: Setup Camel 2.11 branch

[Hadrian Zbarcea]

I would move to git first. Branching is also easier, imho.

$0.02,
Hadrian

On 04/22/2013 03:30 AM, Claus Ibsen wrote:

Hi

We should setup a branch for 2.11
https://svn.apache.org/repos/asf/camel/branches/

And I think in the process there is something to setup for svnmerge to
have that working as well?
I am not sure how that is actually done.

Do we have some notes about this, and if not, we should IMHO add that,
maybe at the release guide page.



--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [DISCUSS] - Last Camel 2.9.7 release and retire this branch

[Hadrian Zbarcea]

Agree. Let's shoot for next week, end of this month.
Hadrian

On 04/22/2013 07:03 AM, Christian Müller wrote:

+1 for releasing it shortly.

Sent from a mobile device
Am 22.04.2013 09:36 schrieb Claus Ibsen claus.ib...@gmail.com:


Hi

When 2.11.0 is GA, we should IMHO do a last 2.9.x release, and then
retire that branch.
Though 2.9.6 was released in early March. So when would be a good time
to do that last 2.9.7 release? Should we wait a bit till eg june, or
should we release it sooner?

Its just that if we got trunk, 2.11, 2.10. and 2.9 braches, then there
is a lot to maintain.
So I dont think there is much activity on the 2.9 branch.

Also the 2.9 branch is now 16 months actie maintained.

Any thoughts?

--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [VOTE] Release Apache Camel 2.11.0

[Hadrian Zbarcea]

- No idea how/why Maven generated this folder:
https://svn.apache.org/repos/asf/camel/tags/camel-2.11.0/trunk/



My guess would be that Christian had some trouble with release:prepare 
and redid it without removing the tag. Happened to me before and I had 
to redo the release.


Hadrian

Re: [CANCEL][VOTE] Release Apache Camel 2.11.0

[Hadrian Zbarcea]

I would have voted -0.5 for this release because of the tag issue. I did 
test camel-2.11.0 with the Talend ESB and it went well.


Thinking about it I think the problem lies with the release:prepare 
phase which should check for the existence of the tag, because of the 
different behavior of svn copy (when the destination does not exist, it 
copies the source as the destination, but if it does it creates a copy 
within the destination folder). While the last release:prepare copies 
the files under the trunk/ subdir, the release:perform phase that 
follows checks out and build the parent tag folder.


Because of that I would suggest that release:prepare should fail if the 
tag exists. I am tempted to open an issue with the maven release plugin.


Thoughts?
Hadrian




On 04/08/2013 04:59 PM, Christian Müller wrote:

-1

I cancel this vote because of the issue with the tag. I will redo this
release now...

Best,
Christian


On Mon, Apr 8, 2013 at 4:11 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:


- No idea how/why Maven generated this folder:

https://svn.apache.org/repos/**asf/camel/tags/camel-2.11.0/**trunk/https://svn.apache.org/repos/asf/camel/tags/camel-2.11.0/trunk/



My guess would be that Christian had some trouble with release:prepare and
redid it without removing the tag. Happened to me before and I had to redo
the release.

Hadrian

Re: 3.0 Ideas

[Hadrian Zbarcea]

This has been mentioned a few times, but no agreement was reached. 
Actually we should drop the whole MEP as it makes little to no sense. It 
could be a hint at best. For me the rationale has little to do with JBI. 
The MEP only makes sense for an Endpoint (i.e. Producer or Consumer) but 
not for the Route. We might want to keep it as a header for edge cases 
like content (header) based routing, although there are a few other ways 
to solve that.


My $0.02,
Hadrian


On 04/03/2013 02:58 PM, Chris Geer wrote:

Just to throw out some other clean-up ideas for Camel 3.0.

I came across this thread here recently [1] talking about exchange patterns
and the history of camel. Now that JBI is essentially dead, does it make
sense to use Camel 3.0 to cleanup unused ties back to JBI? For example, get
rid of the exchange patterns that Camel doesn't really support (OutIn...).

Chris

[1] http://camel.465427.n5.nabble.com/Camel-Exchange-Patters-td2836060.html


On Wed, Apr 3, 2013 at 3:16 AM, Marco Westermann marwesterm...@gmx.dewrote:


Hi Gert,

just commented the jira,

regards, Marco

Am 29.03.2013 12:05, schrieb Gert Vanthienen:

  Hey Marco,


Just noticed your remark about the Exception you got when running
things in ServiceMix and I raised JIRA
https://issues.apache.org/**jira/browse/SMX4-1423https://issues.apache.org/jira/browse/SMX4-1423to
 ensure we look into
this before doing the next release.  The basic example I tried worked
fine, but that was only exposing a web service and not calling an
external service.  If you have a moment, it would be good if you could
add a comment to the JIRA issue explaining how we can reproduce your
problem?

Thanks in advance,

Gert


On Thu, Mar 28, 2013 at 4:21 PM, Marco Westermann marwesterm...@gmx.de
wrote:


Hi,

I use camel for more that one year now and it is actual great for
integration questions. One thing that I always mess around with is
calling
external web services (soap in general). And IMHO this is a central use
case
for soa / integration purposes. I received the impression that this
central
use case has not the weight it should have in an integegration framework
like camel. E.g. most examples with camel and cxf shows how to expose a
web
service, not how to consume one; there are maven archtypes which create
new
projects again only for exposing a service - there is no archtype for
consuming one. Even the camel in action book mostly covers cxf to use as
a
provider. So I think this should be made much easier with much more
examples. (or that easy that no example is neccessary)  If you know
openesb
/ glassfish esb there it is a matter of drag and drop a wsdl to the
project,
use an operation as endpoint (which you can use from a drop down box) and
specify the message-mapping (all is supported by easy clicky clicky)

Don't get me wrong. I really like camel very much, but I always have some
problems with:

* what component should I use (http, cxf, spring-ws) I think cxf should
be
the standard but should be easier to use
* most of my camel routes run in smx. my acutal problem in smx 4.5 (which
seems to be an osgi-problem) is that I get an exception which says that
no
org.apache.cxf.jaxws.spi.**ProviderImpl could be found. And I already
tried 4
hours to fix this issue without success..

These hurdles makes it to a costly task to implement a route which should
call a service. IMHO this should not take longer that 5 mins to implement
that if you already have a wsdl for the service.


I hope my suggestions are understandable / useful.

I which you all Happy Easter,

regards,

Marco Westermann

Re: [DISCUSS] - Moving towards Camel 2.11 release

[Hadrian Zbarcea]

I think there is a problem with camel-bindy as well. I am looking into 
it today.


Hadrian


On 04/02/2013 12:37 PM, Christian Müller wrote:

I think it would be good if we could include CAMEL-6218 into Camel 2.11.0.
May an ActiveMQ expert could have a look into it?

Best,
Christian


On Tue, Apr 2, 2013 at 5:11 PM, AlanFoster a...@alanfoster.me wrote:


Hi all,

Just posting to let you know that Christian Müller mentioned the
possibility
of CAMEL-6218 being included in the Camel 2.11 release
(https://issues.apache.org/jira/browse/CAMEL-6218).

There has been a lot of improvements for using the InOut MEP with the JMS
component, so it seems fitting to include such as fix in Camel 2.11

Alan



--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-Moving-towards-Camel-2-11-release-tp5725088p5730225.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: [DISCUSS] - Moving towards Camel 2.11 release

[Hadrian Zbarcea]

I have been advised to wait for the cxf-2.7.4 release, currently under 
vote. It has some rather important issues that we probably want to take. 
CXF committers on this list, please correct me if I am wrong.


As there are already a number of positive votes, I expect the cxf 
release to become public on Mon, so I could build 2.11.0 on Tue.


Cheers,
Hadrian


On 03/28/2013 08:18 AM, Hadrian Zbarcea wrote:

Christian, do you want to build this release or you want me to do it?
I'd also suggest doing a full build/test before the dryRun.

Hadrian



On 03/28/2013 05:22 AM, Christian Müller wrote:

Ok, I fixed [1] and removed it from the official Apache Camel SVN and
update the docs. I will commit it into Camel Extra and add the docs there
in a few minutes/hours.

We only have two outstanding issues [2].

I will run a mvn release:prepare -DdryRun=true to check whether I hit
some issues.
Do we already have a release manager for Camel 2.11 (to make sure
nobody is
waiting for somebody)?

[1] https://issues.apache.org/jira/browse/CAMEL-5483
[2]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%222.11.0%22


Best,
Christian

On Thu, Mar 28, 2013 at 2:18 AM, Raul Kripalani r...@evosent.com wrote:


Hi,

Managed to find time to commit the improvement for CAMEL-5698.

For CAMEL-5916 the fix is almost ready. Hopefully I'll reach in time
before
we cut the release. It'll be a great improvement for the usability of
camel-cxfrs.

Regards,
Raúl.

On Wed, Mar 27, 2013 at 1:30 PM, Claus Ibsen claus.ib...@gmail.com
wrote:


Hi

Oh yeah and CAMEL-5483 is a issue we must resolve. I think Hadrian is
working on that.


On Wed, Mar 27, 2013 at 2:25 PM, Claus Ibsen claus.ib...@gmail.com
wrote:

Hi

Okay we are getting there. The JIRA tracker has 3 tickets for 2.11.0.




https://issues.apache.org/jira/issues/?filter=12315472jql=project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%222.11.0%22



And I think Willem have almost/done his 2 tickets.

And the last ticket CAMEL-6042 requires some documentation about this
new functionality. I have asked Aaron to help with that. And it would
be great with a better set of unit tests as well.


--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen




--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [DISCUSS] - Moving towards Camel 2.11 release

[Hadrian Zbarcea]

Christian, do you want to build this release or you want me to do it?
I'd also suggest doing a full build/test before the dryRun.

Hadrian



On 03/28/2013 05:22 AM, Christian Müller wrote:

Ok, I fixed [1] and removed it from the official Apache Camel SVN and
update the docs. I will commit it into Camel Extra and add the docs there
in a few minutes/hours.

We only have two outstanding issues [2].

I will run a mvn release:prepare -DdryRun=true to check whether I hit
some issues.
Do we already have a release manager for Camel 2.11 (to make sure nobody is
waiting for somebody)?

[1] https://issues.apache.org/jira/browse/CAMEL-5483
[2]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%222.11.0%22

Best,
Christian

On Thu, Mar 28, 2013 at 2:18 AM, Raul Kripalani r...@evosent.com wrote:


Hi,

Managed to find time to commit the improvement for CAMEL-5698.

For CAMEL-5916 the fix is almost ready. Hopefully I'll reach in time before
we cut the release. It'll be a great improvement for the usability of
camel-cxfrs.

Regards,
Raúl.

On Wed, Mar 27, 2013 at 1:30 PM, Claus Ibsen claus.ib...@gmail.com
wrote:


Hi

Oh yeah and CAMEL-5483 is a issue we must resolve. I think Hadrian is
working on that.


On Wed, Mar 27, 2013 at 2:25 PM, Claus Ibsen claus.ib...@gmail.com
wrote:

Hi

Okay we are getting there. The JIRA tracker has 3 tickets for 2.11.0.




https://issues.apache.org/jira/issues/?filter=12315472jql=project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%222.11.0%22


And I think Willem have almost/done his 2 tickets.

And the last ticket CAMEL-6042 requires some documentation about this
new functionality. I have asked Aaron to help with that. And it would
be great with a better set of unit tests as well.


--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen




--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [DISCUSS] - Moving towards Camel 2.11 release

[Hadrian Zbarcea]

Ok, I'll run tests today as well, and when the trunk is ready we'll 
coordinate. It would be good for you to jump on irc now and then :)


Hadrian


On 03/28/2013 08:47 AM, Christian Müller wrote:

It depends when the last outstanding issues are fixed. If they are not
fixed today, my next time slot is Monday.
It's fine for me if you or some one else do the release.

In the meantime I do a dry run and fix some issues...

Best,
Christian

On Thu, Mar 28, 2013 at 1:18 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:


Christian, do you want to build this release or you want me to do it?
I'd also suggest doing a full build/test before the dryRun.

Hadrian




On 03/28/2013 05:22 AM, Christian Müller wrote:


Ok, I fixed [1] and removed it from the official Apache Camel SVN and
update the docs. I will commit it into Camel Extra and add the docs there
in a few minutes/hours.

We only have two outstanding issues [2].

I will run a mvn release:prepare -DdryRun=true to check whether I hit
some issues.
Do we already have a release manager for Camel 2.11 (to make sure nobody
is
waiting for somebody)?

[1] 
https://issues.apache.org/**jira/browse/CAMEL-5483https://issues.apache.org/jira/browse/CAMEL-5483
[2]
https://issues.apache.org/**jira/issues/?jql=project%20%**
3D%20CAMEL%20AND%20resolution%**20%3D%20Unresolved%20AND%**
20fixVersion%20%3D%20%222.11.**0%22https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%222.11.0%22

Best,
Christian

On Thu, Mar 28, 2013 at 2:18 AM, Raul Kripalani r...@evosent.com wrote:

  Hi,


Managed to find time to commit the improvement for CAMEL-5698.

For CAMEL-5916 the fix is almost ready. Hopefully I'll reach in time
before
we cut the release. It'll be a great improvement for the usability of
camel-cxfrs.

Regards,
Raúl.

On Wed, Mar 27, 2013 at 1:30 PM, Claus Ibsen claus.ib...@gmail.com
wrote:

  Hi


Oh yeah and CAMEL-5483 is a issue we must resolve. I think Hadrian is
working on that.


On Wed, Mar 27, 2013 at 2:25 PM, Claus Ibsen claus.ib...@gmail.com
wrote:


Hi

Okay we are getting there. The JIRA tracker has 3 tickets for 2.11.0.



  https://issues.apache.org/**jira/issues/?filter=12315472**

jql=project%20%3D%20CAMEL%**20AND%20resolution%20%3D%**
20Unresolved%20AND%**20fixVersion%20%3D%20%222.11.**0%22https://issues.apache.org/jira/issues/?filter=12315472jql=project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%222.11.0%22




And I think Willem have almost/done his 2 tickets.

And the last ticket CAMEL-6042 requires some documentation about this
new functionality. I have asked Aaron to help with that. And it would
be great with a better set of unit tests as well.


--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen





--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [DISCUSS] Move to a pure git based repo

[Hadrian Zbarcea]

Inline.
Hadrian

On 03/28/2013 09:35 AM, Daniel Kulp wrote:


On Mar 28, 2013, at 4:26 AM, Christian Müller christian.muel...@gmail.com 
wrote:


Hadrian, it looks like your timing is better than my one [1] ;-)

In general, I'm +1 to switch to Git (I use git-svn at Camel since I can
remember...).

It's not clear for me right now what we have to do with the projects which
are not located under trunk [2] - [6]. I don't think we need all of them.
But what's with our sandbox project/module? Do we have to move it into
trunk?

[1]
http://camel.465427.n5.nabble.com/DISCUSS-force-switching-from-SVN-to-GIT-td5715773.html
[2] https://svn.apache.org/repos/asf/camel/scripts/


These could just go in trunk/release_scripts or something.  Either that or just 
thrown away.  The publish_camel_distro.sh script certainly is wrong now.
Not used in ages. Relics from camel as an activemq subproject. New 
working versions exist at:

https://svn.apache.org/repos/asf/camel/trunk/etc/scripts/




[3] https://svn.apache.org/repos/asf/camel/website/


This would likely need to stay for now.

Right




[4] https://svn.apache.org/repos/asf/camel/sandbox/


No idea on this.
Not needed imho, because with git/github there are other ways to 
collaborate and share. Again, imho.





[5] https://svn.apache.org/repos/asf/camel/m2-repo/


I hope this isn't actually being used.   If it is, this needs to be fixed ASAP.   I think 
INFRA has announced in may that all the m2-repo things in svn will be 
disabled in May.   If there is anything left in there that is needed, it NEEDS to get 
pushed to central.
Not needed anymore, afaik, but will check to make sure. In any event, if 
used, it must be resolved asap, regardless of a move to git.





[6] https://svn.apache.org/repos/asf/camel/ide/


Discarded.  Has been touched in 5 years.

True.



All of this remains in SVN's history forever so not a big deal.  If we ever 
need any of it back, it will always be there.

Dan




Best,
Christian

On Wed, Mar 27, 2013 at 9:01 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:


Would that something that sounds appealing to most? I think most of us
already use mostly git anyway. The ASF infra now offers the choice.

Same question goes about camel-extra, I opened an issue there [1] and as
much as I dislike bringing that on this list, well, I did it for lack of a
better forum.

[1] http://code.google.com/a/**apache-extras.org/p/camel-**
extra/issues/detail?id=38http://code.google.com/a/apache-extras.org/p/camel-extra/issues/detail?id=38

--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Re: [HEADS-UP] Possible issue with neo4j

[Hadrian Zbarcea]

On Wednesday, March 27, 2013 at 9:26 AM, Hadrian Zbarcea wrote:


I've been asked today by a fellow ASFer if it's ok for us to distribute
neo4j and I got to look more into it. As neo4j is GPL3 and virally
infects whatever uses it, I think we do have a problem that needs to be
resolved before the 2.11.0 release.

My guts instinct says that we'll have to pull the camel-spring-neo4j
component out and host it maybe at camel-extra, but we'll see in the
coming days.

Cheers,
Hadrian


--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/










--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: [HEADS-UP] Possible issue with neo4j

[Hadrian Zbarcea]

Christian,

Personally, I'd go ahead and move it to camel-extra, *still* under the 
ALv2 license. That would make it easier to move it back without 
relicensing *if* at a later point neo4j would release a binding under 
ALv2. I don't have any cycles this week but hopefully you or Henryk 
could find some time.


Alternatively, we could wait for the comments to LEGAL-162, but would 
rather save some time and not block the release for too long.


My $0.02,
Hadrian


On 03/27/2013 12:09 PM, Christian Müller wrote:

Good catch Hadrian!

I propose/support to move this component to Camel extra.
We should also move to documentation [1] to Camel extra and update the
Camel components page [2] with the new home of this component.

I can do this/support if you want (I'm sick at home and have some time ;-)
).

[1] http://camel.apache.org/neo4j
[2] http://camel.apache.org/components.html

Best.
Christian

On Wed, Mar 27, 2013 at 4:36 PM, Christian Ohr christian@gmail.comwrote:


Hi,

I'm frequently doing license compliance exercises at work, and an ASL2
project depending on a (A)GPL lib  is clearly *very* troublesome due to
GPL's 'viral' character of imposing licensing conditions to derivative
work. Regardless of whether this dependency is direct or transitive.

Things can be subtle, though, e.g. MongoDB is also (A)GPL, but the
mongo-java-driver that camel-mongodb depends upon is ASL2 (
https://github.com/mongodb/mongo-java-driver/blob/master/LICENSE.txt)

Still I think the Camel project needs to establish some kind of governance
to make sure that contributions of new components don't result in license
compliance violations.

cheers
Christian


2013/3/27 Claus Ibsen claus.ib...@gmail.com


On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies rajdav...@gmail.com
wrote:

Just looking at the spring-data-neo4 (which is ASL 2) - it uses

directly

org.neo4j.graphdb directly - which is an (A)GPLv3 licence.

I agree with Hadrian, we would be infecting users of camel-spring-neo4j

with (A)GPLv3 - which is very undesirable. Unless I've missed a different
licence for the client-side piece of neo4j that meets with our licence
restrictions[2] - it should be moved to camel-extra with appropriate
warnings.


thanks,

Rob

[2]http://www.apache.org/legal/3party.html



Yeah if it uses directly a JAR that is GPL then its a problem.

Great catch Hadrian just in time. We haven't done any releases with
this camel-spring-neo4j component.
So we should move it to camel-extra.





On 27 Mar 2013, at 02:18, Willem jiang willem.ji...@gmail.com wrote:


Hi Hadrian,

We don't use the neo4j directly, the camel-spring-neo4j is based on

the

spring-data-neo4j[1] which is ASF license.

I'm not quite sure if it is OK for us to host and distribute the

camel-spring-neo4j in ASF, so please let us know the result :)


[1]



https://github.com/SpringSource/spring-data-neo4j/blob/master/license.txt


--
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (

http://willemjiang.blogspot.com/)

(English)

  http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem





On Wednesday, March 27, 2013 at 9:26 AM, Hadrian Zbarcea wrote:


I've been asked today by a fellow ASFer if it's ok for us to

distribute

neo4j and I got to look more into it. As neo4j is GPL3 and virally
infects whatever uses it, I think we do have a problem that needs to

be

resolved before the 2.11.0 release.

My guts instinct says that we'll have to pull the camel-spring-neo4j
component out and host it maybe at camel-extra, but we'll see in the
coming days.

Cheers,
Hadrian


--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/










--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

[DISCUSS] Move to a pure git based repo

[Hadrian Zbarcea]

Would that something that sounds appealing to most? I think most of us 
already use mostly git anyway. The ASF infra now offers the choice.


Same question goes about camel-extra, I opened an issue there [1] and as 
much as I dislike bringing that on this list, well, I did it for lack of 
a better forum.


[1] 
http://code.google.com/a/apache-extras.org/p/camel-extra/issues/detail?id=38


--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

[HEADS-UP] Possible issue with neo4j

[Hadrian Zbarcea]

I've been asked today by a fellow ASFer if it's ok for us to distribute 
neo4j and I got to look more into it. As neo4j is GPL3 and virally 
infects whatever uses it, I think we do have a problem that needs to be 
resolved before the 2.11.0 release.


My guts instinct says that we'll have to pull the camel-spring-neo4j 
component out and host it maybe at camel-extra, but we'll see in the 
coming days.


Cheers,
Hadrian


--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Re: [DISCUSS] - Moving towards Camel 2.11 release

[Hadrian Zbarcea]

amqp is failing for me. Will look into it this afternoon.
Hadrian

On 03/15/2013 02:48 AM, Claus Ibsen wrote:

On Thu, Mar 14, 2013 at 3:29 PM, Claus Ibsen claus.ib...@gmail.com wrote:

Hi

Okay I fixed a few issues with the Karaf features so they all now work
and the camel-itest-karaf all passes on linux and windows as well.

The actual OSGi tests in camel-itest-osgi is currently being tested on
my Windows XP box.



Okay all the OSGi tests passes now on Windows. There was a xslt bug in
camel-core when using Windows.
That is now fixed, so the tests passes.







--
Claus Ibsen
-
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

[RESULT][VOTE] Release Apache Camel 2.9.6

[Hadrian Zbarcea]

Result passes with:

[7] +1 (cschneider, dkulp, rajdavies, janstey, cibsen, ningjiang, hadrian)
[0] -1
[1] +0 (cmueller)

The artifacts will be released to the public maven repo immediately, 
followed by the ASF site and mirror and the public announcement.


Many thanks to all who took the time to test and vote.
Hadrian



On 03/04/2013 11:51 PM, Hadrian Zbarcea wrote:

We have a new patch release candidate apache-camel-2.9.6 ready. It comes
with approximately 63 issues resolved: improvements and bug fixes [1].

Please find the staging repo here:
https://repository.apache.org/content/repositories/orgapachecamel-330/

The tarballs are here
https://repository.apache.org/content/repositories/orgapachecamel-330/org/apache/camel/apache-camel/2.9.6/


Tag:
http://svn.apache.org/repos/asf/camel/tags/camel-2.9.6/

Please review, help out with testing and vote to approve this release
binary. Your vote counts!

[ ] +1 Release the binary as Apache Camel 2.9.6
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Here's my +1.
Hadrian

[1]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12323592

Re: [RESULT][VOTE] Release Apache Camel 2.10.4

[Hadrian Zbarcea]

Yes, that's what I was doing now. I am also releasing 2.9.6 this evening.

Cheers,
Hadrian



On 03/04/2013 09:02 PM, Christian Müller wrote:

I updated our JIRA to make Camel 2.10.4 as released.
Can you send out the public announcement soon, so that our user know Camel
2.10.4 is out? Otherwise I can volunteer here...

Best,
Christian

On Tue, Feb 26, 2013 at 7:08 AM, Hadrian Zbarcea hzbar...@gmail.com wrote:


Result passes with:

[4] +1 (cschneider, dkulp, cibsen, hadrian)
[0] -1
[1] +0 (bvahdat)

The artifacts will be released to the public maven repo immediately,
followed by the ASF site and mirror and the public announcement.

Many thanks to all who took the time to test and vote.
Hadrian



On 02/22/2013 09:16 AM, Hadrian Zbarcea wrote:


We have a new patch release candidate apache-camel-2.10.4 ready. It
comes with approximately 105 issues resolved: improvements and bug fixes
[1].

Please find the staging repo here:
https://repository.apache.org/**content/repositories/**
orgapachecamel-294/https://repository.apache.org/content/repositories/orgapachecamel-294/

The tarballs are here
https://repository.apache.org/**content/repositories/**
orgapachecamel-294/org/apache/**camel/apache-camel/2.10.4/https://repository.apache.org/content/repositories/orgapachecamel-294/org/apache/camel/apache-camel/2.10.4/


Tag:
http://svn.apache.org/repos/**asf/camel/tags/camel-2.10.4/http://svn.apache.org/repos/asf/camel/tags/camel-2.10.4/

Please review, help out with testing and vote to approve this release
binary. Your vote counts!

[ ] +1 Release the binary as Apache Camel 2.10.4
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Here's my +1.
Hadrian

[1]
https://issues.apache.org/**jira/secure/ReleaseNote.jspa?**
projectId=12311211version=**12323558https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12323558







--

Re: [RESULT][VOTE] Release Apache Camel 2.10.4

[Hadrian Zbarcea]

It won't propagate to the mirrors until tomorrow though.
Hadrian

On 03/04/2013 09:21 PM, Christian Müller wrote:

Great thanks!

Best,
Christian

On Tue, Mar 5, 2013 at 3:15 AM, Hadrian Zbarcea hzbar...@gmail.com wrote:


Yes, that's what I was doing now. I am also releasing 2.9.6 this evening.

Cheers,
Hadrian




On 03/04/2013 09:02 PM, Christian Müller wrote:


I updated our JIRA to make Camel 2.10.4 as released.
Can you send out the public announcement soon, so that our user know Camel
2.10.4 is out? Otherwise I can volunteer here...

Best,
Christian

On Tue, Feb 26, 2013 at 7:08 AM, Hadrian Zbarcea hzbar...@gmail.com
wrote:

  Result passes with:


[4] +1 (cschneider, dkulp, cibsen, hadrian)
[0] -1
[1] +0 (bvahdat)

The artifacts will be released to the public maven repo immediately,
followed by the ASF site and mirror and the public announcement.

Many thanks to all who took the time to test and vote.
Hadrian



On 02/22/2013 09:16 AM, Hadrian Zbarcea wrote:

  We have a new patch release candidate apache-camel-2.10.4 ready. It

comes with approximately 105 issues resolved: improvements and bug fixes
[1].

Please find the staging repo here:
https://repository.apache.org/content/repositories/**https://repository.apache.org/**content/repositories/**
orgapachecamel-294/https://**repository.apache.org/content/**
repositories/orgapachecamel-**294/https://repository.apache.org/content/repositories/orgapachecamel-294/




The tarballs are here
https://repository.apache.org/content/repositories/**https://repository.apache.org/**content/repositories/**
orgapachecamel-294/org/apache/camel/apache-camel/2.10.4/h**
ttps://repository.apache.org/**content/repositories/**
orgapachecamel-294/org/apache/**camel/apache-camel/2.10.4/https://repository.apache.org/content/repositories/orgapachecamel-294/org/apache/camel/apache-camel/2.10.4/





Tag:
http://svn.apache.org/repos/asf/camel/tags/camel-2.10.4/http://svn.apache.org/repos/**asf/camel/tags/camel-2.10.4/
h**ttp://svn.apache.org/repos/**asf/camel/tags/camel-2.10.4/http://svn.apache.org/repos/asf/camel/tags/camel-2.10.4/





Please review, help out with testing and vote to approve this release
binary. Your vote counts!

[ ] +1 Release the binary as Apache Camel 2.10.4
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Here's my +1.
Hadrian

[1]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?https://issues.apache.org/**jira/secure/ReleaseNote.jspa?**
projectId=12311211version=12323558https://issues.**
apache.org/jira/secure/**ReleaseNote.jspa?projectId=**
12311211version=12323558https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12323558










--





--

[VOTE] Release Apache Camel 2.9.6

[Hadrian Zbarcea]

We have a new patch release candidate apache-camel-2.9.6 ready. It comes 
with approximately 63 issues resolved: improvements and bug fixes [1].


Please find the staging repo here:
https://repository.apache.org/content/repositories/orgapachecamel-330/

The tarballs are here
https://repository.apache.org/content/repositories/orgapachecamel-330/org/apache/camel/apache-camel/2.9.6/

Tag:
http://svn.apache.org/repos/asf/camel/tags/camel-2.9.6/

Please review, help out with testing and vote to approve this release
binary. Your vote counts!

[ ] +1 Release the binary as Apache Camel 2.9.6
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Here's my +1.
Hadrian

[1]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12323592 



--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

[RESULT][VOTE] Release Apache Camel 2.10.4

[Hadrian Zbarcea]

Result passes with:

[4] +1 (cschneider, dkulp, cibsen, hadrian)
[0] -1
[1] +0 (bvahdat)

The artifacts will be released to the public maven repo immediately, 
followed by the ASF site and mirror and the public announcement.


Many thanks to all who took the time to test and vote.
Hadrian


On 02/22/2013 09:16 AM, Hadrian Zbarcea wrote:

We have a new patch release candidate apache-camel-2.10.4 ready. It
comes with approximately 105 issues resolved: improvements and bug fixes
[1].

Please find the staging repo here:
https://repository.apache.org/content/repositories/orgapachecamel-294/

The tarballs are here
https://repository.apache.org/content/repositories/orgapachecamel-294/org/apache/camel/apache-camel/2.10.4/


Tag:
http://svn.apache.org/repos/asf/camel/tags/camel-2.10.4/

Please review, help out with testing and vote to approve this release
binary. Your vote counts!

[ ] +1 Release the binary as Apache Camel 2.10.4
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Here's my +1.
Hadrian

[1]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12323558

[VOTE] Release Apache Camel 2.10.4

[Hadrian Zbarcea]

We have a new patch release candidate apache-camel-2.10.4 ready. It 
comes with approximately 105 issues resolved: improvements and bug fixes 
[1].


Please find the staging repo here:
https://repository.apache.org/content/repositories/orgapachecamel-294/

The tarballs are here
https://repository.apache.org/content/repositories/orgapachecamel-294/org/apache/camel/apache-camel/2.10.4/

Tag:
http://svn.apache.org/repos/asf/camel/tags/camel-2.10.4/

Please review, help out with testing and vote to approve this release
binary. Your vote counts!

[ ] +1 Release the binary as Apache Camel 2.10.4
[ ] -1 Veto the release (provide specific comments)
Vote is open for at least 72 hours.

Here's my +1.
Hadrian

[1]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211version=12323558


--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/

Re: [DISCUSS] Camel 2.10.4 and 2.9.6 releases

[Hadrian Zbarcea]

Apologies for the delay. I've been at a multispeak conference all week. 
I learned to never try a camel release again from a hotel network. I 
believe they are throttling down packets which led to 
timeouts/disconnection at various points while uploading the artifacts.


Anyway, 2.10.4 is under vote with 2.9.6 to be done this weekend.

Many thanks for the patience,
Hadrian

On 02/20/2013 09:52 PM, Hadrian Zbarcea wrote:

Looks like I have some problem uploading the artifacts during
release:perform. I may have to redo this release.

Thanks for the patience,
Hadrian

On 02/19/2013 02:53 PM, Christian Müller wrote:

Thanks for the update!

Sent from a mobile device
Am 19.02.2013 06:48 schrieb Hadrian Zbarcea hzbar...@gmail.com:


The full tests are still running, looks like I'll only finish the
release
tomorrow.
Hadrian

On 02/18/2013 08:43 AM, Hadrian Zbarcea wrote:


The cxf features 2.6.6.1 are now released. I'll do the release builds
today for camel-2.10.4. If you have any more fix for 2.10.4 that
must go
in, please let me know now.

Cheers,
Hadrian

On 02/15/2013 09:10 AM, Hadrian Zbarcea wrote:


Yes, vote for cxf 2.6.6.1 fixing the features issue is under way,
due to
close tomorrow.
Hadrian


On 02/15/2013 06:26 AM, Claus Ibsen wrote:


On Tue, Feb 12, 2013 at 6:14 PM, Hadrian Zbarcea hzbar...@gmail.com
wrote:


There is another security issue in CXF that may require a
release. It's
being investigated now. The backup option is to make a copy of
the cxf
features in camel temporarily. We'll know in a couple of days and
redo the
release.



Any update on this?



  Cheers,

Hadrian


On 02/09/2013 09:47 AM, Hadrian Zbarcea wrote:



Claus, there is :). It's the -P validate profile in
platforms/karaf/features that caught it.

Yeah the cxf 2.6.6 features are pretty much unusable. I am sure Dan
will
do something about it. Instead of reverting to 2.6.5 there is
also the
option of copying the relevant features from cxf to camel (or
all of
them), which could be a temporary fix for the cxf community
(don't use
the cxf features, use the camel ones). That's what I am ready to
do,
but
I'll wait for Dan's comment first.

Cheers,
Hadrian


On 02/09/2013 03:02 AM, Claus Ibsen wrote:



On Sat, Feb 9, 2013 at 4:47 AM, Hadrian Zbarcea
hzbar...@gmail.com
wrote:



Fixed the msv issue and hit another one. Looks like the
apache-cxf-2.6.6-features.xml [1] is invalid:
${cxf.james.mim4j.version} is
not resolved :(.



Ah darn. CXF 2.6.5 does not have that issue, so in worst case
we can
revert to this version.

As Camel, Karaf, SMX etc may have similar issues in the future
with a
feature file having ${ } unresolved placeholders.

Maybe there should be a maven goal that checks for this.
I assume there is some Maven Ninjas that can put together the XML
plugin stuff needed for this.

Then we catches this during before releasing.


  This looks like the only issue that remains to workaround.
I'll try

to build
the releases over the weekend.

Cheers,
Hadrian

[1]

http://repo1.maven.org/maven2/**org/apache/cxf/karaf/apache-**
cxf/2.6.6/apache-cxf-2.6.6-**features.xmlhttp://repo1.maven.org/maven2/org/apache/cxf/karaf/apache-cxf/2.6.6/apache-cxf-2.6.6-features.xml







On 02/08/2013 07:56 AM, Hadrian Zbarcea wrote:




Tests are failing for me in full builds. I am working on it and
will
release asap.

Cheers,
Hadrian

On 02/08/2013 04:21 AM, Claus Ibsen wrote:




On Tue, Feb 5, 2013 at 4:26 AM, Hadrian Zbarcea
hzbar...@gmail.com
wrote:




For some reason still not clear to me, my mail client didn't
get the
original thread started by Claus. That points to consensus
that
it's
time
for a 2.10.4. I started a full build overnight and I am
planning to
build
the 2.10.4 release later this week, Wed or Thu.



Any update on this?


  Regarding 2.9.x, we did decided a while ago to support 2
versions

back,
right? So even if we wouldn't need a 2.9.6 release now, it
should
still be
supported until 2.11.0 is out. However with almost 50 issues
fixed, I
think
we should get 2.9.6 out the door as well, so I'm planning to
release
it this
week as well.

Is there anything you're working on that should make it into
2.10.4 and
2.9.6? Please shout now.

Cheers,
Hadrian

Re: [DISCUSS] Scala components in ASF Camel

[Hadrian Zbarcea]

I would give this a bit more time, maybe after apachecon. While Willem 
stated that it's easy to move code back and forth, his statement is not 
correct. It would be if there were no external contributors, otherwise 
you have ip issues (which is different than the way it's licensed).


I think a marketplace is a good idea, but personally I will not spend 
time on the scala ecosystem. It's not clear to me if we all understand 
the solution you propose the same way. I am not even sure if we all 
understand/agree on the problem the same way.


My $0.02,
Hadrian



On 02/22/2013 09:55 AM, Henryk Konsek wrote:

+1 I like this proposal.


I'll create the GitHub organization called 'camel-marketplace'. Then
I'll create 'camel-scala' and 'camel-scala-extra' projects under its
umbrella. If anybody of you want to be added as an administrator to
the 'camel-marketplace' organization, please just drop me a line.

All the contributions to the 'camel-scala' will be released under
Apache license. Contributions under incompatible licenses will be
committed to 'camel-scala-extra'.

After I create the projects together with some nice homepages for
them, I'll add appropriate references to the Camel Contributing [1]
and Camel Components [1] pages. From this point forward we could refer
to these projects as to the official home for the Camel components
written in Scala.

The versioning and the life cycle of Scala communities will be
synchronized with ASF Camel release the same way as Camel Extra is.

What do you think?

[1] http://camel.apache.org/contributing.html
[2] http://camel.apache.org/components.html

--
Henryk Konsek
http://henryk-konsek.blogspot.com

Re: Message History EIP/Message Store status

[Hadrian Zbarcea]

The claim check pattern is a bit more complex that. I will be touching 
on it in my presentation at ApacheCon next week.


Cheers,
Hadrian

On 02/21/2013 06:26 PM, Christian Ohr wrote:

HI Henryk,

A claim check EIP is definitely an excellent use case for a message store.

Regarding your example - it is probably a matter of taste, but I would rather
* register a (global) default message store with the CamelContext
rather than in the route
* allow all applicable EIPs to override this
* not set the CLAIM_CHECK header again (what for?)

One issue with such a claim check is that you should stay in control
about what is temporarily pushed to the store (e.g. the body, or a
specific header, or...). Later when you claim back the data, the
operation must be basically reversed. Then, who is in charge to
remember the destination - the claimCheck/claim EIP pair or the
developer? In the latter case, claiming back the data might look more
like applying a special expression

...
// store and receive unique id in reserved CLAIM_CHECK header
.claimCheck(myStore, header('myBigHeader'))
...
// and claim back presenting the unique id
.setHeader('myBigHeader', claim(myStore))
...

Does this make sense?

cheers
Christian

2013/2/21 Henryk Konsek hekon...@gmail.com:

You are invited add, comment, criticize etc.


Hi Christian,

Looks good :) .

I've added some examples to Wiki demonstrating my vision of the usage
of Claim Check EIP.

// Setting default message store for route:
defaultMessageStore(myStore);

// Claim Check EIP store:
// 1) Store body.
// 2) Set body to null.
// 3) Set Exchange.CLAIM_CHECK header to unique claim id.
from(...).claimCheck().to(...);

// Claim Check EIP read:
// 1) Lookup for the Exchange.CLAIM_CHECK header value.
// 2) Read the message.
// 3) Set body to the value fetched from the store.
from(...).setHeader(Exchange.CLAIM_CHECK, const(id)).claim().to(...);

I'm curious if my claim check DSL design is similar to yours.

Best regards.

--
Henryk Konsek
http://henryk-konsek.blogspot.com