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
