Migrated Key Vault JCA library to use azure-json serialization/deserialization

[vcolin7]

This library shades Jackson classes to avoid having many external dependencies, so I've gone ahead and done the same for azure-json. I did copy a number of classes over from azure-core, so maybe there's a better approach for that. Let me know what you think Alan Zimmer (@alzimmermsft).

For more information on this, see: #40614.

[Alan Zimmer (alzimmermsft)]

With the recommended changes to the JSON utilities class, you can delete out all the code copied from azure-core

[Xiaolu Dai (saragluna)]

Hey vcolin7, thanks for creating this PR. I am wondering whether we should revert the two changes you made for the AAD Login URL, before we merge in any PR? Seems like you are actively contributing to make the JCA library better, and we also have some features that want to be merged in, and out as regular release. So I think if those two changes won't be out as GA in the near future, maybe we should revert it, and merge it back to main when it's ready to GA.

[vcolin7]

Hey vcolin7, thanks for creating this PR. I am wondering whether we should revert the two changes you made for the AAD Login URL, before we merge in any PR? Seems like you are actively contributing to make the JCA library better, and we also have some features that want to be merged in, and out as regular release. So I think if those two changes won't be out as GA in the near future, maybe we should revert it, and merge it back to main when it's ready to GA.

I think if you guys want to release a single feature that's already in main we should not revert the commits, but instead create a release branch containing only said feature, which is what we do with our other data plane libraries. We have a script that can help you set up the branch and then it would be a matter of cherry-picking the commits that include the feature work. We can talk about this on a separate chat if you need any assistance setting things up.

[Xiaolu Dai (saragluna)]

Thanks vcolin7. But what I'm talking is we are having a PR #41303, we would like to merge into the main branch. But the main branch already has changes only suitable for beta releases. So my question is, should we use the main branch as a place for code ready for GA release, and move the code for beta releases to a feature branch?

[Azure SDK Bot (azure-sdk)]

API change check

API changes are not detected in this pull request.

[vcolin7]

Thanks vcolin7. But what I'm talking is we are having a PR #41303, we would like to merge into the main branch. But the main branch already has changes only suitable for beta releases. So my question is, should we use the main branch as a place for code ready for GA release, and move the code for beta releases to a feature branch?

I think we should merge your PR to main and then release a new stable version from a separate release branch that does not include the beta changes we are not ready to GA yet. This is because if we release any other beta in the future, it should not be missing features or bug fixes we already released for a "previous" stable version (like this that would be included in a 2.8.2 release). Reverting the commits with the beta work would add unnecessary overhead. We should be getting close to GA'ing the beta work anyway, we're just waiting for customer feedback on it.

[Josh Free (joshfree)]

vcolin7 what's happening with this PR? Can we get this wrapped up?

[vcolin7]

/azp run java - keyvault - ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).