Having generated sources checked in will lead to unclear situations where we might not know which sources are being used with library - the checked ones or newly generated from target directory. We often refer people to try snapshot or local build when they have problems, which guarantees they will see same results as we. How will we keep checked sources up to date if generation template was changed, how often we will update it? How we will prevent PRs with changes to code we wish to generate? (there are bots which submit PRs because of certain imports in Java code found) Who is responsible for that and how we can assure that we do not have partial failures? Sorry, but checking-in generated sources creates more troubles for little benefit. The github diff is great, but feature Ben linked is about *excluding* generated sources from PR diffs, which effectively force to manually navigate and check each file, and these changesets are going to be huge. BACnet mspec is creating hundreds of files, making them appear only in the list of files included in commits attached to PR will make submitter, reviewer and our browsers suffer a lot.
If we go into path where we must check in sources of each and every language this library supports it will be better if we will separate generated sources from main repository in first place.
[1] https://github.com/GraxCode/cafecompare Best, Łukasz On 25.11.2022 21:43, Ben Hutcheson wrote:
+1 I like the idea of keeping a history of what has changed. This may help? https://medium.com/@clarkbw/managing-generated-files-in-github-1f1989c09dfd On Fri, Nov 25, 2022 at 9:03 AM Łukasz Dywicki <[email protected]> wrote:-1 from my side I don't think its a good idea, generated code currently changes far too often to make sense of it and its history. We rather track code for generators and templates which produce it. As long as language is fine with automatically generated sources, I opt for not polluting our SCM with millions of LOCs which bring no real value. Letting people checkout and play is fine, but lets face truth, people who would like to do quick start have to install some kind of maven tooling which will generate code for them anyway. If interested party is not using any IDE, it will still need a command line tool to compile sources. Best, Łukasz On 25.11.2022 11:27, Christofer Dutz wrote:Hi all, I know it’s sort of considered bad practice to check in generated code,when you’re working with maven.However, we’ve already started to check-in generated code for all otherlanguages.Especially today when working on the Time and Date stuff I really havelearned to appreciate to see what changed, when working on code-generation.I would like to propose to also start checking in the generatedjava-code.But I would like to generate it into a separate directory and use thebuild-helper-plugin in order to keep things separate (This way we can simply delete the directory, run the build and we get rid of obsolete types)I would propose to generate code into a “src/main/generated” directory. The upside would be: Everyone can simply check out plc4x and use it inany IDE without having to build first.What do you folks think? Chris
