Turns out Sonatype requires a `javadoc.jar` artifact to be present
in the distribution for proper publishing
* Create a `javadoc.jar` based on the `groovydoc` task
* Include `groovydoc.jar` into a publication and distribution
Fixes https://github.com/spring-projects/spring-integration-extensions/issues/248
The `HazelcastMessageStore.doListKeys()` uses `this.map.values()`
by mistake.
* Fix `HazelcastMessageStore.doListKeys()` to use a `keySet()` for a proper filtering
and result inferring
* Add unit test to cover an iteration functionality for message groups in the store
Fixes https://github.com/spring-projects/spring-integration-extensions/issues/242
The `UnZipTransformer` removes a source zip file unconditionally
* Fix `UnZipTransformer` to remove a source zip file only
if unzipping was successful
* More checks for traversal file names
* Upgrade dependencies including Gradle
* Move Maven publishing functionality to `maven-publish` plugin
* Upgrade to the latest dependencies
* Migrate assertions in tests to AssertJ
* Optimize tests to use unsafe mode for CP-subsystem
for better test execution performance
Fixes https://github.com/spring-projects/spring-integration-extensions/issues/235
According to the hazelcast team:
"The logic assumes that locks are generally acquired
& released in a fairly short time or hold a very long time without unlocking.
But in this case, is a bit different, it holds the lock for a long time,
but also does lock/unlock very frequently".
The previous implementation used the described logic,
first acquiring a lock and then doing frequent `tryLock/unlock`.
Doing this leads to
`com.hazelcast.cp.internal.datastructures.lockLock#ownerInvocationRefUids`
to grow without ever being cleaned thus leading to an `OutOfMemoryError` eventually.
* Rely on the `FencedLock.isLocked()` instead of frequent `tryLock/unlock`
* Fix `LeaderInitiatorTests` not to spawn 3 CP members since an unsafe mode is
enough to test the feature
* Move classes in this project to their own `kotlin` package
to avoid conflict with other Spring Integration artifacts
* Add lambda-based `handle()` instead of `GenericHandler` one
* Swap arguments in some EIP-method for better code flow
when build with Kotlin DSL
* Add a `scatterGatherFlow` configuration into a test suite
to demonstrate a complex configuration with Java API interoperability.
The Java sample is present in the comment for this flow definition
