[toKrause]

Link to jira.

Pull Request Checklist (Author)

Please go through the following checklist before assigning the PR for review:

Ticket & Documentation

• The issue in the ticket is clearly described and the solution is documented.
• Design decisions (if any) are explained.
• The ticket references the correct source and target branches.
• The fixed-version is correctly set in the ticket and matches the PR's target branch (main).

Feature & Improvement Specific Checks

• Instructions on how to test or use the feature are included or linked (e.g. to documentation).
• For UI changes: before & after screenshots are attached.
• New features or migrations are documented.
• Does this change affect existing applications, data, or configurations?
  • Yes: Is a migration required? If yes, describe it.
  • Breaking change is marked in the commit message.

Testing

• I have tested the changes locally.
• The feature behaves as described in the ticket.
• Were existing tests modified?
  • Yes: explain the changes for reviewers.

MCR Conventions & Metadata

• MCR naming conventions are followed
• If the public API has changed:
  • Old API is deprecated or a migration is documented.
  • If not, no action needed.
• Java license headers are added where necessary.
• Javadoc is written for non-self-explanatory classes/methods (Clean Code).
• All configuration options are documented in Javadoc and mycore.properties.
• No default properties are hardcoded — all set via mycore.properties.

Multi-Repo Considerations

• Is an equivalent PR in MIR required?
  • If yes, is it already created?

[sebhofmann]

Reviewed the branch locally. All 1274 tests in mycore-base pass and Checkstyle is clean.

One finding blocks: the short form insertion point in MCRValueListSourceBase can throw IndexOutOfBoundsException. See the inline comment for the reproduction.

One point has no line to attach to. MCRInstanceConfiguration.nested(Class, String), both nestedMap(...) overloads, MCRSourceContext.incompatibilityException and MCRSourceContext.orderedKeys(Map) are public API shipped in v2026.06.0 and are removed here, while neither commit message marks a breaking change. Nothing outside mycore-base uses them in my workspace, so this is about the marker, not about the removal itself. Along with them MCRInstanceConfigurationTest (352 lines) is dropped, which leaves the nestedMap edge cases (empty prefix, mixed nesting depth) uncovered.

The remaining inline comments are nits.

[sebhofmann]

This turns intermediate segments of deeper keys into list and map keys. For lists that reaches orderedIntegerKeys, so

Foo.Values.1        = A
Foo.Values.Oops.Sub = X

now throws has element with non-integer key Oops, while on main the indexOf('.', keyPrefixLength) == -1 filter dropped such keys silently. For instance lists the stricter behaviour looks right, for @MCRPropertyList it is a behaviour change that can surface on update in an application with a grown property file. If it is intended, it seems worth naming in the ticket and the documentation.

[toKrause]

I've added this as an example benefit of the harmonization in the ticket description.

[sebhofmann]

This is line for line identical to the private MCRInstanceConfiguration.reduceProperties (line 194 there). One of the two should call the other.

[toKrause]

Both occurrences are going to be removed in MCR-3703. I've added a copy temporarily, so I do not have make one method public and remove a public method in the next PR.

[sebhofmann]

The name is recovered from the property string here, while the previous code built it structurally via name.nested(prefix). MCRInstanceName.of strips a trailing .Class, so an instance map entry keyed Class ends up with a name short by one segment in messages and in the [IMPLICIT] log. Pathological, but avoidable.

[toKrause]

What?