Migrate away from Bettercloud Vault Client

[adammead]

The Bettercloud client is no longer supported - see this comment. As such, we should migrate away from it to another client implementation that can be shared with the Vault Connector.

[neckron]

Hi @adammead / @adesjardin

I was analyzing this issue, correct me please if I missunderstood the AS-IS.

AS-IS

TO-BE (proposal)

• new avio-hhtp-vault-connector will provide a mechanism to use a vanilla/wrapper (could be Grizzly) http client or mule-http-connector (imported as a dependency I think we can use this specific part of the connector) to retrieve secrets from Vault.

Please let me know what do you think about this approach.

[adammead]

Hi @neckron,

I don't think we want to use the mule-http-connector dependency of the client. We want to use the Mule HTTP client (org.mule.runtime.http.api.client.HttpClient) since that is required for MuleSoft certification. Other than that, the approach looks good.

I think the new library should be called vault-http-client since it's not a MuleSoft connector, but rather a Vault client library.

[tledkov]

@adammead I'm sorry for inconvenient.

I've forked the vault-java-driver as io.github.jopenlibs:vault-java-driver the project of simple open source github organization.
I'm going to support it by review & deploy sometimes. Any developer can join to the simple organization.

It seems to me that the advantage of the organization is that when changing the developer, it will not be necessary to change the group of artifacts.