So even if I Sebastian didn’t participate in this discussion, I know he is totally +1 on this.
So, I count 3 +1 (not counting Sebastian) and 1 -1. Regarding your doubts … for the output there is absolutely no difference for the resulting jar what base directory the files were in. IntelliJ will continue to mark the files as Generated as it’s awesome and we put the “Generated code” headers in place of all files. All the problems you describe sort of feel like they aren’t really issues and I can’t see how they will be problematic. I guess I’ll give it a try and if it sucks, we can always go back to how it was before. Chris From: Łukasz Dywicki <[email protected]> Date: Saturday, 26. November 2022 at 00:11 To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Check in generated Java code? Maven have "sources.jar" files which serve purpose of retaining all sources, not only generated ones. I would rather look for tool such https://abi-laboratory.pro/ which can interact with these than opening a pandora box or stick with cafecompare [1]. 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 other >> languages. >>> Especially today when working on the Time and Date stuff I really have >> learned to appreciate to see what changed, when working on code-generation. >>> >>> I would like to propose to also start checking in the generated >> java-code. >>> >>> But I would like to generate it into a separate directory and use the >> build-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 in >> any IDE without having to build first. >>> >>> What do you folks think? >>> >>> >>> Chris >>> >> >
