Rename ReactorRabbitMQ -> RabbitFlux ?

[smaldini]

As title says

[wxlund]

Is there any reason not to put the spring label on as well?

Spring-webflux
Spring-rabbitflux

I hope it looks side by side like we’re doing with mongo driver, web, etc.

[acogoluegnes]

@wxlund Reactor RabbitMQ is based on Reactor Core and RabbitMQ Java client, it does not depend at all on Spring.

[wxlund]

That makes sense. Probably not the right place to ask but is there a planned path from spring-amqp to spring-amqp-reactor?

…

Sent from my iPhone

On Feb 26, 2018, at 5:43 AM, Arnaud Cogoluègnes ***@***.***> wrote: @wxlund Reactor RabbitMQ is based on Reactor Core and RabbitMQ Java client, it does not depend at all on Spring. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[acogoluegnes]

@wxlund Not that I'm aware of. Right now, the closest would be to use Spring Integration 5.0 with the reactive support. /cc @garyrussell @artembilan.

[artembilan]

@wxlund,

Contribution is welcome, but I'm not sure that it is going to be a separate module. Maybe simple pair of Spring-wrappers around Sender and Receiver in the existing spring-rabbit is enough...

[artembilan]

And right: Spring Integration 5.0 can already be used with this Reactive components. I presented last SpringOne possible approach with reactor-kafka:

https://github.com/artembilan/spring-integration-s1p2017/blob/master/src/test/java/org/springoneplatform2017/integration/kafka/SpringIntegrationS1p2017KafkaTests.java#L82-L95

[acogoluegnes]

@smaldini No objections to that. Is it a common convention between Reactor-based extension?

[acogoluegnes]

Per conversation with @simonbasle, we'll stick to the current name.

[acogoluegnes]

As per discussion with @simonbasle and @smaldini, addressing this one for consistency with other static helpers in the Reactor ecosystem.