> We totally agree! It definitely seems less confusing to have this be opt-in functionality in a separate library.
Sorry! Just to correct this, I meant to say: It definitely seems less confusing to *have this be part of the core project than have it be opt-in functionality in a separate library.* On Monday, July 20, 2020 at 9:06:49 AM UTC-7, Natalie Zamani wrote: > > Hey Jochen! > > Apologies for also being late to reply. > > I think a standalone library makes sense if the goal is for it to be used >> in other projects than dropwizard-health or Dropwizard in general. >> > Right, that's definitely our goal. Allowing this same logic to be used in > apps that use other server stacks or frameworks, as it's really only the > bindings to Dropwizard that are dropwizard-specific. > > You're welcome to start it under the umbrella of the Dropwizard >> organization on GitHub, if you want to go that route. > > And that would be great! I think we (Peter and I) still don't have > permissions to create a new repo, but the name we were thinking of for this > was *health, *if we could get help creating that repo in the DW org. :) > > In general, I think it would also make sense to move dropwizard-health as >> a core module into Dropwizard, so that people don't have to discover it >> independently. >> So we'd have the standalone library for the framework-independent parts >> and dropwizard-health as a core module in Dropwizard. >> What do you think? > > We totally agree! It definitely seems less confusing to have this be > opt-in functionality in a separate library. > > So I think we would first need a new *health *repo, which I'll need to > contribute the framework-agnostic logic into, and then I'll work on > consuming that in the core Dropwizard project once that exists. > Sound reasonable? > > On Sunday, July 12, 2020 at 11:40:39 AM UTC-7, Jochen Schalanda wrote: >> >> Hi Natalie, >> >> sorry for the late reply. :-) >> >> > I’m curious about where you all think might be a good home for that new >> library though. The current ideas, in order of which I currently prefer: >> > * A new standalone library >> > * A sub module of metrics >> > * a sub module of Dropwizard-health >> >> I think a standalone library makes sense if the goal is for it to be used >> in other projects than dropwizard-health or Dropwizard in general. >> You're welcome to start it under the umbrella of the Dropwizard >> organization on GitHub, if you want to go that route. >> >> In general, I think it would also make sense to move dropwizard-health as >> a core module into Dropwizard, so that people don't have to discover it >> independently. >> >> So we'd have the standalone library for the framework-independent parts >> and dropwizard-health as a core module in Dropwizard. >> What do you think? >> >> >> Best regards, >> Jochen >> >> > Hi folks! >> > >> > Awhile back we contributed the dropwizard-health module, which offers >> some extra functionality for health checks in the Dropwizard framework. >> I’ve been wanting to separate out the core logic of that library from the >> Dropwizard glue, similar to the metrics library, because much of it is very >> framework agnostic, and generally useful. >> > >> > I’m curious about where you all think might be a good home for that new >> library though. The current ideas, in order of which I currently prefer: >> > * A new standalone library >> > * A sub module of metrics >> > * a sub module of Dropwizard-health >> > >> > Any thoughts on this? I want the DW glue to remain in the same library, >> so that won’t change. >> > >> > Thanks! >> >> -- You received this message because you are subscribed to the Google Groups "dropwizard-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dropwizard-dev/19e15844-0cc7-42e5-9b15-c6851be001ceo%40googlegroups.com.
