Hi
Please use the @user mailing list / forum for this kind of question.
See here for details about the @dev vs @user mailing lists
http://camel.apache.org/mailing-lists.html
On Thu, Aug 22, 2013 at 5:42 AM, contactreji wrote:
> Hi all
> Hope you all having good time riding the camel! :-p
>
> We
Hi all
Hope you all having good time riding the camel! :-p
Well, I am kinda working upon security part in web service.
- I have a webservice exposing a port address enabled with HTTPS.
- They have given me the keystore along with all relevant passwords.
Now I need to call the webservice with h
The Apache Jenkins build system has built Camel.trunk.notest (build #1966)
Status: Failure
Check console output at https://builds.apache.org/job/Camel.trunk.notest/1966/
to view the results.
Hi Christian,
The patch looks good, I will take care of it today.
--
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: willemjia
Hi all,
I've submitted a patch for CAMEL-6545.
Can someone review it?
Attached to
https://issues.apache.org/jira/browse/CAMEL-6545
I can do a pull request if that's the preferred process...
Sorry about the noise with the previous message, sent prematurely.
--
*Christian Posta*
http://www
In a project I worked on, we had a similar structure. Translated to Camel
artifacts, it would result in the following:
- camel pom: Defines generic properties, deployment profiles, plugin
management, etc
- new camel-oss pom i.e. oss BoM: has top-level 'camel' artifact as parent,
defines properties
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
With the "bom" approach, you don't use properties to define the
versions (you can but it seems unnecessary IMHO). All of the
dependency versions are defined in the parent pom in the
section, as normal dependencies.
On Wed, Aug 21, 2013 at 9:55 AM, Jon Anstey wrote:
> When using import scope tho
Is all of this really solving some big problem? I really don't see a
huge benefit here.
On Wed, Aug 21, 2013 at 9:27 AM, Jon Anstey wrote:
> I like the idea of having a pom just for versions. We could use Babak's
> proposal but instead of introducing another level of inheritance, just make
> one
When using import scope though you only get managed dependencies - no
properties. Need to inherit a parent pom to get properties.
On Wed, Aug 21, 2013 at 11:15 AM, James Strachan
wrote:
> I wonder if we should experiment with a BOM file?
> http://stackoverflow.com/questions/14874966/how-to-use-b
I wonder if we should experiment with a BOM file?
http://stackoverflow.com/questions/14874966/how-to-use-bom-iwith-maven
then the camel project could import the BOM file and other projects
could share it too (without having to go the parent pom.xml route).
On 15 August 2013 12:26, Claus Ibsen w
I missed begining of this discussion, however can't you simply use import scope
in Maven dependency?
Cheers,
Łukasz Dywicki
--
l...@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
Wiadomość napisana przez Jon Anstey w dniu 21 sie 2013, o
godz. 15:27:
I like the idea of having a pom just for versions. We could use Babak's
proposal but instead of introducing another level of inheritance, just make
one of the current top level poms mostly properties and push everything
else into the other pom. So, either org.apache.camel:camel or
org.apache.camel:
Sounds good to me. There are a lot of cool new features and components that
would be good to get released.
On Wed, Aug 21, 2013 at 7:09 AM, Willem jiang 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 t
Hi Colm
I attached the missing files. Please have alook into the JIRA.
Regards Franz
On Wed, Aug 21, 2013 at 12:46 PM, Colm O hEigeartaigh
wrote:
> Thanks for the feedback. I will have a go at reviewing the patch for this
> task. Franz, could you please attach all missing (new) files to the JI
Thanks for the feedback. I will have a go at reviewing the patch for this
task. Franz, could you please attach all missing (new) files to the JIRA so
that I can fully run the tests?
Colm.
On Wed, Aug 21, 2013 at 10:44 AM, Claus Ibsen wrote:
> On Wed, Aug 21, 2013 at 8:33 AM, Babak Vahdat
> wr
On Wed, Aug 21, 2013 at 8:33 AM, Babak Vahdat
wrote:
> Hi
>
> I guess as this will be part of the upcoming 2.12.0 release, the users can
> make use of it as a component even if we stick to a data format
> implementation:
>
> http://camel.apache.org/dataformat-component.html
>
Ah yeah, that gives
Hi
Yeah the components gives more flexibility. And a component can also
do the same work as a data format would do, its just how its
represented in the DSL.
If there is a need for a data format for the signer, then we could add
that as a new data format, as Franz pointed out, it has different
con
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
19 matches
Mail list logo
