i’ve a little Groovy problem with custom datasources.
When i create a groovy file that contains a custom datasource, it can’t compile because of the following error:
/home/mario/dev/projects/examples/cuba/problems/cuba-problem-groovy-custom-datasource/modules/web/src/com/company/cpgcd/web/customer/CustomerCustomGroovyDatasource.groovy: -1: Abstract method 'groovy.lang.MetaClass getMetaClass()' is not implemented but a method of the same name but different return type is defined: method 'com.haulmont.chile.core.model.MetaClass getMetaClass()'
@ line -1, column -1.
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app-web:compileGroovy'.
> Compilation failed; see the compiler error output for details.
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
I’d assume that there is a name collision between groovy.lang.MetaClass and com.haulmont.chile.core.model.MetaClass - right?
Perhaps you can take a look at it (atached you’ll find the example project).
thanks for the reply. You mean besides the idea of renaming one of the most important classes of the platform? - no, i don’t
In fact, i asked about the situation in the groovy slack channel and got a response from Jochen Theodorou who quite knows pretty much everything about groovy. The bottom line was: You can’t
So, that’s a pity. I would suggest we forget about the problem and stick to the solution with java classes…
One could argue the MetaClass is a little too broad name anyway, but i don’t think changing a name of this class would not be a very smart move, especially as it seems that i’m quite alone with using groovy…
Thanks for the investigation. We’ll consider renaming the getMetaClass() method in datasources in one of the future releases. It should be enough for using Groovy for writing custom datasources. Let us know if you face similar problems in other parts.
indeed i found that for entites the same problem exists (see Instance.java).
This is also a little bit annoying, because i oftentimes want to do subclass-and-override in a unit test for a entity because there is no dependency injection available. This does not work with a groovy subclass.
Additionally, one can’t just create Mock instances of an Entity with something like spock etc.
Also the actual entity can’t be groovy, which is quite verbose too in case i have transient properties where the getter is a calculation etc.