camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Babak Vahdat <babak.vah...@swissonline.ch>
Subject Re: camel-splunk contribution - Thoughts from the Camel PMC?
Date Sat, 31 Aug 2013 11:50:14 GMT


Am 31.08.13 13:38 schrieb "Claus Ibsen" unter <claus.ibsen@gmail.com>:

>On Sat, Aug 31, 2013 at 1:15 PM, Babak Vahdat
><babak.vahdat@swissonline.ch> wrote:
>>
>>
>> Am 31.08.13 12:51 schrieb "Claus Ibsen" unter <claus.ibsen@gmail.com>:
>>
>>>Hi
>>>
>>>We have a contribution in ticket
>>>https://issues.apache.org/jira/browse/CAMEL-6584
>>>
>>>I am sending this mail to the PMC to have some thoughts about this
>>>contribution.
>>>
>>>1)
>>>If you see from the ticket, then splunk JARs is NOT in maven central.
>>>And that would require our build of Apache Camel to depend on a 3rd
>>>party maven repo. Which IMHO isn't desireable.
>>>
>>>Though as splunk JARs is not OSGi compliant, we could possible create
>>>a OSGi wrapper bundle, and release it as part of ServiceMix bundle
>>>releases, the SMX team do, which are in Maven central:
>>>http://repo2.maven.org/maven2/org/apache/servicemix/bundles/
>>>
>>>So if we do an OSGi bundle and release at SMX then we could rely on
>>>maven central. Preben, the author of camel-splunk, has AFAIK been in
>>>touch with Splunk about OSGify their JARs, but they seems not
>>>interested doing this. Basically you can use their API JARs and
>>>download them from their Maven repo - thats it.
>>>
>>>So still we can get the SMX team to do OSGi bundles of these API JARs
>>>and release as part of their bundle releases and we can use them from
>>>Maven central.
>>
>> Hi
>>
>> I don't see any problem with this approach, that's providing an SMX OSGi
>> wrapper on central for this artifact. We already do this as well for a
>> bunch of other 3rd-party libs like QuickFix/J. And if in the future they
>> would "osgi-fy" their artifact but don't want to come over to the Apache
>> central-repo, then we could still grab their bundle from their own repo
>>as
>> we do this already today for example for camel-restlet.
>>
>>>
>>>So IMHO we have a solution to this issue.
>>>
>>>
>>>2)
>>>Splunk server is not open source. Though you can download a free
>>>version which has limited indexing capabilities. But the source code
>>>is not open source etc.
>>>
>>>Though all the other Camel components are integrating with 100% free
>>>open source libraries.
>>
>> Is this really the case? As an example is MongoDb or Salesforce already
>> 100% open source?
>>
>
>Good point about salesforce and the sap-netweaver actually. As they
>are closed source.
>
>mongodb on the other hand is 100% open source
>
>From their website:
>http://www.mongodb.org/
>
>MongoDB (from "humongous") is an open-source document database, and
>the leading NoSQL database. Written in C++, MongoDB features:
>
>And there is a link to where the source code is and how to build it etc
>http://www.mongodb.org/about/source-code/
>
>
>Though we got salesforce and sap already as closed-source, so I guess
>we can go down the road with splunk also.
>
>
>
>>>
>>>Any thoughts on going down this road? Having out of the box Camel
>>>components that integrate with closed source software?
>>>
>>
>> +1 to go down this road.
>>
>> Babak
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>--
>>>Claus Ibsen
>>>-----------------
>>>Red Hat, Inc.
>>>Email: cibsen@redhat.com
>>>Twitter: davsclaus
>>>Blog: http://davsclaus.com
>>>Author of Camel in Action: http://www.manning.com/ibsen
>>
>>
>
>
>
>-- 
>Claus Ibsen
>-----------------
>Red Hat, Inc.
>Email: cibsen@redhat.com
>Twitter: davsclaus
>Blog: http://davsclaus.com
>Author of Camel in Action: http://www.manning.com/ibsen



Mime
View raw message