In attempt to fix a race condition in the tests
* Remove `log4j` deps as redundant: Spring Boot brings them anyway for logback compatibility
* Add `logback-test.xml` to the `spring-websocket-consumer.test` for test race condition failures
Move `apply plugin: 'com.gradle.develocity'` after we have modified `startParameter.noBuildScan`.
Otherwise, the Develocity is configured for its default server instead of Spring's one
* Remove `MessageChannel` beans whenever their really don't need to be exposed into the target application context.
Use local property definition instead in the configuration class
* Make Twitter `Consumer` configurations conditional on their required properties
to avoid auto-configuration for those bean which are not going to be used in the target application
The `@MessagingGateway` requires a classpath scanning which is not possible
when we use these function artifacts as dependencies, where packages are fully
different from what target project is built with
* Remove `ownConnection` feature from RabbitMQ modules.
It does not bring too much value over Spring Boot config.
Plus no one else modules tries to mimic such a behavior.
So, fully rely on Spring Boot auto-configuration for RabbitMQ as well.
Fixes: #2
* To avoid `@Lazy` and other possible injection problems
when an `IntegrationFlow` is not ready yet, provide a `@MessagingGateway(name = "sftpConsumer")`
explicitly for the `MessageConsumer` in the `SftpConsumerConfiguration`
* Make SFTP modules as auto-configuration
* Fix Checkstyle violations in those modules
* Fix all the Checkstyle violations for those modules
* Introduce a `MosquittoContainerTest` contract into the `spring-function-test-support`
and use it in the MQTT modules
* Fix READMEs for previously migrated modules to auto-configuration
* Fix all the Checkstyle violation in the effected modules
* Fix Twitter modules READMEs to reflect a nature of the auto-configuration
* Add (and mention in README) new `enabled` properties for various Twitter supplier configurations:
by default all of them would be started just by the presence in classpath
* Add `spring-` prefix to function names
Fixes: #9
This commit renames each sub-module in the common, consumer, function
and supplier groups with a prefix of `spring-`.
* Update README.adoc links to new prefixed names
* Add `com.github.spotbugs` plugin to avoid warnings about missed nullability annotations
* Make `TimeSupplierConfiguration` as an auto-configuration
* Add `io.debezium:debezium-bom` as the first one to let others override its deps versions
* Move `org.springframework.boot:spring-boot-dependencies` after `io.awspring.cloud:spring-cloud-aws-dependencies`
to override its deps versions (e.g. `jakarta.mail` `1.0.0` > `2.0.2`)
It is not recommended to use `IntegrationComponentSpec.getObject()` manually.
* Change `KafkaPublisherConfiguration` to use `KafkaProducerMessageHandlerSpec` for bean definition
* Fix `KafkaPublisherConfigurationTests` to add an `IntegrationAutoConfiguration` into the picture as well
* Upgrade to Spring Integration AWS `3.0.1`
* Upgrade to Spring Cloud AWS `3.0.1`
* Use `spring-cloud-aws-dependencies` BOM to manage Spring Cloud AWS deps, as well as AWS SDK
* Remove `AmazonS3Properties` in favor of similar properties in the Spring Cloud AWS auto-configuration
* Remove `CompatibleStorageAmazonS3Configuration` in favor of its code migration to the single `AmazonS3Configuration`
* Fix `supplier`, `consumer`, `source` and `sink` for S3 to use API and programing model from the mentioned upgrades
* Add extra `dataflow-configuration-metadata` entries for the mentioned properties from the Spring Cloud AWS auto-configuration
* Regenerate README for `s3-source` and `s3-sink`
* Fix `metadata-store-common` to use the latest Spring Integration AWS for DynamoDB store impl
* * Fix `AmazonS3ConfigurationTests` for missed `AwsAutoConfiguration`
in an `ApplicationContextRunner` setup
* * Remove unused import in the `MetadataStoreAutoConfigurationTests`
* * Remove unused import in the `AbstractAwsS3ConsumerMockTests`
