One option that might work rather easily, as long as Eclipse Copyright legal experts do not see a problem with that could be calling the implementation "Diana“. It is already a subsystem, "Artemis“ although also more a module there is used by Apache with JMS, therefore it may be confusing or even violate some trademarks by Apache Foundation, but I could not see any significant project with the name "Diana“. Guess we should also share the suggestions (by David) on the NoSQL Mailing lists, but what are thoughts here or is it a No-Go from the IP or Trademark side? Werner Gesendet von Mail für Windows 10 David, Those are some good thoughts. It would be nice to see at least a second implementation even before the Final release.
Agree. I'd highly recommend the project target a few Progress Reviews to get formal feedback as key things progress. I'd also highly recommend my fellow Specification Committee members view these phases as opportunities to mentor and provide comments with their votes. Together with Thodoris and in some Events Otavio will also help us I’m currently working on a new conference presentation „NoSQL Endgame“ comparing some popular NoSQL persistence frameworks, and without sharing too much before it Premiers next week at the first online conference, even the most popular fameworks often have many shortcomings, especially when it comes to switching between or supporting multiple NoSQL DB Systems. I would say Spring Data is probably in the best Position beside Jakarta NoSQL, so it also seems in the interest of several others to implement such a Standard. The name yes, that seems a bit confusing because it just differs by a „J“, not sure, how to do that, but Looking at e.g. Projects like Yasson or Krazo (which had to Change ist Name when it came to Eclipse) Show, this can be done, so I don’t think it would be a big Problem. Werner Gesendet von Mail für Windows 10 +1 Tomitribe We're voting +1 as we believe the goal of the specification has merit and we are excited to see new specifications being attempted in the Jakarta-verse. A key exit criteria for us before we'd vote +1 on a final release would be to ensure there is industry interest in implementing this API. Before any final ballot we'd want to see a second implementation being worked on and nod from them saying the API is ready. We'd also recommend a cleaner line between the implementation and the specification. We understand the intent is for the specification's complete and full name to be "Jakarta NoSQL" and the implementation to be "Eclipse JNoSQL", which we agree are clear and separate. However, at current time the front page of the draft specification has the implementation's "JNoSQL" logo and a third ambiguous brand name of "Eclipse Jakarta NoSQL", which can be interpreted as the long version of either "Jakarta NoSQL" or "Eclipse JNoSQL." We recommend a clean line of using "Jakarta" to refer to the specification and "Eclipse" to refer to the implementation. A final thing to consider which is far outside the specification process and should only be interpreted as advice. Consider entirely renaming the implementation project to make it impossible for it to be confused for the specification itself. This could go a long way to encouraging other implementations to show up and feel they have a reasonable chance to compete without branding confusion that favors one implementation and puts them at a disadvantage.
Greetings Jakarta EE Specification Committee. I need your vote to approve the plan for Jakarta NoSQL 1.0. The JESP/EFSP requires a successful ballot of the Specification Committee in order to ratify the products of this release as a Final Specification (as that term is defined in the EFSP). The relevant materials are available here: https://github.com/jakartaee/specifications/pull/236
https://deploy-preview-236--jakartaee-specifications.netlify.app/specifications/nosql/1.0/ Per the process, this will be a seven day ballot, ending on October 12, 2020 that requires a Super-majority positive vote of the Specification Committee members (note that there is no veto). Community input is welcome, but only votes cast by Specification Committee Representatives will be counted. The Specification Committee is composed of representatives of the Jakarta EE Working Group Member Companies (Fujitsu, IBM, Oracle, Payara, Red Hat, Tomitribe, and Primeton), along with individuals who represent the EE4J PMC, Participant Members, and Committer Members. Specification Committee representatives, your vote is hereby requested. Please respond with +1 (positive), 0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated. Thanks … -- Jakarta EE Developer Advocate | Eclipse Foundation, Inc. Community. Code. Collaboration. Join us at our virtual event: EclipseCon 2020 - October 20-22 _______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
|
