camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [CONF] Apache Camel > Scalate
Date Thu, 21 Jul 2011 07:25:31 GMT
Hi Claus,

I think we should also list external components. We only need to make 
sure it is visible that they are not part of the package and not 
supported by the camel community.

So I think we could have an external components header at the end of the 
components page where we list external components. These should just 
link to an external documentation though. The details
should not be on our camel wiki.

So I think the message to external component developers should be that 
we are happy about any good external components but if they want it to 
be directly part of camel and supported by the community they will have 
to donate it to the camel project.


Am 21.07.2011 08:08, schrieb Claus Ibsen:
> Hi
> Yeah I seemed a bit rushed.
> On the components page, Dan added since in the bottom a table with
> much related components, but as the components is not included in the
> Camel source tree, he separated them from the top table.
> Maybe we could add the scalete component to this table in the bottom?
> When someone creates a Camel components there is always a decision to
> be made, whether the component should be hosted as part of the 3rd
> party component, or donated and included at Apache Camel. Sometimes it
> makes most sense to include it in the 3rd party in case its more tied
> into that project, and that project changes more frequent, and for
> example the Camel glue is just a thin layer. As well as the 3rd party
> team is in control of that component etc. For example we had a
> discussion with the Activiti team whether to host the Camel Activiti
> integration at them or at Apache.
> In this case the scalete component is also build using scala code, and
> scalete was being innovated rapidly. So I guess the decision back them
> was to keep the scalete-camel component at Scalete for the time being.
> I am sure we can ask the scelete team to donate it to Apache if thats
> what we want. But lets try to avoid this again. It does send a message
> to 3rd party who take time to integrate their product with Camel a
> wrong message.
> The scalete JARs is synced to central maven, so there is no problem
> with that. And AFAIR they are osgi compliant as well.
> On Wed, Jul 20, 2011 at 10:04 PM, Christian Müller
> <>  wrote:
>> Yes. I also think it was the right thing to do, but the wrong way...
>> We should act with more respect for each other - independently whether or
>> not we have different point of views.
>> ... and as Claus always says: We love contributions... ;-)
>> Best,
>> Christian
>> On Wed, Jul 20, 2011 at 5:58 PM, James Strachan<>wrote:
>>> On 20 July 2011 16:43, Daniel Kulp<>  wrote:
>>>> On Wednesday, July 20, 2011 8:47:19 AM James Strachan wrote:
>>>>> Dan could you please explain why you're deleting pages from the wiki
>>> which
>>>>> describe open source camel components without first at least having a
>>>>> discussion about it?
>>>> Because in this case, there is nothing really to discuss.   That page
>>>> be hosted here.   Period.  It's not supported by the Apache Camel
>>> project.
>>>> It's not part of Apache Camel.   Etc....   If the Scalate team would like
>>> to
>>>> create a page on their own site with information, we can create a new
>>> "3rd
>>>> party Camel Components" page or table or similar that provides a
>>> (nofollow)
>>>> link to their page, but Apache cannot provide hosting and such for
>>>> documentation of external components.  Alternatively, if they would like
>>> to
>>>> donate the Scalate component to camel, we could put it back for 2.9.   I
>>> can
>>>> help out with the software grant needed.
>>> Don't you think it'd be a little nicer to just bring this discussion
>>> up first rather than just going ahead and deleting stuff? If that page
>>> has to move somewhere so be it - but please talk to folks first.
>>> Deleting stuff without comment or discussion is pretty rude behaviour.
>>> BTW no need to SHOUT
>>> --
>>> James
>>> -------
>>> FuseSource
>>> Email:
>>> Web:
>>> Twitter: jstrachan, fusenews
>>> Blog:
>>> Open Source Integration and Messaging

Christian Schneider

Open Source Architect

View raw message