Request for access to org.json.simple groupId

[loegering]

I've opened a ticket with Sonatype (https://issues.sonatype.org/browse/OSSRH-24756) and was informed I must get the permission of the current publishers to the groupId org.json in order to publish to a sub groupId.

I've taken on updating https://github.com/fangyidong/json-simple at https://github.com/cliftonlabs/json-simple.

Here's a list of reasons I believe the library should be deployed under the org.json.simple groupId:

1. The code is in the java package org.json.simple due to the previous author's design choice.
2. I like my groupIds to correspond to the java packages so I can more easily recognize package conflicts among my dependencies.
3. json.org mentions the library explicitly on its home web page (as it does with many other JSON libraries, including this one).
4. The original library used com.googlecode.json-simple groupId but the website is deprecated and only exists for archival reasons. Not to mention misrepresents the original domain, probably due to the reasons I'm here.
5. I don't think there were any previous plans to use org.json.simple.
6. It is unlikely to be an issue in the future.
7. The groupId org.json.simple just feels right to me.

And so, for these reasons I'd like to be granted access to deploy the json-simple artifact under the org.json.simple groupId.

Thank you for your time helping me with this issue.
--Davin Loegering

[johnjaylward]

json.org was originally owned by Douglas Crawford (maybe still?). He designed the original JSON spec and created this project as a reference implementation for other JSON projects. The other projects listed on JSON.org are similar to other projects that list "Companies that use our product". A listing there is by no means a valid reason for being under the org.json group identifier, even as a sub group.

Your other reasons listed seem to mostly be that it's your personal preference without any tangible reasons.

Your group id can be anything you want. It doesn't have to be a reversed domain name. Why not use "json-simple" as your group name instead?

[loegering]

Thanks for the quick reply and information on the json.org website.

There isn't any reason not to use an alternative, I just felt that org.json.simple was preferable. As many of the best/good development practices can be labeled as a widely adopted personal preference, I think there can be tangible merit to even personal preferences.

Have I misunderstood the website as a public service to help those looking to adopt the JSON data format? I merely thought it would make a good maven coordinate for the popular library. If I'm not misunderstanding the goal of the website, I don't see any reason not to be granted access to org.json.simple either.

Please advise.

[johnjaylward]

That is the point of the website. However, I don't know who currently maintains it if it's maintained at all. As stated, the domain was made by the author of the spec. Just because I use java, doesn't mean I should use the net.java group id. I personally feel the same applies here.

The 2 tools are not related. json-simple does not rely on JSON-Java at all. I think it's more misleading than not to have them hosted under the same group id.

[loegering]

The projects are quite related using the same RFC specifications and purpose, it's just different implementations, though I understand that you mean json-simple isn't a 'module' of this specific project.

If I have the groupId com.google I think it is pretty clear that (if these projects were implemented in java) com.google.mail, com.google.calendar, com.google.plus, and com.google.drive are all different projects and vaguely related under the identity of google. I think the same case could be argued for org.json where each project could be understood as an implementation of the same thing. Using org.json this project would obviously be org.json.java but since maven is implicitly java it could be argued that the java part is dropped for org.json. The groupId org.json.simple is a simple implementation of JSON and makes sense to be there. Other implementations from the json.org website could be listed as org.json.jsonp, org.json.json-lib, org.json.argo, org.json.stringtree, or even org.json.gson could all be implicitly understood as implementations of the org.json specification. You shouldn't need more than one in your POM anyway because one they are likely to conflict, and it would be bad practice (IMHO) to do the same thing multiple ways in the same project.

For me as a developer it was misleading that JSON.simple used org.json.simple java packages but was using the maven groupId com.googlecode.json-simple. Understanding the concept/reasons for java package names and maven's java groupIds, it seems needlessly divergent to do otherwise.

I guess, I'm proposing that implementations of the JSON specifications be allowed a groupId under the org.json as implementations of that data format exchange. It will make their purpose clear and self documenting at the POM level to any developer that uses them. Of course the maintainer of any implementation must choose to request their respective sub groupId that isn't already in use and their project is capable of doing what is described at json.org. Thoughts?

[johnjaylward]

I'd argue that the original implementation of json-simple should not have used the org.json package either. I do agree it should have used the same group-id and package name for consistency and clarity.

