Extract BaseIntegrationFlowDefinition

[artembilan]

Kotlin inline reified functions cannot override as syntax sugar generic
Java methods.

• Extract a BaseIntegrationFlowDefinition with strong typed methods,
  plus those which doesn't have a syntax sugar variants
• Leave in the IntegrationFlowDefinition only those generic methods
  which are just a syntax sugar without any types requirements

This way we can write Kotlin inline reified functions as an extension
with the same names to make a Kotlin DSL much cleaner

[garyrussell]

I am ok with this generally, but I think it means new builds of all downstream (extension) projects will be needed to work with this version.

[artembilan]

I would take such a risk since the simple workaround is just to compile the project against this version.
More over it only affect those projects which use Java DSL.
And I guess you talk here only about SI-Kafka.
It's so easy to build that project and release a new version for it.
We have already Spring Kafka patch release, so that feels natural to build a new version for SIK based on this patch release for SI, too.

Otherwise we would have to deffer Kotlin DSL feature until the next year...

[garyrussell]

Actually, it's a lot worse than that; any user app that uses the methods in IFD has to be recompiled...

***************************
APPLICATION FAILED TO START
***************************

Description:

An attempt was made to call a method that does not exist. The attempt was made from the following location:

    com.example.demo.Ktest23Application.lambda$2(Ktest23Application.java:69)

The following method did not exist:

    org.springframework.integration.dsl.IntegrationFlowDefinition.handle(Lorg/springframework/integration/dsl/MessageHandlerSpec;)Lorg/springframework/integration/dsl/IntegrationFlowDefinition;

The method's class, org.springframework.integration.dsl.IntegrationFlowDefinition, is available from the following locations:

    jar:file:/Users/grussell/.m2/repository/org/springframework/integration/spring-integration-core/5.2.1.BUILD-SNAPSHOT/spring-integration-core-5.2.1.BUILD-SNAPSHOT.jar!/org/springframework/integration/dsl/IntegrationFlowDefinition.class

It was loaded from the following location:

    file:/Users/grussell/.m2/repository/org/springframework/integration/spring-integration-core/5.2.1.BUILD-SNAPSHOT/spring-integration-core-5.2.1.BUILD-SNAPSHOT.jar

	@Bean
	public IntegrationFlow inFlow(ConsumerFactory<String, String> consumerFactory) {

		ContainerProperties props = new ContainerProperties("ktest23");
		props.setGroupId("ktest23int");
		return IntegrationFlows.from(Kafka.messageDrivenChannelAdapter(consumerFactory, props))
				.handle(msg -> System.out.println("int:" + msg.getPayload()))
				.get();

[artembilan]

@garyrussell ,

Here is a solution we discussed with you yesterday. Unfortunately another one with a plain extension still doesn't work in Kotlin.

Do not merge yet this one, since I haven't finished Kotlin part to be sure that we are good.
Although you can share your feedback about bytecode compatibility.

Thanks

[garyrussell]

I think we will need to mark all these with NOSONAR to avoid "useless override" smells from Sonar 😦

[artembilan]

Correct, but I would like to see that message to be sure about the place for such a // NOSONAR comment

[artembilan]

OK! Missed mavenLocal() was my mistake in Kotlin DSL project, but now all is good!
Feel free to merge or let me know where to place those // NOSONAR.

Thanks

[artembilan]

And now you can see what happened to Kotlin DSL after this.

[garyrussell]

It goes on the method after the { - see ContainerProperties in kafka.

[artembilan]

Thanks. Done.
Note: I have removed protected overridden methods. I don't think they are obstacle for target projects.