You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2022/11/25 10:27:33 UTC
[DISCUSS] Check in generated Java code?
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
Re: [DISCUSS] Check in generated Java code?
Posted by Christofer Dutz <ch...@c-ware.de>.
It actually IS very helpful to see what changes in the code generation produce in differences in the output.
It has saved me multiple times in other languages before.
Chris
From: Ben Hutcheson <be...@gmail.com>
Date: Friday, 25. November 2022 at 21:45
To: dev@plc4x.apache.org <de...@plc4x.apache.org>
Subject: Re: [DISCUSS] Check in generated Java code?
+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 <lu...@code-house.org> 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
> >
>
Re: [DISCUSS] Check in generated Java code?
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <lu...@code-house.org>
Date: Saturday, 26. November 2022 at 00:11
To: dev@plc4x.apache.org <de...@plc4x.apache.org>
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 <lu...@code-house.org> 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
>>>
>>
>
Re: [DISCUSS] Check in generated Java code?
Posted by Łukasz Dywicki <lu...@code-house.org>.
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 <lu...@code-house.org> 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
>>>
>>
>
Re: [DISCUSS] Check in generated Java code?
Posted by Ben Hutcheson <be...@gmail.com>.
+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 <lu...@code-house.org> 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
> >
>
Re: [DISCUSS] Check in generated Java code?
Posted by Łukasz Dywicki <lu...@code-house.org>.
-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
>
Re: [DISCUSS] Check in generated Java code?
Posted by Lukas Ott <ot...@gmail.com>.
+1 as this simplifies for users
Am Fr., 25. Nov. 2022 um 11:27 Uhr schrieb Christofer Dutz <
christofer.dutz@c-ware.de>:
> 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
>