However implementations of of the java cryptography API are not expected to use the same package structure as the API (java.security and javax.crypto). You would place your implementation in their own packages.

By reusing the package name, you gain access to default (package) scoped objects/fields/methods, which is also probably not what you want (or the original developer that you are implementing under).

Maybe your google example was just quick, but I think it's a point for not using org.json. The only entity using the com.google namespace should be Google. If you write your own code that implements a com.google.plus API, I would not expect to see it share the com.google.plus package space. I would expect your implementation of com.google.plus.API to fall under your own namespace like my.package.google-plus for example. I'd then expect you to post to the my.package maven repository. If you place your code in a com.google.davin-plus package, it makes it look like google is implicitly supporting your project. If it was com.googlecode.davin-plus then it's shows that this is indeed a non-google product as everyone knows that googlecode.com is a developer tool hosted by google, and not the google entity itself. However, I'd still argue against using a shared namespace like com.googlecode, com.bitbucket, or com.github as it makes it difficult to see who the real owner is for that.

In the end, I personally feel it's best for each project to maintain it's own unique namespace. This prevents classname collisions in case for some reason someone wants to use https://github.com/FasterXML/jackson, https://github.com/cliftonlabs/json-simple, and JSONJava in the same project. I also see it as keeping each namespace cleaner for future implementations or people wanting to extend your project. It also showcases your project as it's own. In the future, if you picked a unique enough namespace, you can also release other projects under it that may not be related: davin.simple-json, davin.gis-tool, davin.google-plus, and davin.someSmartphoneApp.

If someone were to fork this project and add Java-8 features like Streams and Optional, I would also expect them to publish it under their own namespace (unless this project was dead for some reason and they were the sole maintainer of the code).

[loegering]

I agree that it shouldn't have been written in the package org.json.simple, but I wasn't the original author and one could say the damage is done especially if I intend to maintain a backwards compatible library. Which is important for many of my projects (and I'm sure others if they adopt the 2.0.0 version) for the time being.

Writing an alternative implementation of a specification and implementing/using an API are apples and oranges. You mention an implementation of the cryptography API which wouldn't be an alternative implementation of the specifications of the cryptography API. If it were an alternative implementation of the same exact specifications or otherwise extended, simplified or improved the cryptography API that couldn't for whatever reason be part of the original implementation or another version, I would see a case for it being a sub package. Regardless, I am under the impression that the java.* namespace was reserved for APIs included in the JDK and so I would also share your expectations of the alternative not being included in a sub package of it for the case of any alternative to what is in the java.* namespace unless it was distributed in the official release of the JDK.

There shouldn't be any reuse of packages for specifically the reasons you mentioned about package scoped access and namespace collisions. We can't predict the requirements of other projects and namespacing our classes has proven to be effective at making life easier on all developers. Like in my hypothetical alternative, com.google.plus.davin, would be in its own package davin and not have access to the package level code due to the code being located in the package plus. As an alternative implementation it shouldn't need any of that code either, but the public code is technically available to it. If com.google.plus was a public specification designed from the beginning to have alternatives (not too far from the likes of the JSON data format specifications) it would probably look something like this:
com.google.plus.official
com.google.plus.davin
com.google.plus.anotherAlternative
in the not so subtle case of json.org:
org.json //the official implementation.
org.json.simple //my alternative.
org.json.anotherAlternative //someone else's alternative if they so choose to request a sub groupId.

I think your strongest point is that a groupId of say com.google.* implies it is implicitly endorsed or supported by Google somehow and Google shouldn't be required to endorse any project just because it is an alternative to one of their APIs or products even if it was based on the exact same specifications. Though highly idealized like OSS, it might be convenient for developers that wish to use the best implementation for their needs, by reducing their research space to find the right fit. I also strongly agree with your point on shared namespaces and the lack clarity on the owner and should be avoided.

So, if org.json is unwilling to take collective ownership of alternatives by providing a sub groupId to them. Nor is org.json willing to endorse future releases of json-simple artifacts if not alternatives in general. I can accept that this issue is simply closed. I will just have to find a less-preferable alternative groupId for it.

In the case that this issue is closed, thank you for your support on this issue!