-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Onebusaway nyc app mods merge #2
Conversation
@@ -3,7 +3,7 @@ | |||
<parent> | |||
<groupId>org.onebusaway</groupId> | |||
<artifactId>onebusaway-application-modules</artifactId> | |||
<version>1.0.2-SNAPSHOT</version> | |||
<version>2.0.19-SNAPSHOT</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the first thing we need to figure out is versioning. Even if we can find a common version number to agree to, are we just going to get out of sync again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe--I can go either way on this... it wasn't necessarily my idea to change the numbers in the first place... your call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are you thoughts about switching back to the current OBA version numbers? Does that conflict with any of your existing releases? Have any of those release artifacts been put in any public repos?
In the same vein, do you think you're going to need to continue to make versioned releases independent of the main codebase? We can definitely talk about giving you release privileges on the main codebase, especially once we've got things in sync, if that will help. If you do need to make versioned releases independent of the main codebase, I'd probably talk about how we can do that without causing release conflicts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we'll use yours. You can ignore the version changes in these patches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any chance you could exclude the version changes from the pull request entirely?
Onebusaway nyc app mods merge
Okay, Brian, please re-review--changes made. Thanks! |
Conflicts: onebusaway-webapp/pom.xml pom.xml
Brian--changes you requested have been made. Please merge, do a release, and then let us know what the new released version number is. Then please close this pull request when you're done-- Also happy to have the service alerts conversation, but would prefer to make that a conversation separate from this merge request if we can... Thanks-- -Jeff |
Onebusaway nyc app mods merge
Cleanup: remove real-time trip planning, other dead code, etc.
Okay, for real this time--patches are in the referenced commits. Let's discuss how to handle version numbering, and also whether the few hacks I had to make to get GWT working are needed; maybe you've already fixed? Might also need to do a release on the GTFS and CSV modules--not 100% sure it was required, but seemed like it was--they're in our own private mvn repo now, but should be public.
But otherwise, should be a set of fairly clean, straightforward changes that shouldn't change anything for anybody else--or that's the hope at least... let's discuss...
Just like before, pasting in the original list E-mail below:
Hello OBA-ers,
Brian--this is mostly directed to you: I'm writing to submit a series
of smallish patches we made as part of OBA's integration with MTA Bus
Time to OBA trunk, hopefully to eventually merge these two codebases
back together. Patch is attached. I'm also happy to commit these if I
receive the go-ahead, otherwise feel free to merge them yourself.
Rough summary of patch contents are:
ServiceAlertsServiceImplTest: unit test for service alert changes
RoutesBeanServiceImpl: change to eliminate internal cached data
structures in favor of a "cacheable" method that does the same;
queryBean configurable minimum lucene score to keep
VehicleStatusBeanServiceImpl: informative debugging message only
RefreshableResources: new refreshable resource key for
WhereGeospatialServiceImpl
SiriService: change to enable unit testing
VehicleStatusServiceImpl: change to reset block state in
BlockVehicleLocationService if a record is received by the
VehicleStatusServiceImpl that has no trip/block assigned to it (e.g.
inference drops out) for the same vehicle ID
WhereGeospatialServiceImpl: made "refreshable", plus informative debug message
ServiceAlertsServiceImpl: switch to turn bundle persistence of service
alerts on/off; new time parameter to getServiceAlertIdsAsObject
BlockStatusServiceImpl: enlargement of search window for block list
that backs getBlocksForRoute(), to better handle vehicles assigned to
"late" trips (that weren't within the previously super tight bound
(instant?) specified as "time").
BlockGeospatialServiceImpl: change made to, when "refreshed", clear
the blockSequenceIndices so the old ones are not left in the internal
cache state.
SearchQueryBean: moved minimum lucene score to keep to this bean so
that it is configurable per query by the developer.