Gavin King

> For developers, the XML descriptors were out of date. I don't see how that's relevant; `persistence.xml` is certainly _not_ obsolete, and that's what this proposal is about. > Like...

> That all said big +1 for the proposal. I'm fairly certain it was discussed at some point back then to have persistence.xml as another (even a more logical) place...

> That means we almost do not need configuration at all in development, and in production deployment stage, I mean that is simply a false statement. The only way that...

Given the positive feedback I've received on this from various quarters, I would like to put this on the agenda for JPA4. It's a well-defined, relatively straightforward change that builds...

@njr-11 > If Jakarta Persistence providers are processing `` elements in `persistence.xml`, they will need a way to interface with the Jakarta EE container to create the DataSource, which will...

@arjantijms But it makes complete sense for this to be a container responsibility because the container should be the thing that is scanning the archive for entity classes. Otherwise every...

> giving container an option to pass a listener/callback sort of thing to the persistence provider instead of requiring the server to implement/duplicate full blown parsing logic. I guess I...

> do we know XML stays? Realistically XML is going to be around for a long time, even assuming Config *is* successful. And to be able to completely replace `persistence.xml`,...

@lukasj Note also [my comment here](https://github.com/jakartaee/persistence/issues/701#issuecomment-3705700933). What I like about this proposal is precisely that it *doesn't* commit us to some stop-gap replacement for `persistence.xml` that might be obsoleted by...

Setting this to Draft mode because it's a source of conflicts with other open PRs.