Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jnosql-dev] [nosql-dev] Possibly renamingtheimplementationproject

We also updated the demo projects only to demos instead of artemis-demo.
The new source repository: https://github.com/JNOSQL/demos



On Tue, Dec 29, 2020 at 12:47 PM Otavio Santana <otaviopolianasantana@xxxxxxxxx> wrote:
FYI: This PR has been merged. Therefore, the name has been updated.
The next step is to rise again the discussion about upgrade the project to Jakarta EE 9 with the big bang.

On Mon, Oct 26, 2020 at 12:35 PM Werner Keil <werner.keil@xxxxxxx> wrote:

Ivar,

 

I think it was the latter for the last Point, EE4J simply did not exist, so hopefully when Jakarta EE 9 is out we can look into a possible Migration of JNoSQL.

 

Thanks for the confirmation About the PR, so I can review it (as Project member, not with my Spec Committee "hat") and or merge it.

 

Werner

 

Gesendet von Mail für Windows 10

 

Von: Ivar Grimstad
Gesendet: Montag, 26. Oktober 2020 12:34
An: Werner Keil
Betreff: Re: [jnosql-dev] [nosql-dev] Possibly renamingtheimplementationproject

 

 

 

On Mon, Oct 26, 2020 at 12:23 PM Werner Keil <werner.keil@xxxxxxx> wrote:

Ivar,

 

Thanks for the pointers. I told Otavio to get in touch with the EMO, but he does not seem to like the idea of renaming the whole Project at least Right now.

 

He already prepared a PR to change the internal module structure by eliminating both "Diana" and "Artemis" to avoid confusion with other projects like Apache Artemis. I hope that is OK now, or is there any plan review at the Spec Committee that might Prevent such changes at this point?

 

As I pointed out, the spec committee has not anything to do with how the compatible implementations name their products or sub-modules. And JNoSQL has nothing to do with he plan review by the specification committee. Only the plan for the specification project is relevant there.

 

That was primarily my reason to give the Spec Committee a heads-up because it was discussed last week.

 

I understand. The topic there was the plan review and not really how the naming is done in the implementation project. It came up as part of the feedback from the review, but shouldn't really be the focus of that group.

 

It not being an EE4J Project is also a problem and it seems odd especially compared to the relatively late joiner MVC which was added both API and implementation project there instead of Technology.

 

That’s unfortunate because the feedback from just the first NoSQL Framework talk showed us we scratched a big "itch" of the Industry with that and in a very (Web) API centric time yet another MVC spec on top of REST is far less important. We also saw that when Devoxx Ukraine accepted the NoSQL Endgame proposal over the others like the MVC one.

So even with the current name, what keeps JNoSQL from being moved over to EE4J at least after Jakarta EE 9 went final?

 

Nothing, but that is entirely a project decision. We chose to add Krazo under EE4J when we created the project. JNoSQL chose to add it under the Technology PMC when they created it. They probably had some reason for that, maybe it was created before EE4J was established? Anyway, if they choose to move to EE4J, I guess the EMO is the place to start.

 

Ivar 

 

 

Thanks,

Werner

 

Von: Ivar Grimstad
Gesendet: Montag, 26. Oktober 2020 08:11
An: jnosql developer discussions
Betreff: Re: [jnosql-dev] [nosql-dev] Possibly renamingtheimplementationproject

 

Hi,

 

There is no need to bring this to the Jakarta EE Specification Committee. They have absolutely no say in how an implementation project is named as long as all conventions are followed and the Jakarta name is not used in a wrongful way. There may be personal opinions among the specification committee member, but that does not make it official specification committee business. It is not even an EE4J project, so the EE4J PMC has no opinion about this either.

 

For any renaming of the project, refer to the Eclipse Development Handbook (https://www.eclipse.org/projects/handbook/#trademarks-background) and engage with the EMO and the Technology PMC.

 

Ivar

 

 

On Mon, Oct 26, 2020 at 12:29 AM Werner Keil <werner.keil@xxxxxxx> wrote:

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

artemis

mapping

diana

communication

org.eclipse.jnosql.diana

org.eclipse.diana.communication

org.eclipse.jnosql.artemis

org.eclipse.diana.mapping

jnosql-diana-driver

diana-driver

jnosql-artemis-extension

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

artemis

mapping

diana

communication

org.eclipse.jnosql.diana

org.eclipse.jnosql.communication

org.eclipse.jnosql.artemis

org.eclipse.jnosql.mapping

jnosql-diana-driver

jnosql-communication-driver

jnosql-artemis-extension

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

 


 

--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation, Inc.

Community. Code. Collaboration. 

Join us at our virtual event: EclipseCon 2020 - October 20-22

 

_______________________________________________
jnosql-dev mailing list
jnosql-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jnosql-dev


--
Otávio Santana


--
Otávio Santana

Back to the top