Conversation
Yes, that's breaking. In theory, we could add |
The class has default visibility, so it's not a public build item in any way, shape or form. It seems to me that we could really use a "context accessor" here instead of a The PR looks good, but I only took a very brief look and didn't review properly. I'll take a proper look next week. |
Right, I totally missed that, thanks for pointing it out 🤦
This is IMO making it even worse. The idea of these properties is to be case sensitive and this way we'd add arguably useless option while still keeping the behavior broken. If you just wish to make it explicit and keep as-is, we can easily document it in the Personally, I'd point it out as potentially breaking but still change it. To me, it is clearly an oversight. |
Well, that might be obvious for users who work with case sensitive systems 🤷. |
Status for workflow
|
Fixes #53757
There are two commits.
First one adds the regex functionality. In order to avoid computing the regex repeatedly, I have added a static field into the generated bean. This however required me to change
SuppressConditionGeneratorBuildItemto gain access to theClassCreator. I am not sure if that's acceptable given it's theoretically a "public" build item.Second commit fixes an inconsistency we already had in code regarding case-sensitivity.
For build-time properties, we were using case-insensitive approach (code) whereas runtime was using case sensitive (code).
I believe this was an oversight although it is theoretically breaking 🤷