Where should transformer strategies live?

[laidig]

Summary:

Currently, there are transformer strategies in both org.onebusaway.gtfs_transformer.updates and org.onebusaway.gtfs_transformer.impl. This caused me some confusion (as not all transformations are documented), and I wrote a duplicate transform.

Is there a reason why they are split?

I propose that they be all moved together into one of the following org.onebusaway.gtfs_transformer packages:

updates impl (as they implement a strategy) strategies (a new package)

If someone else opines, I'd be happy to refactor this, test, and submit a PR. Expected behavior:

They should be in one package.

[sheldonabrown]

We've been rushing some changes for the latest project, and this repo could use some cleanup in general. Some things that should happen:

1. Document some of the hidden gems, like support for s// and m//
2. Create a plugin convention and pull out some of the agency specific transforms, and start refactoring
3. Investigate, document, and if necessary implement the ability to commit, apply, or flatten the dao from within a transform. Either that or document that multi-part transforms are not recommended
4. General cleanup as suggested above

[sheldonabrown]

I spoke with the rest of my team and they agree with your proposed changes. We are happy to accept any contributions you are willing to make...

[kurtraschke]

Any thoughts on transform strategies that live outside the onebusaway-gtfs-modules tree? Right now I'm just including onebusaway-gtfs-transformer-cli as a dependency and building a shaded JAR whose main class is org.onebusaway.gtfs_transformer.GtfsTransformerMain, so as to avoid having to tinker with the classpath, but that's not a particularly clean solution.

[sheldonabrown]

We've been doing a similar pattern for other modules recently for code not appropriate for the generic/open source repo. So no, no better ideas here so far.