> "The Persistence spec team does not want the integration to be present in that repo as it does not want to declare the dependency on CDI because Spring or others will use it potentially."
In that case we should discuss with the Persistence spec team more to see if there's a solution. I don't see a problem why Persistence spec couldn't define additional behavior in case CDI container is present. If used without CDI, that functionality would not simply be available and that's OK.
If the Persistence team would be adamant in refusing any type of (optional) dependency on CDI, then I suggested resorting to adding Persistence x CDI integration into the Platform/profile spec. But, if there are no good arguments from the Peristence spec team, then I would sincerely question whether the Persistence team wants Jakarta EE to be successful or they care only about Spring and other non-Jakarta EE usages of Persistence.
All the Jakarta EE specs should work well together, not only work standalone. The purpose of Jakarta EE is to create a coherent set of standard APIs, not individual APIs. If they work well as standalone, that's a good bonus. But the other way doesn't work well for the Jakarta EE community.
Ondro