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?

[CaylaSavitzky]

@leonardehrenfried
I'm so sorry for the delay, I was offline for a few weeks, and then had to do some searching to find an answer. Either CS has not historically published to Maven Central, or it was long enough ago no one in our current team remembers a time when we did.
That said, after some internal discussion, we'd be happy to publish outside of the camsys repository, or can maintain a fork if this decision is already made.

[leonardehrenfried]

Hi @CaylaSavitzky!

If the dependency is on Maven Central I can very easily revert this PR. Thanks!

[leonardehrenfried]

And while you're deploying to Maven Central, can you do the same for the following artifacts:

• org.onebusaway:onebusaway-cloud-api:jar:0.0.13
• org.onebusaway:onebusaway-cloud-noop:jar:0.0.13

I don't really understand what they do but I guess they are for some cloud integrations that Camsys uses.

[CaylaSavitzky]

@leonardehrenfried
I believe those are two lightweight supports for oba to easily reach a generic cloud service, and, one of which is used more in gtfs-modules, and the other used more in application modules.
Yes we can definitely publish both