| Re: [jnosql-dev] [nosql-dev] Possibly renaming theimplementationproject |
_______________________________________________Please do not merge this until I also reached out to the Spec Committee.
Changing the names internally first to avoid confusion with Apache Artemis is a good idea.
I would not outrule changing the overall name, ideally that might work better before it goes Final, but Jakarta EE also has a couple of specs without a distinguished implementation project or this one https://jakarta.ee/specifications/batch/2.0/ where the former RI is also called "JBatch".
Gesendet von Mail für Windows 10
Von: Otavio Santana
Gesendet: Sonntag, 25. Oktober 2020 12:26
An: jnosql developer discussions
Betreff: Re: [jnosql-dev] [nosql-dev] Possibly renaming theimplementationproject
Ok, I've created the PR:
https://github.com/eclipse/jnosql/pull/249
Please, let me know what do you think.
Once you merged, I'll request to rename the projects.
On Sat, Oct 24, 2020 at 8:29 PM Werner Keil <werner.keil@xxxxxxx> wrote:
There will be no third name, if "Eclipse JNoSQL" was replaced with "Eclipse Somethingelse" then there are two project names "Jakarta NoSQL“ and the other new Name instead of "JNoSQL".
Of course I don’t think the Spec Committee, PMC or some of its members could force you to rename it. Please Keep in mind there IS NO REFERENCE IMPLEMENTATION, only a "Compatible Implementation“, thus I’ll simply forward that response to the Spec Committee and they’ll have o live with it for now. Of Course David or any other interested party could create another implementation at Apache (like "Johnzon", at least JSON-P also has no distinct implemention Project so far) or elsewhere, so let’s not worry about it for now.
Werner
Von: Otavio Santana
Gesendet: Sonntag, 25. Oktober 2020 01:02
An: jnosql developer discussions
Cc: nosql developer discussions
Betreff: Re: [jnosql-dev] [nosql-dev] Possibly renaming the implementationproject
When we reduce a couple of names and nicknames to just two it became easier to understand:
- Jakarta NoSQL: The spec
- JNoSQL: The reference implementation.
I don't like the idea to create a third name it will generate even more confusion. Furthermore, we have several articles, presentations, links, domain, a book that already uses the JNoSQL name.
On Sat, Oct 24, 2020 at 7:32 PM Werner Keil <werner.keil@xxxxxxx> wrote:
That would solve the ambiguity around Artemis, but the bigger problem David highlighted is "JNoSQL" sounding almost identical to "Jakarta NoSQL", so the spec and its compatible implementation are too easy to confuse.
I know, there are projects like "MachineLearning4J" but that does not implement some spec named "MachineLearning" or similar.
The "Diana" Name sounds more neutral, so replacing "org.eclipse.jnosql" with another more distinct project name would help to tell them apart more easily. "Artemis" would not work because of the Apache MQ project, AFAIK "Diana" is not used so unless there was a company holding a trademark or patent of some kind, it might be an acceptable name.
So the
Current
New Name
mapping
communication
org.eclipse.jnosql.diana
org.eclipse.diana.communication
org.eclipse.jnosql.artemis
org.eclipse.diana.mappingdiana-driver
diana-mapping-extension
If the "communication" part is vital then it could also be "diana-communication-driver", but not sure, if it really adds value there?
WDYT?
Of course we had to clarify with Eclipse if the name is valid, otherwise a new Name may have to be found or voted on, but let’s try the existing one and see, what Elipse IP or legal says About it?
Werner
Von: Otavio Santana
Gesendet: Sonntag, 25. Oktober 2020 00:16
An: nosql developer discussions
Cc: jnosql developer discussions
Betreff: Re: [nosql-dev] Possibly renaming the implementation project
Hum, I got it. If the issue is the nicknames around the project, we can remove all of them; therefore, instead of Diana and Artemis, it directly became communication and mapping. E.g.:
Current
New Name
mapping
communication
org.eclipse.jnosql.diana
org.eclipse.jnosql.communication
org.eclipse.jnosql.artemis
org.eclipse.jnosql.mappingjnosql-communication-driver
jnosql-mapping-extension
What do you think?
On Wed, Oct 21, 2020 at 2:09 PM Werner Keil <werner.keil@xxxxxxx> wrote:
All,
Please see a response by David/Tomitribe to the recent Plan Review where aside from procedual remarks and advise he also raised the question about po
----
+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.
----
The most natural choice if there isn’t any trademark problem would be "Eclipse Diana" instead of "Eclipse JNoSQL" because it is already used for a subsystem. Otherwise we would Need a vote and name search, not sure, which you prefer?
"Artemis" even as a subsystem is toxic and misleading because it is a subproject or subsystem of Apache ActiveMQ and used in places like
https://github.com/quarkusio/quarkus/tree/master/extensions
I highly recommend to replace "Artemis" with something neutral either "mapping" or "cdi", because it essentially defines the CDI Extension and one could imagine a module with "spring" or "spring-di" similar to https://github.com/quarkusio/quarkus/tree/master/extensions/spring-di.
I know especially "Eclipse Mylyn" changed its name from "Eclipse Mylar" after there was a trademark problem with a company like 3M I believe.
I see no problem using the Domain "jnosql.org" being used for the spec project instead like http://json-b.net/ is an alias for Jakarta JSON-B now. We could do that or clearly Point out, that „JNoSQL“ stands for „Jakarta NoSQL“ and rename the pages or sections Talking About the implementation.
Regards,
Werner
_______________________________________________
nosql-dev mailing list
nosql-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/nosql-dev
--
Otávio Santana
_______________________________________________
jnosql-dev mailing list
jnosql-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jnosql-dev
--
Otávio Santana
_______________________________________________
jnosql-dev mailing list
jnosql-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jnosql-dev
--
Otávio Santana
jnosql-dev mailing list
jnosql-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jnosql-dev
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation, Inc.
Community. Code. Collaboration.
Join us at our virtual event: EclipseCon 2020 - October 20-22