Re: cgen into the future

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 <[email protected]> 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 <[email protected]>
> 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
>
>