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
Comments
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. |
I really like Parson |
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". |
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. |
reminder: I go with names in following order:
and with following repo split:
unless I hear otherwise or some other suggestions. |
proposal is at https://projects.eclipse.org/proposals/eclipse-parsson |
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
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
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.
The text was updated successfully, but these errors were encountered: