It turns out that relative path in the property
`<property name="file" value="src/checkstyle/checkstyle-suppressions.xml"/>`
in some cases is resolved against a Gradle deamon dir as a root for configs
* Fix Checkstyle plugin config to use an absolute path in the project for
the `configDirectory`.
* Since `configDirectory` is exposed as a Checkstyle config variable,
we can use its `${config_loc}` placeholder to rely on the absolute path
in the project
Upgrade to latest version of Asciidoctor because we were several
versions behind and were steadily incurring more technical debt.
* Replace project-version attribute in Asciidoctor
I had removed the project-version attribute, but the docs use it all
over, so I put it back.
* Removed unneeded repositories
It turns out that those repositories are not needed.
A cross-reference was incorrectly formatted (missing the # character).
* Remove `CODE_OF_CONDUCT.adoc` if favor of the same for a GitHub org
* Move `LICENSE.txt` to the root project dir
* Fix `build.gradle` to copy a `LICENSE.txt` from the actual location
* Fix `README.md` and `CONTRIBUTING.adoc` to point into the actual `CODE_OF_CONDUCT`
& Security policy
* Add `ISSUE_TEMPLATE` directory with files similar to ones in `spring-session`
* Fix wrong section `id` in the `whats-new.adoc`
* Improve `build.gradle`:
- Upgrade some plugins
- Remove unused (or mistaken) dependencies
- Add transitive `exclude` into Spring Data dependencies
- Add `inputs.dir(sourceDir)` for docs tasks in attempt to avoid their build because of `up-to-date`
Fixes https://github.com/spring-projects/spring-integration/issues/3213
* Expose a `LeaderInitiatorFactoryBean.setCandidate()` for better control over candidate options
* Expose a `candidate` attribute for the `<int-zk:leader-listener>` tag
* Fix `dokka` task to obtain `package-list` URL from the local dir
* Migrate ZK tests to JUnit 5
- fix mock tests for internal client changes
- reduce stop wait for completion time
**cherry-pick to 5.2.x**
* Remove stack trace from test and convert to assertJ
Resolves https://github.com/spring-projects/spring-integration/issues/3172
When the listener container supports creating batches of consumed
messages, present the batch as the message payload - either a
`List<Message<?>>` or `List<SomePayload>`.
* Add 'since' to new method.
* Gradle 6.1.1
* MongoDb 4.0
* Other Spring dependencies to `BUILD-SNAPSHOT`
* Fix MongoDb tests according latest Spring Data
* State in the docs that both MongoDb driver are `optional` now in the dependencies
* Add `org.gradle.caching=true` and `org.gradle.parallel=true` into a `gradle.properties`
* Fix `Matcher` tests in the `spring-integration-test-support` for the latest JUnit 4
* Infrastructure for ReactiveMessageHandler
We have now a `ReactiveMongoDbStoringMessageHandler` which implements
a `ReactiveMessageHandler`, but not a `MessageHandler` for possible
deferred subscriptions to the returned Reactor type
We don't have a proper application context processing for this
new type of message handlers
* Change a `ConsumerEndpointFactoryBean` to apply an `MH` and `RMH`
as possible types for handler
* Introduce a `ReactiveMessageHandlerAdapter` to wrap an `RMH`
into a `MH` for synchronous calls in the regular consumer endpoints
* Wrap an `RMH` into a `ReactiveMessageHandlerAdapter` for regular
endpoints and unwrap for `ReactiveStreamsConsumer`
* Add `RMH`-based ctor into `ReactiveStreamsConsumer` for target
reactive streams composition (`flatMap()` on the `RMH`)
* Remove a `DelegatingSubscriber` from the `ReactiveStreamsConsumer`
in favor of direct calls from the `doOnSubscribe()`, `doOnComplete()`
& `doOnNext()`
* Add an `onErrorContinue()` to handle per-message errors, but don't
cancel the whole source `Publisher`
* Use `Disposable` from the `subscribe()` to cancel in the `stop()`
- recommended way in Reactor
* Use `onErrorContinue()` in the `FluxMessageChannel` instead of
`try..catch` in the `doOnNext()` - for possible `onErrorStop()`
in the provided upstream `Publisher`
* Handle `RMH` in the `ServiceActivatorFactoryBean` as a direct handler
as well with wrapping into `ReactiveMessageHandlerAdapter` for return.
The `ConsumerEndpointFactoryBean` extracts an `RMH` from the adapter
for the `ReactiveStreamsConsumer` anyway
* Add XML parsing test for `ReactiveMongoDbStoringMessageHandler`
* Add `log4j-slf4j-impl` for all the test runtime since `slf4j-api`
comes as a transitive dependency from many places
* * Fix conflicts after rebasing to master
* * Fix typo in warn message
* Change `Assert.state()` to `Assert.isTrue()`
for `ConsumerEndpointFactoryBean.setHandler()`
* * Fix `ConsumerEndpointFactoryBean` when reactive and no advice-chain
* Fix race condition in the
`ReactiveMongoDbStoringMessageHandlerTests.testReactiveMongoMessageHandlerFromApplicationContext()`
* * Handle `ReactiveMessageHandler` in Java DSL.
Essentially request a wrapping into `ReactiveMessageHandlerAdapter`.
Describe such a requirements in the `ReactiveMessageHandlerAdapter` JavaDocs
* Some Java DSL test polishing
* Add Java DSL for `ReactiveMongoDbStoringMessageHandler`
* Propagate missed `ApplicationContext` population into an internally
created `ReactiveMongoTemplate` in the `ReactiveMongoDbStoringMessageHandler`
* Remove Boon dependency and its usage
* Remove overloaded methods from the `IntegrationFlowDefinition`
- we can simply rely now on the super class
* Remove (or rework) deprecated entities in the docs
* Fix tests for removed deprecated APIs
* Rework affected tests to JUnit 5
* Bring Spring Data MongoDb back to `2.3`;
essentially rely on Spring Data BOM for dependencies
* Change `mongodb-driver-reactivestreams` driver version back to `1.12.0`
* Upgrade to Spring Security 5.3 M1
* Fix MongoDb module to use `MongoDbFactory` class instead of new (not committed yet)
`MongoDatabaseFactory`
* Remove `uuidRepresentation()` configuration from the `MongoClients` factory usage -
that is going to be MongoDb driver 4 feature
* Use Gradle variants for publishing `optional` and `provided`
* Use some transitive dependencies explicitly from other modules
since all the optional dependencies are not pulled by Gradle any more
* Alongside with existing `springAmqpVersion` & `springVersion`
also expose `springDataVersion` & `springSecurityVersion`
project properties.
These can be used in external CI plans for compatibility builds
* Fix `IntegrationGraphServerTests` for the current state of graph -
The node name is now based on the endpoint id, not a `MH` bean name
* Fix MongoDB tests for compatibility with the latest driver
JIRA: https://jira.spring.io/browse/INT-4568
* Refactor `AbstractMessageHandler` and implement `MongodbReactiveMessageHandler`
* Rename `AbstractBaseMessageHandler` to `MessageHandlerSupport`
* Clean up code style and resolve possible Sonar smells
* Move `What's New` into `changes-5.1-5.2.adoc`
* Remove version from the `XSD` files:
1. Align with SF
2. The version for XSD doesn't matter for the current jar version,
since only the version is available in classpath is from the current
jar version
3. Modify `spring.schemas` to map all the possible versions for XSD
into the current one in a jar.
This way target applications can upgrade without changing the version
for XSD location and we don't need to require `versionless` variant
any more
4. The jar in classpath can handle only its own XSD, so independently
of version or no-version variants we still may fail because the current
jar may not support end-user code any more - need some fix over there
anyway.
* Remove `checkTestConfigs` Gradle task since we don't worry about XSD
version any more
* Modify `schemaZip` Gradle task to populate XSDs into a distribution
still with a version to avoid overriding on-line XSDs for version `1.0.x`.
We may consider not do that since SF doesn't and just bite a bullet
for always overriding those on-line XSDs to the actual one from the latest
release.
Related to https://github.com/checkstyle/checkstyle/issues/7322
To be able to build the project against `mavenLocal()`, add a
`mavenLocal` project property which can be specified as command line arg
`-PmavenLocal`, so a `mavenLocal()` is added into `repositories`
conditionally
It turns out that these properties have some reasonable defaults, but
Sonar plugin on Bamboo can't read them anyway.
So, we have to modify CI plan for respective values for the project
Remove `sonar.projectKey` & `sonar.projectName` properties from the
`sonarqube` task since they have a reasonable defaults according
plugin docs: https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-gradle/
It looks like the feature to override these properties in the Bamboo
plugin doesn't work properly
Related to https://github.com/checkstyle/checkstyle/issues/7306
According to discussion with Checkstyle team, we agreed to give us
project for testing their latest changes for regressions to avoid
situation like in the mentioned issue with `RequireThis`
* We expose a `checkstyleVersion` for Gradle command line to let to
provide a Checkstyle version externally.
This feature is going to be used on Checkstyle CI to run check in our
project against their SNAPSHOT
The command to run checks against external version is like this:
`./gradlew clean check --parallel -x test -PcheckstyleVersion=[CHECKSTYLE_VERSION]`
Where `[CHECKSTYLE_VERSION]` is a placeholder which should be replaced
with environment-specific variable or an explicit version.
