There are decisions recorded at various contexts:
https://projects.eclipse.org/projects/ee4j.nosql/governance
There is no question that the EFSP and JESP are not ready for primetime. This is why we voted against the JESP as it relies on external process documents that have not been sufficiently defined. We are only now getting close to finalizing the TCK process, and have open issues for how specification projects are managed with a visible component on the jakarta.ee website in a manner similar to what the jcp.org site did:
If you feel strongly about the Jakarta NoSQL project needing to change something, follow the EDP grievance handling:
Thanks everyone for chiming in.
So I understand that apparently – nobody seems to know when or where exactly – a decision has been made. A decision that should've been guarded by dedicated requirements if we had followed the self-implied JakartaEE process. Shouldn't that decision then not be formally documented visible to everyone interested? I'm not sure the JakartaEE community does itself a favor if the very first new spec added to the umbrella is incepted this way. Shouldn't the JakartaEE leadership have interest to avoid that kind of impression?
Another question I have is why the spec is not routed through Microprofile in the first place. MP seems to be a very decent place to experiment with new features to be standardized eventually and gain feedback from production deployments. With Jakarta NoSQL you start with a spec that's already designed in a way that contradicts design approaches in a competitive library (disclaimer: which I led for almost a decade) in very significant areas. It doesn't feel like a start from an open playground but with pretty significant decisions aleady having been made in a way that they're the complete opposite of what production deployments have seen working well over almost a decade.
Why not build something, make sure it sees enough developer projects, gather feedback, learn from that, tweak the design and eventually end up standardizing. In short: what would be wrong with a MP-driven NoSQL module *first* before standardizing an API (of course assuming that a discussion whether the MP community would want to do that happens beforehand)?
I deliberately posted to this list instead of the JNoSQL one as this boils down to a general question on how JakartaEE standards will come to be besides the formal process requirements. I can see that an immediate standardization makes sense for problem spaces for already established libraries. Creating one that actively takes different design decisions than the most prominently used one (and which already nicely works in a CDI environment btw.) and not putting that into extensive real world practice before standardizing it feels like a really risky way to approach that topic.
Cheers,
Ollie
|
