On 11/10/21 2:56am, Michael Gentry wrote:
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).
This isn't true when deleting or renaming an entity in the model. It is
really important to me that this kind of mistake causes a compilation
error. Multiply this problem out by antlr, swagger and cayenne entities
and I'm very happy with our design choice to keep generated code out of VCS.
This isn't hypothetical. Years ago we had a real problem that took days
to solve; additional entities in our classpath caused a subtle problem
in places you'd not expect. Almost lost a customer over it, so I've
little interest in going back there.
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'm pretty happy with our use of gradle to lock dependencies to a
reproducible version. We even use gradle to lock in the version of node
which compiles our typescript. And our DSL documentation is generated
live [1], parsing the code without having to remember to commit the
generated docs.
Anyhow, each to their own. Some people might like to commit js files
compiled from typescript so they can search on what is running in
production without compiling. For us, the opposite approach has worked well.
Cheers
Ari
[1]
https://github.com/ishgroup/oncourse/blob/main/buildSrc/apidoc/src/main/groovy/au/com/ish/docs/DslGroovyRootDocBuilder.groovy
