[windows] Fixed missing output

[devhl-labs]

Fixes #19708
Fixes #19626

Some files were being written using the same path but different case. On Windows, this results in only one file being written. This fixes that and also fixes a bug exposed by the fix where the operation id is not always unique.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh ./bin/configs/*.yaml
  ./bin/utils/export_docs_generators.sh
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[wing328]

thanks for the PR

cc @OpenAPITools/generator-core-team

[wing328]

thanks for fix. let's give it a try

[wing328]

looks like this breaks the use case in which more than one operation having the same name (e.g. getId) and now users will get something different

[devhl-labs]

You can revert it but we will need a sample for the use case this breaks and another pr with this fix that doesn't break that sample.

[devhl-labs]

When you say users get something different, is it wrong, or just different?

[wing328]

I think it's nice addition to prevent spec with duplicated operationId generating code that won't compile. Thanks again for the PR.

Let me think about how to deal with auto fix (opt in or out) and come up with a solution.

Will definitely add samples/tests for to cover this case moving forward.

Thanks again for your work!

[wing328]

When you say users get something different, is it wrong, or just different?

please refer to the discussion in https://openapi-generator.slack.com/archives/CLSB0U0R5/p1728581031429579?thread_ts=1728372817.754659&cid=CLSB0U0R5

[wing328]

please take your time

[OlliL]

I have multiple endpoints in my openapi.json which have the same operationId. This was perfectly fine in 7.8.0 and is also fine "in real life" because they are all below different path. I have for example two GET endpoints

• "/moneyflow/server/monthlysettlement/getAvailableMonth" with operationId "getAvailableMonth"
• "/moneyflow/server/report/getAvailableMonth" also with operationId "getAvailableMonth"

With the JavaSpring generator, I now get interfaces generated with "getAvailableMonth_0" inside the ReportControllerApi and one "getAvailableMonth" in MonthlySettlementControllerApi.

This is just an example - I have multiple endpoints with "create", "delete" and so on operationIds - they now all end up getting generated as create_0 up to create_4 - all in different Controllers.... this really looks like a mess to be honest.

How can I revert back to the old behaviour. There is no point to make this methods unique project-wide when they end up getting generated in different Controller Interfaces (not generating a client, using tags to group endpoints controller-wise). Additionally those numbers don't seem to be predictable so it just ends up with not usable method names (because they may vary in the future I guess). At least tags should be considered to verify if random numbers have to be added or not. It makes no sense to add them for same operationIds in different tags.

• overall openapi.json
• endpoint within monthlysettlement tag
• endpoint within report tag
• Maven Plugin config

[devhl-labs]

Clearly the _0 is a breaking change. The issue for me is that I use the operationId in the name of a class which means it has to be unique. I thought using the operationId would give me a unique value, but that is not true when there are tags. I'll have to explore a different way to handle this.

[OlliL]

On class level you are right (have to be unique). If I understood the initial problem correctly, it was all about Windows filesystem limitations (case insensitive). So maybe the file names have to be unique case-insensitiive wise, but the code inside the files might not. I mean while Windows can't have File1.x and file1.x in parallel, it might have File1.x and file1_0.x but with classes File1 and file1 inside. But - not sure if there are languages out which dictate classname must be equal filename.

And one problem remains imho. The names become inpredictable. What guarantees that "...._0" will be "..._0" in the future and not silently will be generated as "..._2" at one point instead. Maybe just because some dev decides to reorder the openapi spec? Adding iterating numbers seems not right at all imho but maybe I'm missing something 😄

What about taking the tag into consideration?

[devhl-labs]

The _0 part of this pr reverted in a new pr. Thanks for being understanding. #19913