| Re: [nosql-dev] Possible rescoping of Jakarta NoSQL Spec and parts of the API |
_______________________________________________Dear Otavio/NoSQL Team,
After some discussions in the platform and especially this week’s Jakarta Spec Committee call, one takeaway for Jakarta NoSQL (and also other specs that may come in the future, or the likes of Jakarta Security, see https://github.com/eclipse-ee4j/security-api/issues/183 ) is, that „optional“ features may only anticipate the removal of these features or specs but if a spec defines something, there is no plan for „optionality“ along the lines of Java ME Embedded, and there see https://www.oracle.com/java/technologies/javame-embedded/javame-embedded-documentation.html specs like ME Security (JSR 177) and numerous others were Independent specs and not optional parts of one spec, but MEEP (https://docs.oracle.com/javame/8.0/api/meep/api/index.html) and JSR 385 which was modeled after it contain more opptional than mandatory packages, therefore at least These two JSR specs are examples for a large degree of modularity and optionality.
As of now, this is not desired for Jakarta EE specs in a similar way, so if implementors of Jakarta NoSQL or Security wanted to support only some type of database or authentication mechanism then there must be a different approach to it.
Since at least JPA and JDBC also had some of these challenges and one can decice, if they want to support RDBMS by Oracle, IBM, Microsoft, PostgreSQL, MariaDb or you name them, so for Jakarta NoSQL the idea of https://github.com/eclipse/jnosql-communication-driver and https://github.com/eclipse/jnosql-mapping-extension might be the best approach and a few packages in the API itself like https://github.com/eclipse-ee4j/nosql/tree/master/api/mapping/mapping-column/src/main/java/jakarta/nosql/mapping/column or https://github.com/eclipse-ee4j/nosql/tree/master/api/mapping/mapping-document/src/main/java/jakarta/nosql/mapping/document should most likely move into those mapping extensions unless the need for standardization of each was great enough to justify something like „Jakarta NoSQL Column“ or „Jakarta NoSQL Document“, a bit like JSP or Faces on top of the Servlet spec, but looking at some like https://github.com/eclipse-ee4j/nosql/blob/master/api/mapping/mapping-document/src/main/java/jakarta/nosql/mapping/document/DocumentRepositoryProducer.java I would arge, that Looks already a bit implementation-like and a more generic RepositoryProducer similar to Producer or ProducerFactory in CDI might help in the core mapping module of the API.
If more authentication mechanisms for Jakarta Security were desired, see https://github.com/eclipse-ee4j/security-api/issues/183#issuecomment-844384491 then that would be a similar case, probably speaking for a similar approach here like keeping it in Soteria or extension modules which are not part of the API and require every implementor and implementation to support every single one of them. A bit like Jakarta Servlet where only Servlet and HttpServlet are defined in the API but not extensions like CGIServlet (in Tomcat) VaadinServlet or SipServlet in the SIP Servlet JSR.
Werner
nosql-dev mailing list
nosql-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/nosql-dev