search

BetterCloud / vault-java-driver

Zero-dependency Java client for HashiCorp's Vault
https://bettercloud.github.io/vault-java-driver/
334 stars 224 forks source link

Added the following #245

Open darkedges opened 3 years ago

darkedges commented 3 years ago

Added the following

This relates to

edmundham commented 2 years ago

Hello vault-java-driver team, can someone look into merging this and have this released?

steve-perkins commented 2 years ago

I was the primary (almost sole) contributor to this project when I worked at BetterCloud, but I resigned from there in late 2019. Initially there was discussion about a transition plan, but then a funny little thing happened in early 2020...

By the time the world settled back down, there had been a lot of turnover, and I just no longer had the connections at BetterCloud that I once did. My sense is that there is no interest there in continuing this without me driving it. And I have no personal interest in maintaining a fork, because my only use of Vault these days is by way of Vault Agent Injector in a Kubernetes environment.

My recommendation would be to either:

  1. Migrate to Vault Agent Injector, if that's an option for your use case,
  2. Migrate to Spring Vault, if you are open to Spring (it MAY be possible separate the pure Vault bits from the Spring dependency, I'm not sure), or
  3. Just fall back to interacting with the Vault through vanilla REST calls.

Of course, the community launching a fork is also an option. But I think you'd be on your own, with no one upstream either blessing or opposing it.

edmundham commented 2 years ago

@steve-perkins , thank you so much for your fast reply. I'll definitely look for the other options then :)

tledkov commented 1 year ago

@henryx @darkedges I've forked the project as io.github.jopenlibs:vault-java-driver - as the first project of the simple github organization https://github.com/jopenlibs.

Now I really need in small bugfix and few simple improvements. Also I'll provide write/maintain rights for any developer who interest in the project. I guess it is better than a lot of individual forks with short life time. 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 deployed artifacts.

@steve-perkins Do you have any objections? Blessing? A parting word? %) The library is very useful for integration services run on bare-metal without Kuber hosts, when adding spring dependencies is not an option for a project.

Now I've fixed the issue with /sys/wrapping/unwrap endpoint (it is blocker for my integration) and publish artifacts at the staging repo.

I'm going to release 5.2.0 soon...