setSelectedObjects did not call setSelectionIndexes
allow client-side caching of ERXResponse content
Update the version of some Maven dependencies
Format the pom.xml using spaces
[maven-release-plugin] prepare release wonder-6.1.1
[maven-release-plugin] prepare for next development iteration
Merge pull request #538 from nekesto/ERXKeyJavaDocUpdates

Fix ERXKey JavaDoc
Merge pull request #540 from amagavi/ERProperties_ClassNameUpdate

Update ERPrototype Class Names
Merge pull request #537 from sgaertner/ERXResponse_patch

allow client-side caching of ERXResponse content
Merge pull request #536 from amagavi/ERXCopyableFix

ERXCopyable Improvements and bug fixes
add missing binding
optimize localInstancesOfObjects

• check for empty array
• create new array with correct size
Refactoring of the ERS3UploadQueue and ERCloudFilesUploadQueue to share the same implementation and avoid accidental death of the queue thread

The ERS3UploadQueue and ERCloudFilesUploadQueue are clearly duplicated. This commit introduces an abstract queue that handles all the logic to upload files asynchronously to a remote server. The upload process is unchanged. The queue logic was improved to perform all the upload logic (preparation + execution) inside of a try-catch block. This small change makes the queue much more robust by avoiding accidental death of the queue thread when an exception is thrown during the preparation phase.
Improve the way attachments and editing contexts are handled by the attachment queue

Current behavior: the attachment queue shares one editing context for every attachment being uploaded. The attachment is inserted into the queue editing context before being enqueued.

Problem 1: the editing context can become dirty (has inconsistencies that cannot be saved) and no attachment can be saved anymore.

Problem 2: the attachment can become inconsistent between queueing and processing it.

Solution: create a new editing context to upload each attachment in the queue. This solution eliminates the chance of a dirty editing context because the editing context is going to be discarded at the end of each processing cycle. It also reduces considerably the chance of inconsistencies in the attachment since it has to be loaded immediately before performing the upload.
Merge pull request #535 from darkv/displaygroup_patch

display group's setSelectedObjects did not call setSelectionIndexes
use constant
use method from commons lang
better method name
deprecation
create StringBuilder of correct size