[MDEP-799] - improve dependency:tree to add optional JSON output of the results

[kezhenxu94]

Following this checklist to help us incorporate your contribution quickly and easily:

• [x] Make sure there is a JIRA issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes.
• [x] Each commit in the pull request should have a meaningful subject line and body.
• [x] Format the pull request title like [MDEP-XXX] - Fixes bug in ApproximateQuantiles, where you replace MDEP-XXX with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message.
• [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• [x] Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
• [x] You have run the integration tests successfully (mvn -Prun-its clean verify).

If your pull request is about ~20 lines of code you don't need to sign an Individual Contributor License Agreement if you are unsure please ask on the developers list.

(I'm Apache Member and I've signed ICLA)

To make clear that you license your contribution under the Apache License Version 2.0, January 2004 you have to acknowledge this by using the following check-box.

• [x] I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

• [x] In any other case, please file an Apache Individual Contributor License Agreement.

[kezhenxu94]

• why json is created manually? Maybe use FasterXML

Is it OK to add some dependencies? I thought you might want to keep the dependencies minimal.

• missing documentation, I propose separate page with output example and description

OK, will add doc

[slawekjaranowski]

• why json is created manually? Maybe use FasterXML

Is it OK to add some dependencies? I thought you might want to keep the dependencies minimal.

It is ok if meets: https://maven.apache.org/developers/dependency-policies.html

• missing documentation, I propose separate page with output example and description

OK, will add doc

[monperrus]

super cool feature, hope we can get it merged!

[MartinWitt]

Hey, as this PR seems stale, and I want this feature, I would implement this in a new PR. Do you prefer to use a JSON library, which one do you like, or shall I write a JSON printer myself?

[elharo]

I strongly prefer no extra dependencies for this. JSON libraries in particular are a world of security bugs, unmaintained code, violations of Java conventions, and overall poor design. For JSON output, writing strings is straight-forward. A library shouldn't be necessary to implement this.

Possibly tests (and only tests) might want to parse the JSON, and for that a library would be helpful. Do not use Jackson. javax.json or perhaps GSON might be OK.

[michael-o]

I strongly prefer no extra dependencies for this. JSON libraries in particular are a world of security bugs, unmaintained code, violations of Java conventions, and overall poor design. For JSON output, writing strings is straight-forward. A library shouldn't be necessary to implement this.

Possibly tests (and only tests) might want to parse the JSON, and for that a library would be helpful. Do not use Jackson. javax.json or perhaps GSON might be OK.

GSON is superseded already.

[elharo]

I strongly prefer no extra dependencies for this. JSON libraries in particular are a world of security bugs, unmaintained code, violations of Java conventions, and overall poor design. For JSON output, writing strings is straight-forward. A library shouldn't be necessary to implement this. Possibly tests (and only tests) might want to parse the JSON, and for that a library would be helpful. Do not use Jackson. javax.json or perhaps GSON might be OK.

GSON is superseded already.

By what?

[cstamas]

What makes you think that "gson is superseded"?

[michael-o]

What makes you think that "gson is superseded"?

There is a while post about it.

[cstamas]

Where?

[michael-o]

Where?

Searching, it was from the original authors, maybe even Kevin Bourillion.

[cstamas]

AFAIK, GSON was "just" moved out from Google umbrella, and is in maintenance mode, as it is feature complete (or something, dunno, guessing), but the project is quite lively and have regular releases and fixes.

[elharo]

While I was at Google, I did successfully lobby to get GSON adopted and officially supported by the Java core libraries team. This was part of my then day job managing dependencies for the Google Cloud Java client libraries, which depended quite heavily on GSON. That was a couple of years ago. Things might have changed since, but anything you heard about the project pre-2021 is certainly out of date.

[elharo]

feature complete under another PR