Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New name for the implementation project/repo split #285

Closed
lukasj opened this issue Apr 23, 2021 · 7 comments
Closed

New name for the implementation project/repo split #285

lukasj opened this issue Apr 23, 2021 · 7 comments
Labels
Projects

Comments

@lukasj
Copy link
Contributor

lukasj commented Apr 23, 2021

I'm about to set new name for the implementation project eventually.

I suggest keep using Eclipse JSONP.

Alternative names:

  • jsonp4j
  • Parson
  • Parsson

Does anyone have ideas and/or suggestions for something else?

Since this requires involvement or other teams within Eclipse Fnd, I'm also about to ask for splitting the project into 3 repositories - one for API, one for the TCK and one for the implementation project unless there is strong opinion on not doing so. Comments on how this change should be done are welcomed - I can see also an option to have API and TCK in one repo and implementation in the other.

Silence within the next week means that I'll go with my preference but I would really prefer to get wider consensus on this.

I would like to bring this up to appropriate places for approval by the next Friday, April 30 2021.

@jbescos
Copy link
Member

jbescos commented Apr 23, 2021

Name is fine with me.

I like more to have API and TCK in the same repository. This is convenient because we don't need to release a new API in maven to make TCK tests to work with the changes.

@dalexandrov
Copy link

I really like Parson

@jjspiegel
Copy link

I am in favor of putting the API in a separate repository, especially if this means that it versions independently. Right now it is troublesome for projects that only depend on the API because the version appears to move so frequently even when nothing has changed.

I also like your suggestion of "Eclipse JSONP".

@keilw
Copy link
Member

keilw commented Apr 23, 2021

I think the API should be separate similar to jsonb, and since that got its own dedicated implementation project name "Yasson" I would prefer "Parson" (if "Parsson" like "Yasson" made it easier to avoid a brand conflict, why not) because of both

@waynebeaton
Copy link

I think the API should be separate similar to jsonb, and since that got its own dedicated implementation project name "Yasson" I would prefer "Parson" (if "Parsson" like "Yasson" made it easier to avoid a brand conflict, why not) because of both

Determining whether or not we can use a name depends on how we intend to use a name and how it is used by others. Generally, the selection of name is about avoiding confusion and it's not always obvious. The simple check is to try searching for " technology" using your favourite search engine to see what comes up; even if you do find other technologies with the same name, if a case can be made that an average person would not confuse our project's use with that hypothetical other hit's use, then it may be okay. Just spelling a word differently doesn't always get you off the hook (we couldn't reasonably try to claim that a project name "Hadooop" is distinct from "Hadoop"). Of course, completely distinct names are always best.

We'll run whatever you come up with past the Trademarks Team who will take care of checking against the EUIPO, USPTO, etc. It's always good to have a couple of options to fall back on.

@lukasj
Copy link
Contributor Author

lukasj commented Apr 28, 2021

reminder:

I go with names in following order:

  • Parsson
  • Eclipse JSONP
  • jsonp4j

and with following repo split:

  • API + TCK
  • implementation

unless I hear otherwise or some other suggestions.

@lukasj
Copy link
Contributor Author

lukasj commented May 5, 2021

@lukasj lukasj closed this as completed May 5, 2021
@lukasj lukasj added the 2.1 label Sep 30, 2021
@lukasj lukasj added this to Done in JSONP 2.1 Sep 30, 2021
asvanberg added a commit to asvanberg/donkey that referenced this issue Dec 18, 2021
josmmirror pushed a commit to JOSM/josm that referenced this issue May 10, 2023
Parsson was split out from the JSONP repository in 2021 (see
jakartaee/jsonp-api#285 ). It is the default provider,
and will "just work" without additional configuration.

Many plugins use `javax.json`, so the scheduled removal of the `javax.json`
dependencies is set to milestone:"24.12" (see #22941).

Changes between javax.json and jakarta.json 2.0:
* Rename of `javax.json` to `jakarta.json`
* Some additional bug fixes

This will enable us to move easily to jakarta.json 2.1 in the future.
The changes of note with 2.1 includes:
* Better handling of duplicated keys
* Additional APIs around primitive types
* API to get current event from JsonParser

We cannot currently move to jakarta.json 2.1 since it requires Java 11+.

git-svn-id: https://josm.openstreetmap.de/svn/trunk@18723 0c6e7542-c601-0410-84e7-c038aed88b3b
MarcelloPerathoner pushed a commit to MarcelloPerathoner/josm that referenced this issue Nov 2, 2023
Parsson was split out from the JSONP repository in 2021 (see
jakartaee/jsonp-api#285 ). It is the default provider,
and will "just work" without additional configuration.

Many plugins use `javax.json`, so the scheduled removal of the `javax.json`
dependencies is set to milestone:"24.12" (see #22941).

Changes between javax.json and jakarta.json 2.0:
* Rename of `javax.json` to `jakarta.json`
* Some additional bug fixes

This will enable us to move easily to jakarta.json 2.1 in the future.
The changes of note with 2.1 includes:
* Better handling of duplicated keys
* Additional APIs around primitive types
* API to get current event from JsonParser

We cannot currently move to jakarta.json 2.1 since it requires Java 11+.

git-svn-id: https://josm.openstreetmap.de/svn/trunk@18723 0c6e7542-c601-0410-84e7-c038aed88b3b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Development

No branches or pull requests

6 participants