Fallback to default fragment implementation if no candidates found

[quaff]

It's an enhancement that should not break existing behaviors.

The default implementation is $FragmentInterfaceName + $ImplementationPostfix, for example com.example.FragmentImpl is the default implementation of com.example.Fragment.

It's useful for sharing repository fragments as library, application doesn't have to include library package in @Enable…Repositories, and it will back off if application provides custom implementation.

See spring-projects/spring-data-jpa#3287

[mp911de]

Thanks for your suggestion. We need to discuss in the team whether we want to support external fragments and how discovery is affected with a fragment implementation inside the base package vs. a fragment implementation that resides in the package the interface is defined in.

[quaff]

Any thoughts?

[mp911de]

We've introduced #3090 to register fragments by specifying implementations in spring.factories. Falling back to a same-package default implementation deviates from what Spring's approach and seems a bit random.

Care to check out #3090? It allows you to specify an implementation for a fragment interface. Once the fragment interface is used in a repository, you will get the fragment implementation that is associated with it.

[quaff]

Falling back to a same-package default implementation deviates from what Spring's approach and seems a bit random.

Same-package default implementation is unique, could you explain why it's random?
Specifying it in spring.factories deviates from "Convention over Configuration" principle.

---

org.springframework.data.repository.config.spifragment.SpiFragment=org.springframework.data.repository.config.spifragment.SpiFragmentImpl

in spring.factories could be omitted after this commit is merged.

[mp911de]

Specifying it in spring.factories deviates from "Convention over Configuration" principle.

The opposite is true. We're adding means of configuration for arrangements that require a more explicit configuration.

Scanning outside the base package would strongly deviate from our conventions. By broadening scanning locations to interfaces imported into a repository declaration we would ignore configuration.

That being said, we're closing this PR in favor of #3090.