Besides generating the java classes, we use cgen to generate source code for other languages and other artifacts, using different configuration. So while I would be in favor of removing the duplication of the configuration for java class generation, I would still like to have the cgen task remain available to use for other purposes.
On Sun, Oct 10, 2021 at 2:26 AM Andrus Adamchik <aadamc...@gmail.com> 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 > >
