According to this: https://stackoverflow.com/a/56154292/3715185, adding an id to the execution configuration can help to keep Maven from generating erroneous tags in the effective pom, such as adding a `<resource>` tag to the `ManifestResourceTransformer`.
This moves the Maven documentation from the 'configuration' section to the
'deploy' section, and adds documentation for Gradle.
A further improvement would be to split up the current 'deploy' docs and
separate 'bundling' from 'deploying', but that is for a future PR.
* move AccountExample to Sharding, to be able to test with EntityRef etc
* add tests for AccountExample
* for javadsl there is a problem
* explicity replyTo type solves javadsl issue
* use EventSourcedEntity.withEnforcedReplies
* try replyTo with super type AccountCommandReply
* Reply <: AccountCommandReply
* replace lambda with method (constructor) reference
* No clear advantage over CBOR
* One less choice for users
* CBOR seems to have a stronger specification and therefore potential
for wider adoption
* Performance of CBOR is equals to Smile
* Smile can be slightly more compact
(I think it does more to reduce repeated field names),
but that might be better to solve with good compression
* Remove ActorContext parameter from javadsl.ReceiveBuilder, #27120
* functional style in javadsl
* in Java it's more practical to have an enclosing class to hold
initialization parameters and ActorContext
* writing behaviors as pure static methods will be unlikely be used in Java
* it's still possible to write behaviors as static methods by passing
the context around, in same way as all other things
* better to embrace the enclosing class pattern and therefore remove
the context parameter from the message handlers
* style cleanup of ChatRoom sample
* migration guide
* Removed `Behavior.same`, `Behavior.unhandled`, `Behavior.stopped`, `Behavior.empty`, and `Behavior.ignore` since
they were redundant with corresponding in Behaviors
* Also moved several of the internal things from Behavior to BehaviorImpl
* Needed in Lagom to be able to have separate object mappers with different
config for exernal and internal usage.
* Can also be good to be able to have different config for json and cbor
serializers, or different for remote messages and persisted events.
* Pass in binding name when creating the serializer if it has a matching
constructor
* Serialization identifiers loaded from config via the binding name instead
of class name, for JacksonSerializer.
* Decrease waiting-for-state-timeout to 2s
The timeout can be likely to happen for small clusters when the read
majority needs to go to every node
Refs #26710
* Restructure migration guide for 2.6
Separate out changes that require no user action unless the old
behavior is preferred
* Update akka-docs/src/main/paradox/project/migration-guide-2.5.x-2.6.x.md
Co-Authored-By: Arnout Engelen <github@bzzt.net>
* previous `schedule` method is trying to maintain a fixed average frequency
over time, but that can result in undesired bursts of scheduled tasks after a long
GC or if the JVM process has been suspended, same with all other periodic
scheduled message sending via various Timer APIs
* most of the time "fixed delay" is more desirable
* we can't just change because it's too big behavioral change and some might
depend on previous behavior
* deprecate the old `schedule` and introduce new `scheduleWithFixedDelay`
and `scheduleAtFixedRate`, when fixing the deprecation warning users should
make a concious decision of which behavior to use (scheduleWithFixedDelay in
most cases)
* Streams
* SchedulerSpec
* test both fixed delay and fixed rate
* TimerSpec
* FSM and PersistentFSM
* mima
* runnable as second parameter list, also in typed.Scheduler
* IllegalStateException vs SchedulerException
* deprecated annotations
* api and reference docs, all places
* migration guide
