On Sun, Oct 10, 2021 at 3:04 AM Aristedes Maniatis <a...@ish.com.au.invalid> wrote:
> Can you explain a bit more? We don't store generated superclasses in > version control since that's confusing and redundant. [1] This is > similar to how we don't store swagger generated classes in version > control for the server side API implementation. > Hi Ari and Andrus, While I'm generally a proponent of "don't commit generated artifacts," I'm also a proponent of "write code to be read, not written." I often browse code through GitHub or BitBucket and if I were browsing a Cayenne project WITHOUT the superclasses checked in, I'd probably be grumbling "WTF is the code?!?!?!" [1] There are also many times I've sent people a GH or BB link to code to look at, including the superclasses. I wouldn't want to have to checkout and build before I could browse the code, which could involve a lot of steps for some of the projects I've seen or worked on. Likewise, I wouldn't want to tell someone else they have to checkout and build the code to see the superclasses. Also, with the superclass checked in, you have a point-in-time view of the actual code which was used to build the project. With changes to Cayenne Modeler and code generation possible from one version to another, if you have to checkout a previous version and build it with a newer (or perhaps even older) version of Cayenne to see the superclasses, you may not be seeing the same superclasses as originally intended. I guess I feel it is important to check in the generated classes for readability and historical purposes. Also used cgen quite a bit to generate the classes instead of using Cayenne Modeler to do so since it made dealing with custom templates easier. If someone generated the "incorrect" classes from the default templates, cgen would fix that mistake for them when they built the project (happened frequently enough that I made it part of the build process). [1] This might be even more important if you use custom templates for a project. Thanks, mrg
