Fixes https://github.com/spring-projects/spring-integration-extensions/issues/246
The `replaceFile` & `useTempFile` options are not `SmbSession` responsibility.
The `FileTransferringMessageHandler` covers a functionality of `replace` and `tmFile`.
* Implement an `SmbMessageHandler` to hide a `replaceFile` setting on the `SmbSessionFactory`
to retain backward compatibility
* Mention an `SmbMessageHandler` in the README
Updates after further unit testing
Updated for initial PR review requested changes
removed comment to satisfy PR review
Updated to satisfy PR review requests for changes
More updates after further PR review
Updated again based on PR review comments
* Suppress deprecations in the tests for these deprecated options
* Add `package-info.java` to `outbound`
* Delegate from one ctor to another in the `SmbMessageHandler`
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
