> How backwards compatible are these changes? They're totally backwards compatible. They're purely additive bundles.
If there's interest in pulling them into 2.0.0, we'd be happy to contribute them, but we're also fine holding off. On Thursday, May 2, 2019 at 4:54:39 AM UTC-7, jpl...@gmail.com wrote: > > I'd also like to see the HTTP header module brought into the core. > Palantir also has their own module that allows configuring the headers at > https://github.com/palantir/dropwizard-web-security > > -Justin > > On Wednesday, May 1, 2019 at 3:09:26 PM UTC-4, babc...@umich.edu wrote: >> >> While I'd prefer and wait until after 2.0 is out before including them >> into dropwizard, these modules seem well thought out: finer grained >> healthchecks with the ability to have them cached, and deeper support for >> HTTP headers seem great! >> >> How backwards compatible are these changes? >> >> Are you thinking submitting the healthcheck code against the metrics >> repo, the dropwizard repo, or a new repo under the dropwizard organization? >> >> On Monday, April 29, 2019 at 6:52:01 PM UTC-5, mza...@apple.com wrote: >>> >>> > We would publish these apps using the Apache License 2.0, as all >>> other Dropwizard projects do. >>> >>> Not apps, libraries. :) >>> >>> On Monday, April 29, 2019 at 4:49:33 PM UTC-7, mza...@apple.com wrote: >>>> >>>> Hey Jochen! >>>> >>>> >>>> > Do you have a list and description of the modules you're planning to >>>> open-source? >>>> >>>> We do! >>>> >>>> >>>> So we have three modules that we think make sense to live in the core >>>> Dropwizard project. Two of which are in a pretty ready state to be >>>> contributed, but because 2.0.0 is already in RC stage, might not make >>>> sense >>>> until that ships. >>>> >>>> >>>> The ones we have are: >>>> >>>> >>>> >>>> - A module containing a bundle that allows for configuration of >>>> various headers that are important for services that are accessed by >>>> web >>>> browsers. This includes: HTTP Strict Transport Security (HSTS), >>>> X-Frame-Options, X-Content-Type-Options, X-XSS-Protection (XSS), >>>> Content >>>> Security Policy (CSP), and Cross-Origin Resource Sharing (CORS). >>>> - A module containing a more-feature rich and extendable admin >>>> page, in short. This would need a little bit more work before we could >>>> contribute it, because there’s some cleanup work we’d need to do, and >>>> some >>>> changes to make it more flexible in how it’s used. >>>> - A bundle containing improved health check functionality. Provides >>>> functionality to allow a user to associate a schedule with any >>>> registered >>>> health checks to run on a recurring basis, and to allow marking which >>>> checks are critical to service health (i.e., if a dependency is down, >>>> it >>>> should bring the service down with it). The bundle then allows exposing >>>> another health check URL on the server port, which simply returns the >>>> aggregated view of the application’s health, rather than trigger checks >>>> on >>>> every health check. >>>> >>>> >>>> We also have some additional potential contributions that we don’t >>>> think would make sense to live in the core Dropwizard project, but rather >>>> (hopefully) could live in the Dropwizard organization. Our reasoning for >>>> including these would be that we already maintain these internally, and >>>> keep them up to date with the underlying client libraries we’re wrapping, >>>> AND we do so in a consistent way, so we figured it might make sense to >>>> broaden the audience for these, as there’s no good reason not to. >>>> >>>> >>>> >>>> - A module providing integration with Kafka. >>>> - A module providing integration with Redis. >>>> - A module providing integration with Cassandra. >>>> - A module providing integration with FoundationDB. >>>> >>>> >>>> There may be some others I’m missing here, that we may propose down the >>>> line, but this should be the majority of what we’d like to publish >>>> initially. >>>> >>>> >>>> > Also, what license are they currently under or which licenses do you >>>> plan to use for them? All projects under the Dropwizard umbrella are using >>>> the Apache License 2.0. >>>> >>>> Are there any other things to consider copyright- or license-wise when >>>> you're contributing these modules? >>>> >>>> >>>> We would publish these apps using the Apache License 2.0, as all other >>>> Dropwizard projects do. >>>> >>>> >>>> > And finally, do you plan to keep contributing to the modules you're >>>> going to open-source or will it be more or less a "code drop" without any >>>> further involvement? >>>> >>>> >>>> We plan to keep contributing to the modules we contribute. We maintain >>>> these internally on an ongoing basis already, so we’d just continue to do >>>> so. >>>> >>>> On Sunday, April 28, 2019 at 2:23:09 PM UTC-7, Jochen Schalanda wrote: >>>>> >>>>> Hi Michael, >>>>> >>>>> Thanks for reaching out! >>>>> >>>>> Depending on the specific modules, it might make sense to adopt them >>>>> in the Dropwizard organization on GitHub. Alternatively, you can also >>>>> host >>>>> them in your own accounts and add them to the module directory at >>>>> https://modules.dropwizard.io/, as Nick described in his last email. >>>>> >>>>> Do you have a list and description of the modules you're planning to >>>>> open-source? >>>>> >>>>> Also, what license are they currently under or which licenses do you >>>>> plan to use for them? All projects under the Dropwizard umbrella are >>>>> using >>>>> the Apache License 2.0. >>>>> Are there any other things to consider copyright- or license-wise when >>>>> you're contributing these modules? >>>>> >>>>> And finally, do you plan to keep contributing to the modules you're >>>>> going to open-source or will it be more or less a "code drop" without any >>>>> further involvement? >>>>> >>>>> >>>>> Best regards, >>>>> Jochen >>>>> >>>>> Am 27.04.2019 um 23:14 schrieb mzamani via dropwizard-dev < >>>>> dropwiz...@googlegroups.com>: >>>>> >>>>> Hey dropwizard-dev, >>>>> >>>>> We've got some modules we'd like to open source that we use internally >>>>> at Apple. Some of those might make sense to be included in the core >>>>> Dropwizard project, but others definitely don't, and it would make much >>>>> more sense to have them live outside of the Dropwizard repo. >>>>> >>>>> We're hoping we might be able to contribute these to the Dropwizard >>>>> organization (https://github.com/dropwizard) instead, as that seems >>>>> like a place where it would make sense for Dropwizard extensions to live. >>>>> However, we wanted to consult you guys to see if you had any strong >>>>> preferences one way or another, or if there's any process we should be >>>>> aware of in order to add a project to the Dropwizard GitHub organization. >>>>> >>>>> It might be worth mentioning that it would be easier for us to open >>>>> source them if they can live in the Dropwizard organization, rather than >>>>> a >>>>> brand new spot, due to how our corporate open source policy works. >>>>> >>>>> 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. For more options, visit https://groups.google.com/d/optout.
