Calling for Maintainers

[rbeauchamp]

This issue is only for people who are asking to become a core maintainer of this open source project:

Because OData WebApi does not support ASP.NET Core (see OData/WebApi#939) and I am 100% focused on new ASP.NET Core development, I don't have the capacity to maintain this project. Still, I'd love to see it live on and am seeking one or two "core" maintainers. Ideally, these would be people who have already contributed through PRs and understand the inner workings and overall design.

[KDet]

I've contributed "Custom property resolver" #176 .
Could someone review related pull request and add it to the next version?

[robertmclaws]

FYI, .NET Core support is coming, and is almost finished. The new system will support both WebAPI2 and ASP.NET Core.

[JanEggers]

as Odata package has a pre alpha nuget id like to contribute to this package.

Do you have any plans how to support both aspnet and aspnetcore?

id like to split things up in a similar fashon so there will be:

for independent stuff: Swashbuckle.OData.Core

Aspnet: Swashbuckle.OData
depends on Microsoft.AspNet.Odata, Swashbuckle

AspnetCore: Swashbuckle.OData.AspNetCore
depends on Microsoft.AspNetCore.Odata, Swashbuckle.AspNetCore

is that ok / may i submit a pr?

[rbeauchamp]

@KDet @robertmclaws @JanEggers this issue is for people who are asking to become maintainers of this open source project. Just to verify: are any of you asking for this role? If so, please confirm yes, otherwise please submit questions/issues/PR requests via GitHub issues/PRs outside of this issue.

[Tiberriver256]

Something I thought might be worth mentioning. Oasis has been keeping an XSLT up to date for transformation of OData v2-v4 to OpenAPI 2 and 3

https://github.com/oasis-tcs/odata-openapi

It might be worth consolidating efforts on the conversion of one format to the other.

[commonsensesoftware]

Apologies for trolling this hard-working community because there is some good work and ideas going on here, but I would certainly welcome anyone interested contributing, even just ideas, related to OData documentation over at ASP.NET API Verisoning. I've elected to focus purely on mapping OData constructs to the API Explorer by API version and let consumers such as Swagger generators leverage the meta information. This has enabled me to support ASP.NET Web API and ASP.NET Core fairly easily without any dependencies on external libraries. It also makes things neutral so the capabilities can be used by any Swagger generator (ex: Swashbuckle, NSwag, etc) or used in different contexts such discovering and bucketizing APIs by version for test suites.

Some of the more interesting things service authors have started asking for is configuration data that is not even present in the EDM, such as which query operators are allowed, page limits, etc. I've always believed these were important pieces of information that are never easily discoverable by clients. A few ideas have started to roll in and I've put forth some effort into these concepts years ago (before Swagger), but I'd welcome other ideas from the seasoned OData community.

I'm also curious as to what features or capabilities are needed in an API Explorer that I don't have covered with respect to OData. I've had a few people try to mix this library with API Versioning to no avail. I believe that stems from this library expecting authors to setup their routes in ways that only it understands. If there is interest in continuing to maintain this library with more neutrality as to how an author versions their service, I'm willing to reciprocate with input and/or collaboration.