I have an internal grails plugin that has some tes...
# questionsu
user
09/22/2025, 2:16 PMI have an internal grails plugin that has some tests that require domain entities. These domain entities are only required to test the plugin code and are not useful to the main project.
Is there a way to configure either (a) move test-domain entities out of grails-app/domain and later promote them to domain object when under test environment - or (b) suppress these from being dragged into the main project somehow? Thx
j
jdaugherty
09/22/2025, 2:17 PMwhy not create a gradle project with just the test dependencies that uses your plugin?
u
user
09/22/2025, 2:19 PMThat's what I'm having to do... I'm aiming for
myapp.myplugin-supportmyapp.myplugin-support-testj
jdaugherty
09/22/2025, 2:20 PMUsually you want different test scenarios, you can easily configure a plugin to not export ocnfiguration, but when it comes to compiled code, a gradle project is that division
jdaugherty
09/22/2025, 2:20 PMyou can technically put testImplementation <your gradle project with domains>, but usually you want to test a plugin like other users would
jdaugherty
09/22/2025, 2:21 PMA lot of the "best" plugin practices are seen in this project: https://github.com/longwa/build-test-data
jdaugherty
09/22/2025, 2:21 PMwhere the plugin is defined as it's own gradle project
jdaugherty
09/22/2025, 2:21 PMand then there's an examples directory with projects that test the plugin
u
user
09/22/2025, 2:21 PMThank you @jdaugherty very helpful info
j
jdaugherty
09/22/2025, 2:22 PMI have a todo in my backlog to write a section in the grails doc for best plugin practices
jdaugherty
09/22/2025, 2:22 PMbut i haven't gotten around to it yet
jdaugherty
09/22/2025, 2:22 PMbut you can see grails-core, grails-spring-security, & grails-redis have all adopted this strategy
jdaugherty
09/22/2025, 2:22 PMjdaugherty
09/22/2025, 2:23 PMGrails web console is another example: https://github.com/grails-plugins/grails-web-console
u
user
09/22/2025, 2:23 PMMy client doesn't have any artefact distribution so everything is in-tree. Was attempting ot cut down a bit of noise.
j
jdaugherty
09/22/2025, 2:23 PMyou don't need to distribute the test examples, in fact you probably never want to
jdaugherty
09/22/2025, 2:23 PMthe multiproject gradle build is how best to model that
jdaugherty
09/22/2025, 2:23 PMall of those links have a plugin / examples directory
u
user
09/22/2025, 2:25 PMIndeed - it's because of the lack of artifact distribution that everytihng is in tree, one subproject for the plugin but now another subproject just to test the plugin. (with the adjacent apps depending on the plugin alone)
j
jdaugherty
09/22/2025, 2:26 PMhere's the thing people don't consider, having a single app split into several gradle projects will greatly reduce the compilation time / time to development. The groovy incremental compiler isn't the best, but gradle is amazing at caching and only running when code changes. So by having a multiproject build, you can actually save development time.
jdaugherty
09/22/2025, 2:26 PMbut that does require you following gradle project best practices - don't use eager registration, etc
u
user
09/22/2025, 2:27 PM😎 thanks again for your help
👍 1