Gareth Clay

I think I hit this today: ``` javax.servlet:servlet-api:2.5 \--- com.netflix.netflix-commons:netflix-infix:0.3.0 \--- com.netflix.netflix-commons:netflix-eventbus:0.3.0 \--- com.netflix.eureka:eureka-client:1.10.11 +--- org.springframework.cloud:spring-cloud-starter-netflix-eureka-client:3.0.2 | \--- io.pivotal.spring.cloud:spring-cloud-services-starter-service-registry:3.2.2.BUILD-SNAPSHOT:20210329.130303-8 | +--- runtimeClasspath (requested io.pivotal.spring.cloud:spring-cloud-services-starter-service-registry) | \--- io.pivotal.spring.cloud:spring-cloud-services-dependencies:3.2.2.BUILD-SNAPSHOT:20210329.130301-8 | \--- runtimeClasspath...

Hi @buddyavis , yes we do support this, and it was recently optimised as part of #349. I'll check the documentation we have on this and update it if necessary....

iirc I think publication of docs maven artefacts was unintentional, and was deliberately turned off when we updated the build a while ago (https://github.com/spring-cloud/spring-cloud-app-broker/issues/269)

Hi @buddyavis, we think this is probably due to [this known issue](https://github.com/cloudfoundry/cf-java-client/issues/1051). Hopefully we'll be able to pick up the fix for this when it comes out.

This may have already been fixed due to #349. Needs a re-test.

We'll take a look at making space deletion configurable

This would be hugely useful for us. The feedback cycle when making manifest changes to a bosh-init deployed bosh is huge because of the package compilation step.

Could be supported already - if the service (user-defined or otherwise) already exists in the Target then we'll skip creation and move straight to binding to it. But we have...

Related to #350

Discussed today... We think a nice way to solve this would be to autoconfigure a data store based on database starter availability on the classpath.