#100 Sort tags

[magx2]

I've added sorting tags to get more predictable results for generating JSON/YML.

see https://github.com/kbuntrock/openapi-maven-plugin/issues/100

[kbuntrock]

Hello, thank you for your contribution, I appreciate it (first external one 🥳 )

I have a bunch of remarks about it tho' :

• sorting should not be done in getters since it is triggered sometimes for nothing. Like for example when we just want to log the size of the list to print how many tags we have documented. I suggest to create dedicated functions like "getSortedTags" and "getSortedEnpoints". And then use them only when appropriate.
• 6 unit tests fails. 2 because the expected result is different (normally just the expected test result should be adapted), and 4 because there is a NullPointer exception (java.lang.NullPointerException: Cannot invoke "java.lang.Comparable.compareTo(Object)" because the return value of "java.util.function.Function.apply(Object)" is null) Good news is : I was feared of much more tests to adapt. :)
• Endpoint comparison : path should be compared before endpoint type. To regroup any operation on the same url. I guess computed name and name can be discarded from comparison since path+type should be unique.
• Tag comparison : to remove any possibility of comparison difference between linux and windows, I suggest to ignore whitespaces during comparison of computed names.

And finally, I'm trying to test anything I'm adding to this project in order to limit as much as possible any possible regression when improving this plugin. That's why I would like a unit test about this ordering process.

Thank you by advance!

Kind regards, Kevin

[magx2]

6 unit tests fails.

ah, you do not have github actions configured?

[magx2]

Tag comparison : to remove any possibility of comparison difference between linux and windows, I suggest to ignore whitespaces during comparison of computed names.

why white spaces? Did you mean case?

[magx2]

sorting should not be done in getters

I've change List to SortedSet

[magx2]

Why it's failing on ci/cd, but when I'm running locally mvn clean install it does not fail?

[kbuntrock]

ah, you do not have github actions configured?

It was not configured for PR coming from forks. But I changed the configuration and it seems to work with your PR now.

why white spaces? Did you mean case?

No, I meant white spaces. Sometimes linux and windows string comparison defer if they rely on the OS default "collation" (spaces count by default on one and not on the other). But the java implementation seems consistent, let's put away this suggestion and not complicate the code.

Why it's failing on ci/cd, but when I'm running locally mvn clean install it does not fail?

Weird, it fails also for me in local. Are you sure you don't deactivate tests with a maven option?

[magx2]

Weird, it fails also for me in local. Are you sure you don't deactivate tests with a maven option?

Have you done git pull?

[magx2]

nvm, I had turned test off in IntelliJ (when I was debugging previous bug I've turned it off)

[magx2]

Ready 🚀!

[magx2]

Do we have anything pending here?

[magx2]

LGTM!

[magx2]

Ready to merge?

[kbuntrock]

A few things annoys me with this one

Ready to merge?

Back on it. I remind having an issue with it but it seems I have not write it down. Re-reading this PR.

[kbuntrock]

Got the time yesterday to retrieve what was bothering me : In case of a name collision of the simple class name, using a Set will erase randomly some tags. A similar issue can be found with Enpoints having path collisions.

Even if we will probably generate an invalid documentation, we cannot hide the problem under the carpet (french expression :P)

Since I was on it, I took the liberty to derive from your branch to add my modifications : #109 I also "manually" set the order for operation types as described in #100

I let you review my modifications and if it please you, I'll merge this on Tuesday evening.

[magx2]

OK, added few comments