transformer: Remove library com.kurtraschke:wsf-api and WSF block resolution strategy

[leonardehrenfried]

The artifact com.kurtraschke:wsf-api is not deployed to Maven Central and apparently only available from camsys-apps.com. I also cannot find the source code of this library.

Since I would like to include only libraries that are available on Maven Central, I'm going to remove this library and the WSFBlockResolutionStrategy. I tested the the URLs in this class and only get 404s.

@sdjacobs You originally added this strategy. Can you shed some light on whether it's still used and if the WSF API is still working?

@kurtraschke Do you know where the source code is and can you deploy it to Maven Central?

Closes #282

[sdjacobs]

I don't know if anyone is using this; I'm not personally. The WSF API does appear to work still if you create an API key as indicated here: https://www.wsdot.wa.gov/ferries/api/schedule/documentation/rest.html

[leonardehrenfried]

@sberkley Do you know anything about this topic? Are you using this?

[kurtraschke]

@kurtraschke Do you know where the source code is and can you deploy it to Maven Central?

The current code lives in a fork which belongs to Cambridge Systematics (https://github.com/camsys/wsf-gtfsrealtime), although there had been discussion (kurtraschke/wsf-gtfsrealtime#2) of transferring the project to them outright.

I have no idea how it became a dependency ofonebusaway-gtfs-modules; presumably some new transformer?

(Ah, it seems to be WSFBlockResolutionStrategy, which appears to use schedule data from the WSF API to enrich the WSF static GTFS with block IDs?)

Many years ago I had discussed with some folks at CS the idea that agency-specific transforms should live in their own modules, and then onebusaway-gtfs-transformer-cli could take a command-line parameter to add user-specified JARs to a ClassLoader used for resolving transformers. This would appear to be an ideal use case for such a strategy; personally I don't think it makes much sense to drag in dependencies that are only relevant to one agency for all downstream users of the library. (In fairness, I recognize it was the convenient, expedient thing to do at the time, and I understand how we got to where we are today, but that shouldn't stand in the way of making things better now.)

[leonardehrenfried]

Thanks for chiming in @kurtraschke. I am, by the way, the new maintainer of this project.

I don't really have a problem with extra dependencies, even those only used by a single transform, since I see the transformer module as a place where you can put all the stuff you don't want to do downstream.

And file size is also not an issue since the combined jar is just 5MB - nothing by today's standards.

What I am trying to clear out of this repo is dependencies that cannot be found on Maven Central.

[aaronbrethorst]

@kurtraschke @leonardehrenfried fwiw, I think that both approaches could be reconciled in a single project: a plugin architecture allows downstream users to build their own transformers without needing to wait for them to be accepted into the project, experiment with new approaches, etc. Vetted transformers can be pulled in as need/opportunity arise.

[sberkley]

The Puget Sound OBA instance that CS maintains for Sound Transit does still need the WSF transformer. That said, I agree that this project shouldn't have dependancies that aren't available in Maven Central. I've raised the issue with CS. @CaylaSavitzky is our main dev contact these days. I don't think it would be too bad if we (CS & ST) needed to include this via a fork or plugin.

[leonardehrenfried]

I would be fine with even very agency-specific code to remain in this repo so no need for a fork. A Maven Central deployment is all I want.

[leonardehrenfried]

@sberkley @CaylaSavitzky Are there any news about a Maven Central deployment?