To improve maintenance, simplify adding new features, and reusability of Repository parts, it should be somewhat refactored.

See earlier attempt at Repository refactoring: https://github.com/ezsystems/ezpublish-kernel/compare/master...repo_structure
However approach below tries to keep changes to a minimum to not break existing type hints on public services

Proposed Repository restructuring of structure, less can be done if considered to invasive:

• Core/Repository/Helper/*Mapper to Core/Repository/Mapper/*Mapper
• Core/Repository/Helper/*Registry to Core/Repository/Registry/*Registry // done
• Core/Repository/Helper/*Processor to Core/Repository/Processor/*Processor
• Core/Repository/Helper/LimitationService to Core/Repository/Registry/LimitationRegistry // note: we've found AdminUI use cases which legitimize making it an API service, hence rather keeping "Service" suffix
• Core/Repository/Helper/NameSchemaService to Core/Repository/Processor/NameSchemaProcessor
• Core/SignalSlot to Core/Repository/SignalSlot // obsolete, Signal Slot layer has been dropped in favor of Events

For all above classes that are exposed as public services we'll have to leave bc classes behind (aka new class extends old class so type hints works, TODO: investigate how old one can be marked as deprecated while new one will not be seen as deprecated, alternative is old deprecate class extend new, and internals / services definition continue to return old classes until they are removed)

Proposed decoupling

1. All classes should be made into symfony services and injected instead of being created inside Repository
2. Get rid of injecting whole Repository and persistence handler inside all services so they don't continue to have circular referances
3. Refactor Repository factories (buildRepository, get*Service) to use Dependency Injection rather that manual instantiation.

Other moving parts

The repo_structure branch linked to in the beginning has a few other things in it:

• Permission extraction: Still valid, however should for the sake of sanity be handled by separate story. This is only relevant if we are to add API layer cache (however not possible before API objects are serializable)
• Lazy Loaded User object: Obsolete, fixed by introduction of UserRef, which should be used in more parts for instance in Session handling (done as of 1.10)