> I don't see the benefit in storing the output of generated code in version > control.
There's no benefit, but there's no downside either. I barely give it a thought during my daily work. Entity removal is probably the only snag, but it is not completely addressed by not having superclasses in VC: you still have to remove you subclass manually. > With the configuration in our gradle build file there is absolutely nothing > to ask new developers to do. Yep. This is why it was recommended by us before it got moved to the Modeler. Now the "Modeler-only" flow is at the same (or arguably higher) level of convenience. > But I'd be equally happy for Modeler and cgen to share the same configuration > somewhere. I don't remember if they can already share the config from the map.xml file. But they definitely should. I expected tools removal to be a controversial proposal. Still decided to throw it out there. I am always looking for opportunities to minimize our support footprint (hi, ROP :)). Properly maintaining the tools across 3 build systems is a non-trivial effort (especially Gradle, due to the rest of Cayenne being built with Maven). Now we've only increased the footprint, as we'd need to be merging map.xml config with build file config. But of course I realize that lots of people have designed their Cayenne workflow around the build tools (and we encouraged it), and will not appreciate them being taken away. FWIW, the switch was very simple for me and my team, but that may be because "cdbimport" was also in use, and going from pom.xml to the Modeler for cdbimport removed so much pain, that it was a no-brainer. "cgen" was just icing on the cake. We are using standard templates and nobody cared about the latter one way or another (and we already had _Xyz.java under version control). Andrus > On Oct 10, 2021, at 11:41 AM, Aristedes Maniatis <a...@ish.com.au.INVALID> > wrote: > > I don't see the benefit in storing the output of generated code in version > control. It makes commit history more noisy and hard to read without any real > benefit. For just this one project, that includes: > > * Cayenne > * Swagger > * Antlr > > So if someone makes a change to the data model of one of those things and > forgets to commit additional files, or there is a lot of boilerplate output > changes because (say) Swagger was updated, then things might get out of sync > and cause oddness in builds. > > Mostly importantly, its really easy to mess up when you remove an entity from > Cayenne and there is no automated process which also removes the relevant > superclass. You may not even notice for a while until something unexpected > happens three months later. > > With the configuration in our gradle build file there is absolutely nothing > to ask new developers to do. But I'd be equally happy for Modeler and cgen to > share the same configuration somewhere. > > > Ari > > > On 10/10/21 6:25pm, Andrus Adamchik wrote: >>> We don't store generated superclasses in version control since that's >>> confusing and redundant. >> I commit generated superclasses to Git everywhere. Never caused any issues >> that I can remember. But yes, I think that would be a prerequisite to >> switching away from cgen in build scripts to the Modeler-based flow. >> >> What I was alluding to is that the XML config below is now managed visually >> in the Modeler and is saved in the XYZ.map.xml, while previously it was only >> saved in the local modeler preferences. So keeping a similar configuration >> in a build script was a superior approach because it was the only way to >> keep the config portable across dev machines. Imagine asking all your team >> members to manually import a custom template and setup their Modeler to use >> it for a specific project. Now this problem is gone. >> >> >> <dbImport xmlns="http://cayenne.apache.org/schema/10/dbimport";> >> <catalog> >> <includeTable> >> <name>ma_.*</name> >> </includeTable> >> <name>media</name> >> </catalog> >> <tableTypes> >> <tableType>TABLE</tableType> >> <tableType>VIEW</tableType> >> </tableTypes> >> <forceDataMapCatalog>false</forceDataMapCatalog> >> <forceDataMapSchema>false</forceDataMapSchema> >> >> <namingStrategy>org.apache.cayenne.dbsync.naming.DefaultObjectNameGenerator</namingStrategy> >> <skipPrimaryKeyLoading>false</skipPrimaryKeyLoading> >> <skipRelationshipsLoading>false</skipRelationshipsLoading> >> <stripFromTableNames>^ma_</stripFromTableNames> >> <useJava7Types>false</useJava7Types> >> <usePrimitives>true</usePrimitives> >> </dbImport> >> <cgen xmlns="http://cayenne.apache.org/schema/10/cgen";> >> <destDir>../../../../../../java</destDir> >> <mode>entity</mode> >> <template>templates/v4_1/subclass.vm</template> >> <superTemplate>templates/v4_1/superclass.vm</superTemplate> >> <outputPattern>*.java</outputPattern> >> <makePairs>true</makePairs> >> <usePkgPath>true</usePkgPath> >> <overwrite>false</overwrite> >> <createPropertyNames>false</createPropertyNames> >> <createPKProperties>false</createPKProperties> >> <client>false</client> >> </cgen> >> >> Andrus >> >> >>> On Oct 10, 2021, at 10:04 AM, Aristedes Maniatis <a...@ish.com.au.INVALID> >>> wrote: >>> >>> >>> >>> On 10/10/21 5:42pm, Andrus Adamchik wrote: >>>> A bit OT... Before 4.1 all my projects used cgen and most - cdbimport. Not >>>> anymore. Things went full circle and Modeler has become the only way to >>>> sync up project with the DB. DataMap XML file now stores all the settings >>>> of the c* tasks. So now I came to realization that putting those same >>>> settings in your build file (Ant/Maven/Gradle) was simply a hack that >>>> allowed to share and version-control task configs. It is not needed >>>> anymore. >>>> >>>> While I'll expect pushback on this:) , may I suggest to deprecate the >>>> tools in 5.0, and remove them in 5.1. >>> 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. >>> >>> >>> Ari >>> >>> >>> [1] https://github.com/ishgroup/oncourse/blob/main/server/build.gradle#L335 >>> [2] >>> https://github.com/ishgroup/oncourse/blob/main/server-api/build.gradle#L62 >
