Open jjathman opened 7 years ago
That's how the starters work and is the normal pattern for Spring Boot and Spring Cloud. So, I'd say it's behaving as designed. What does it bring in that you don't want?
And after looking at the starter, it's the minimal dependencies for it.
spring-cloud-starter-consul
pulls in spring-boot-starter-web
which pulls in spring-boot-starter-tomcat
etc.
Here's what I'm trying to do and maybe you can help me find a better path. I'm building an internal library for my company to help us standardized our usage of Consul. I'd like to use the Consul related features of Spring cloud, but since this is a library I don't want to pull in things like tomcat or extra logging frameworks (beyond just SLF4J). I can't seem to figure out the dependencies I should be using.
If you don't want tomcat you're going to need to exclude it. We can look at making it optional which has been requested in Spring Cloud zookeeper.
OK thanks, that's what I'll do. I suppose what I'm trying to do isn't part of the normal usage pattern.
spring-cloud-consul-discovery
version 1.1.2.RELEASE says that joda-time is an optional dependency, but it appears as though it is needed by theorg.springframework.cloud.consul.discovery.HeartbeatProperties
class. It doesn't seem possible for a consumer to just have a compile time dependency onspring-cloud-consul-discovery
without also explicitly including a runtime dependency on joda-time. Is this expected or am I not understanding how to correctly use this dependency? I'd rather not use the starter dependencies as it includes a lot of other stuff I don't want.