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 <javascript:>>: > > 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.
