Fix prototype class names to match the naming convention that we changed to, oh, say 5 or 6 years ago. Always good to catch these things early!
setSelectedObjects did not call setSelectionIndexes
Add UUID CopyType, Fix Generics and expectations that destination objects of reference-copied relationships implement ERXCopyable - they don't need to.
Javadoc addition with additional EOGeneration template code, remove unused import.
Fix generics calls that eclipse compiles just fine, but javac won't. Good times, good times.
allow client-side caching of ERXResponse content
Fix JavaDoc - NO CODE CHANGES - Much of ERXKey's java doc was either confusing, or outright wrong. It often described operators as *prepending* the passed in key or current key when the methods actually *appended* the keys. For many operator keys it makes a big difference as to what they do.
Revert unintended change to ERXMappingObjectStream.
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