-
Notifications
You must be signed in to change notification settings - Fork 130
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
Remove default tags from global level #525
Remove default tags from global level #525
Conversation
ea7dc2e
to
a4fa974
Compare
I had to add a couple of dependencies in order to run tests. I'm not sure how the existing CI is passing. I could use some pointers on how to investigate this. |
@kailuowang |
|
||
val tagsJson = mergeByName(generatedTagsJson, (baseJson \ "tags").asOpt[JsArray].getOrElse(JsArray())) | ||
|
||
val tagsJson = (baseJson \ "tags").asOpt[JsArray].getOrElse(JsArray()) |
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.
It has been a long time since I looked at this code base. It is unclear to me how this change can retain the tags generated from file paths? The test was also changed. The code is generating new set of tags now?
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.
We don't want to retain tags generated from file paths because we don't need them. Please check our chat on this thread.
The code is not generating new tags. The previous was only testing if a small subset of tags was present in the output file. I made that set exhaustive.
Sorry, I pretty much forgot about the code as well. I think the expected behavior is that the code generates a tag for each route from the path name of the route file in which the route is defined. That means that routes defined in the root route file will have a pretty useless tag of the root file path. It will be ideal to remove this tag for the root file but retain the tags for routes in referenced routes files. |
@kailuowang I raised another pr a few years back and lost track of it. It got auto-closed due to no activity. You can check it for reference. |
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.
It looks fine to me. But I'll leave the final decision to @Javakky-pxv
It's still a breaking change, we might want to make it loud in the release note and bump up the minor version number
@kailuowang By the way, do you have a roadmap for ver 1.0.0? Or is it already substantially 1.0.0? |
Imo, it should've been 1.0 by now. I don't have a roadmap. I stopped using
swagger or play long time ago, and thus not a stakeholder of this lib. I
don't think I have anything to say in regards to it's features or roadmap.
One thing you might want to consider is a roadmap to scala 3. A big portion
of reflection based code might needs to be rewritten.
…On Tue, Mar 7, 2023, 12:19 AM Kazuma Iemura ***@***.***> wrote:
@kailuowang <https://github.com/kailuowang>
I am in favor of this change.
It is a BREAKING CHANGE, but I am not sure if this is a milestone for ver
1.0.0, and I am considering releasing it as 0.14.0 and advertising it in
the CHANGE LOG.
By the way, do you have a roadmap for ver 1.0.0? Or is it already
substantially 1.0.0?
—
Reply to this email directly, view it on GitHub
<#525 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUKOMH3P3SWG7UJGP45X3W23AO7ANCNFSM6AAAAAATNSKTJY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@kchaitanya1195 @kailuowang Support for Scala 3 is an important change, but I will take the plunge and move up to 2.0.0 if there are major changes at that time. |
Removing code for generating global tags object (#70 ).
Also added an extra test to make sure that a "routes" tag is not added when a default routes file is used.
cc: @kailuowang