[GitHub] karaf pull request #277: Reintroduce MavenTest itest to test on Jenkins (tha...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/karaf/pull/277


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Proposal] New subproject rcomp - Reactive components framework

[Jean-Baptiste Onofré]

Hi

I will do a new review round tomorrow morning.

Thanks
Regards
JB

On Aug 8, 2017, 13:04, at 13:04, Christian Schneider  
wrote:
>I now adapted the package names as well as the maven coordinates. All
>files should now also have the apache headers.
>I also made sure the build now works without any running mqtt or kafka
>server.
>
>I would be happy about a quick review of the current status. If there
>are no objections then I will go ahead and ask for a git repository.
>
>Christian
>
>On 03.08.2017 08:02, Jean-Baptiste Onofré wrote:
>> Hi Christian,
>>
>> the proposal is interesting, and I see a first potential use in
>> Decanter for sure.
>>
>> The comment about Camel is fair as it looks very similar at first
>glance.
>>
>> However, the scope is slightly different IMHO.
>>
>> I checked about the legal. The code should be cleanup for donation
>> (ASF headers, package names, ...). About the dependency license, for
>> the reactive-streams, it' OK as it uses Creative Commons Zero into
>the
>> Public Domain. And Reactor is already under Apache license.
>>
>> The DSL is a hot topic. I understand that leveraging Akka or Reactor
>> is easier, but I'm a bit concern that we could be too much "coupled".
>> Maybe our own simple DSL could help. Thoughts ?
>>
>> Thanks anyway !
>> Regards
>> JB
>>
>> On 07/19/2017 01:02 PM, Christian Schneider wrote:
>>>
>>>   Scope
>>>
>>> I recently experimented with reactive streams and built a small
>>> component framework on top of this spec.
>>> See https://github.com/cschneider/reactive-components
>>>
>>> The goal is to have a small API that can encapsulate a protocol and
>>> transport. The code using such a reactive component should not
>>> directly depend on the specifics of the transport or protocol.
>>> Another goal is to have reactive features like back pressure.
>>> Ultimately I am searching for something like Apache Camel Components
>
>>> but with a lot less coupling. In camel the big problem is that
>>> components depend on camel core which unfortunately is much more
>than
>>> a component API. So any camel component is coupled quite tightly to
>>> all of camel core.
>>>
>>>
>>>   Proposal
>>>
>>> I propose to donate my code to Apache and establish this as a Apache
>
>>> Karaf sub project. Some people like Jean-Baptiste and Hadrian have
>>> already expressed that they support this and I hope for some more
>>> feedback and help.
>>>
>>> I chose the Karaf project at the moment but am also open to placing
>>> this in another Apache project. Some matching projects would be
>>> Apache Camel, Aries or Felix.
>>>
>>>
>>>   Component API
>>>
>>> I was trying to find the simplest API that would allow similar
>>> components to camel in one way mode.
>>>
>>> public interface RComponent {
>>>   Publisher from(String destination, Class type);
>>>   Subscriber to(String destination, Class type);
>>> }
>>>
>>> A component is a factory for Publishers and Subscribers. From and to
>
>>> have similar meaning as in camel. The component can be given a
>source
>>> / target type to produce / consume. So with the OSGi Converter spec
>>> this would allow to have type safe messaging without coding the
>>> conversion in every component. Each component is exposed as a
>service
>>> which encapsulates most of the configuration. All endpoint specific
>>> configuration can be done using the destination String.
>>>
>>> Publisher and Subscriber are interfaces from the reactive streams
>api
>>> (http://www.reactive-streams.org/). So they are well defined and
>have
>>> zero additional dependencies.
>>>
>>> I also considered to use OSGi push streams which is an OSGi spec and
>
>>> would also be an interesting foundation. I decided against that 
>>> though as push streams have no API that is separate from the DSL and
>
>>> will probably not be used a lot outside of OSGi.
>>>
>>> See the examples for how to use this in practice.
>>> https://github.com/cschneider/reactive-components
>>>
>>>
>>>   Possible use cases
>>>
>>> Two big use cases are reactive microservices that need messaging as
>>> well as plain camel like integrations.
>>> Another case are the Apache Karaf decanter collectors and appenders.
>
>>> Currently they use a decanter specific API but they could easily be
>>> converted into the more general rcomp api.
>>> We could also create a bridge to camel components to leverage the
>>> many existing camel components using the rcomp API as well as
>>> offering rcomp components to camel.
>>>
>>> Components alone are of course not enough. One big strength of
>Apache
>>> Camel is the DSL. In case of rcomp I propose to not create our own
>>> DSL and instead use existing DSLs that work well in OSGi. Two
>examples:
>>>
>>> Akka and reactive streams
>>>
>https://de.slideshare.net/ktoso/reactive-integrations-with-akka-streams
>>>
>>> Reactor and reactive streams
>>>

Re: [Proposal] New subproject rcomp - Reactive components framework

[Christian Schneider]

I now adapted the package names as well as the maven coordinates. All 
files should now also have the apache headers.
I also made sure the build now works without any running mqtt or kafka 
server.


I would be happy about a quick review of the current status. If there 
are no objections then I will go ahead and ask for a git repository.


Christian

On 03.08.2017 08:02, Jean-Baptiste Onofré wrote:

Hi Christian,

the proposal is interesting, and I see a first potential use in 
Decanter for sure.


The comment about Camel is fair as it looks very similar at first glance.

However, the scope is slightly different IMHO.

I checked about the legal. The code should be cleanup for donation 
(ASF headers, package names, ...). About the dependency license, for 
the reactive-streams, it' OK as it uses Creative Commons Zero into the 
Public Domain. And Reactor is already under Apache license.


The DSL is a hot topic. I understand that leveraging Akka or Reactor 
is easier, but I'm a bit concern that we could be too much "coupled".

Maybe our own simple DSL could help. Thoughts ?

Thanks anyway !
Regards
JB

On 07/19/2017 01:02 PM, Christian Schneider wrote:


  Scope

I recently experimented with reactive streams and built a small 
component framework on top of this spec.

See https://github.com/cschneider/reactive-components

The goal is to have a small API that can encapsulate a protocol and 
transport. The code using such a reactive component should not 
directly depend on the specifics of the transport or protocol. 
Another goal is to have reactive features like back pressure. 
Ultimately I am searching for something like Apache Camel Components 
but with a lot less coupling. In camel the big problem is that 
components depend on camel core which unfortunately is much more than 
a component API. So any camel component is coupled quite tightly to 
all of camel core.



  Proposal

I propose to donate my code to Apache and establish this as a Apache 
Karaf sub project. Some people like Jean-Baptiste and Hadrian have 
already expressed that they support this and I hope for some more 
feedback and help.


I chose the Karaf project at the moment but am also open to placing 
this in another Apache project. Some matching projects would be 
Apache Camel, Aries or Felix.



  Component API

I was trying to find the simplest API that would allow similar 
components to camel in one way mode.


public interface RComponent {
  Publisher from(String destination, Class type);
  Subscriber to(String destination, Class type);
}

A component is a factory for Publishers and Subscribers. From and to 
have similar meaning as in camel. The component can be given a source 
/ target type to produce / consume. So with the OSGi Converter spec 
this would allow to have type safe messaging without coding the 
conversion in every component. Each component is exposed as a service 
which encapsulates most of the configuration. All endpoint specific 
configuration can be done using the destination String.


Publisher and Subscriber are interfaces from the reactive streams api 
(http://www.reactive-streams.org/). So they are well defined and have 
zero additional dependencies.


I also considered to use OSGi push streams which is an OSGi spec and 
would also be an interesting foundation. I decided against that 
though as push streams have no API that is separate from the DSL and 
will probably not be used a lot outside of OSGi.


See the examples for how to use this in practice. 
https://github.com/cschneider/reactive-components



  Possible use cases

Two big use cases are reactive microservices that need messaging as 
well as plain camel like integrations.
Another case are the Apache Karaf decanter collectors and appenders. 
Currently they use a decanter specific API but they could easily be 
converted into the more general rcomp api.
We could also create a bridge to camel components to leverage the 
many existing camel components using the rcomp API as well as 
offering rcomp components to camel.


Components alone are of course not enough. One big strength of Apache 
Camel is the DSL. In case of rcomp I propose to not create our own 
DSL and instead use existing DSLs that work well in OSGi. Two examples:


Akka and reactive streams
https://de.slideshare.net/ktoso/reactive-integrations-with-akka-streams

Reactor and reactive streams
https://de.slideshare.net/StphaneMaldini/reactor-30-a-reactive-foundation-for-java-8-and-spring 



Another integration is with REST. It is already possible to integrate 
CXF Rest services with reactive streams using some adapters but we 
could have native integration.



  Risks and Opportunities

The main risk I see is not gathering a critical mass of components to 
draw more people.
Another risk is that the RComponent API or the reactor streams have 
some unexpected limitations.
The big opportunity I see is that the rcomp API is very simple so the 
barrier of entry is low.
I 

[ANN] Apache Karaf 4.1.2 has been released!

[Jean-Baptiste Onofré]

The Apache Karaf team is pleased to announce the release of Karaf (Container) 
4.1.2.

Apache Karaf 4.1.2 is a maintenance release on the 4.1.x series, bringing bug 
fixes and updates.


Please, take a look on the release notes for details:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12340261

You can download the release from here:

http://karaf.apache.org/download.html#container-412

or directly from Maven Central with the following coordinates:

  
  org.apache.karaf
  apache-karaf
  4.1.2
  

Enjoy !