How would you envision that it would work ideally? As in, how would you want to pass in the different configuration per package?

e.g.

<compilerArgs>
    <arg>-AmapstructSpi.enumPostfix=com.company.package1=UNSPECIFIED,com.company.package2=INVALID</arg>
</compilerArgs>

Or something different?

In this case, if we wanted to support non specificity of packages (in the scenarios where all protos need to be treated the same) we might also need to support wildcards...

But my opinion is that your project is more likely than not going to have some sort of consistency (either you are following Google's style guide, or Uber's, or your own) and the need for a multi-configuration is likely unnecessary for the majority of use cases. I know for us it definitely is.

My preference is to merge as is and incrementally add more support for configurability as the need arises. In my honest opinion, an organization/individual service should be consistent with their naming conventions.

I think we should default to Google style and use this new parameter to override this for certain package roots?

I think we should default to Google style and use this new parameter to override this for certain package roots?

So how it's written right now, it will default to the Google style if the param is not passed.

Are you suggesting that the param (if supplied) should only be applied to specific specified package roots? As in, another compiler arg? If so, I was just wondering what use case you are thinking of where one would need two separate postfixes in the same project. Is it a scenario in which one is importing proto messages from multiple sources, where one source might be using the Google style and another source is using some other style?

Updated to allow for package specific enum postfix overrides.

Thanks for your contribution @ro0sterjam !