Migrate this repo into Spring Integration repo

[markusherbert]

Opinion - this repo is redundant, confusing, looks unmaintained, and encourages people to not contribute new Spring Integrations Connectors (since these connectors won't enter the Spring Integration project, and instead enter an unknown and undocumented one).

I don't see any advantage to this, and as a relatively new user, I'm just getting more and more confused by this whole thing.

[markusherbert]

Example for how unmaintained this project is, and why this is so confusing and misleading - this project references the AWS and the Kafka connector, just for a README that will tell the user that this connector isn't in this repo. This repo of course has some other connectors like Twitter, but it won't reference that in the README. @artembilan Please migrate this and improve this project for the next user.

[artembilan]

Thanks for bring this up, @ipanimnim .

We already such a discussion in other place: spring-projects/spring-integration#3720.

Feel free to continue over there.

[almogtavor]

@artembilan The discussion we had there was out of subject (the issue was about the request for more extensions in general). This issue seems to fit more. Anyway, was there any progress in this subject since the last discussion?

[artembilan]

Thanks, @almogtavor , for the pointer.
No, there is no progress for those your requests yet.
I'm not familiar with those projects to make an immediate solution.
Plus I'm only one committer for these Spring Integration projects over here.
Therefore bear with me how it is slow done.
There are also some other not-work related stuff to deal with...

As I always say, the contribution is welcome: https://github.com/spring-projects/spring-integration/blob/main/CONTRIBUTING.adoc
And having an external PR is really a good way to expedite the progress.

[almogtavor]

@artembilan would you accept PRs that will move this & other repos like spring-integration-aws to the main repo?

[artembilan]

Not yet.
We are discussing internally what would be acceptable from this repo.
For example twitter is obsolete and based on the library which already out of support. So, it cannot be moved anywhere.
Perhaps to a new repo for obsolete modules a-la spring-integration-attic.
The AWS cannot be moved because it is based on Spring Boot and we cannot have circular dependencies.
And so on, so on. Too many questions for every single repo.
For example what do you think about Spring Integration modules in Google GCP project, Microsoft Azure, Alibaba etc?.

At a glance only Cassandra, Hazelcast, Zip, SMB are good to go.

Although I may confirm fully that Goovy DSL is 100% candidate to go into spring-integration-core right now.

Thanks

[almogtavor]

Why AWS is based on spring boot? About GCP, Alibaba and so, their fine as long as being referenced from the docs. All the others that are relevant should be in the same place, which should encourage to add more connectors over time.

[artembilan]

Please, they are not called connectors. They are channel adapters. That's exactly a canonical name from EIP: https://www.enterpriseintegrationpatterns.com/patterns/messaging/ChannelAdapter.html.

The Spring Integration AWS uses Spring Cloud AWS , which is based on Spring Cloud, which, in turn, is based on Spring Boot. And the last one exactly uses Spring Integration. Therefore Spring Integration AWS has to be the last one in the release train.
If we can come up with the solution on a plain AWS SDK (v2?), then it indeed can go to Spring Integration.
Some other channel adapter impls may have similar concerns.
So, better to have such a discussion in a discrete manner: per module/project.

[almogtavor]

How does the AWS module different from the Mongo module? They both rely on other Spring based projects. And in general the main point is that all of the channel adapters that can sit in the main repo, should sit there. Otherwise, at least to be documented on the main docs/ referenced from the main docs.

[artembilan]

There is a difference to be dependent on a plain Spring module and the one based on Spring Boot. The auto-configuration from Spring Boot and Spring Cloud rely changes a play over here.
If Spring Cloud AWS is divided to separate projects: plain components and auto-configuration, then it could make difference for Spring Integration AWS. But not at the moment when
Therefore Spring Integration are not those channel adapters that can sit in the main repo.
Yes, we discussed with you in other places that we are going to mention this and other vendor-specific channel adapters in the doc.

[markusherbert]

I think the AWS channel adapters should stay at their own repo (as long as being referenced from the official SI docs - which they currently do not). When it comes to channel adapters for Twitter, Cassandra, and more, I think they have to be in the SI official repo, and as fast as possible, since people don't know of them and think that they just don't exist (which happened to me). @artembilan would you accept a copy-paste PR that moves the following folders:

• spring-integration-cassandra
• spring-integration-etcd
• spring-integration-groovy-dsl
• spring-integration-hazelcast
• spring-integration-cassandra
• spring-integration-smb
• spring-integration-smpp
• spring-integration-print
• spring-integration-social-twitter
• spring-integration-xquery
• spring-integration-xmpp

I think this is also a good chance to merge back:

• spring-integration-splunk

spring-integration-ip-extensions, spring-integration-jgroups, spring-integration-jt400, spring-integration-voldemort seems pretty abandoned but if you want this can be added.

I think this move is no less than a must. These extensions don't even appear in the table, their docs don't appear in the main docs, and nobody actually has an opportunity to know about them.

[artembilan]

We cannot move twitter back because we really have moved it here for the reason its base library was EoL: https://spring.io/blog/2018/07/03/spring-social-end-of-life-announcement.

It can come back only if there is other library we can make channel adapters based on.

The xmpp is already in the main project: https://docs.spring.io/spring-integration/docs/current/reference/html/xmpp.html#xmpp.
And there is no such an extension over here.
You duplicated cassandra.

We cannot move xquery because seems for me it is not based on the Open Source licensed library.

I doubt in print and smpp - they really are very abandoned.

I doubt it is going to be just easy copy/paste PRs.
But we can try, of course!

As I said before: the Groovy DSL is the best candidate to go. So, let's start from it for now!

[markusherbert]

So:

• spring-integration-cassandra
• spring-integration-etcd
• spring-integration-groovy-dsl
• spring-integration-hazelcast
• spring-integration-smb

Seems good?

[artembilan]

I think so. Let’s see how it goes!