Mark Paluch

TL;DR: Supporting JSR-305 annotations (`avax.annotation.Nullable`) instead of the Jakarta packages is a consequence of Spring Framework's support for these annotations. It is not only the meta-annotation `org.springframework.lang.Nullable` but also runtime...

Yeah, that is fair to say. Going forward, did you file a ticket against Spring Framework to support Jakarta nullability annotations?

We discussed nullability annotation coverage in the team. `jakarta.annotation-api` introduced with version 2.1 a slim variant of nullability annotations that are a shallow copy of JSR305 (without `when` or `@TypeQualifierDefault`)...

For now, we're using a combination of utilities to detect JSpecify annotations through Spring's `Nullness` utility. The remaining annotations (`@NonNullApi`, and `@Nullable`, Spring and JSR-305 variants) are introspected by our...

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...

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...

> 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...

How do you mean? Something like `findByFooIsNull(true)`/`findByFooIsNull(false)`?

Related: * #4318 * #4667

Thanks for exploring that path. We generally advocate for our Aggregation Framework API to rather use programmatic guidance as aggregations can become pretty complex with their variety of options. String-based...