Skip to content
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

Build fails when anything other than "ORSRoutingFile" set for "routing_name" #424

Closed
rabidllama opened this issue Feb 27, 2019 · 2 comments
Assignees
Labels
awaiting release ⏳ bug 🐞 Erroneous behavior of the backend infrastructure
Milestone

Comments

@rabidllama
Copy link
Contributor

Here's what I did

Setting the routing_name property within the app.config and building ORS


Here's what I got

the build fails with on the unit test testCreateRouteFeatureType in SimpleFeatureTypeTest as it expects always to be named as ORSRoutingFile even when a value has been set in the app.config - it seems that the creation of the feature always accesses the app.config even for running unit tests


Here's what I was expecting

That ors should build when a value is entered in the app.config for routing_name. Also, the name of the property itself is a bit vague, and it seems that when applying the name to the feature, anything after a space is ignored.


Here's what I think could be improved

Either the unit tests should ensure that the app.config is not used for building the object, or the test should be removed as unit tests shouldn't be dependant on external items

@rabidllama rabidllama added bug 🐞 Erroneous behavior of the backend infrastructure labels Feb 27, 2019
@rabidllama rabidllama added this to the 5.1 milestone Mar 4, 2019
MichaelsJP pushed a commit that referenced this issue Mar 26, 2019
@MichaelsJP
Copy link
Member

MichaelsJP commented Mar 26, 2019

@rabidllama It seems like the routing_name variable is a bit redundant. It's not correctly documented in the wiki documentation as it is just called name in there and it seems it was actually never returned. I didn't implement it correctly back then. I would suggest dropping the config variable completely, as we already have attributions in it. And that is basically the "same" if not better suited to brand a result. What you think?

@rabidllama
Copy link
Contributor Author

I believe it was introduced when the gpx output was added as it was some sort of required value in the response

MichaelsJP pushed a commit that referenced this issue Mar 27, 2019
MichaelsJP pushed a commit that referenced this issue Mar 27, 2019
MichaelsJP pushed a commit that referenced this issue Mar 29, 2019
MichaelsJP pushed a commit that referenced this issue Mar 29, 2019
MichaelsJP pushed a commit that referenced this issue Mar 29, 2019
MichaelsJP pushed a commit that referenced this issue Mar 29, 2019
MichaelsJP pushed a commit that referenced this issue Mar 29, 2019
MichaelsJP pushed a commit that referenced this issue Mar 29, 2019
MichaelsJP pushed a commit that referenced this issue Mar 29, 2019
@MichaelsJP MichaelsJP mentioned this issue Mar 29, 2019
12 tasks
MichaelsJP pushed a commit that referenced this issue Apr 1, 2019
MichaelsJP pushed a commit that referenced this issue Apr 1, 2019
rabidllama pushed a commit that referenced this issue Apr 3, 2019
TimMcCauley pushed a commit that referenced this issue May 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting release ⏳ bug 🐞 Erroneous behavior of the backend infrastructure
Projects
None yet
Development

No branches or pull requests

2 participants