Closed apryamostanov closed 5 years ago
So this is an issue... The way I get the conventions.groovy currently, is by going after the sourceUnits target directory, doing a split on ''build" to get the source directory, where presumably the conventions.groovy should be. This works with a normal gradle build, but it seems like from what you're saying, travis is redirecting that build directory outside of the source directory.
I'm not sure what the solution is either, as adding a gradle parameter, won't work, because the AST transform has no knowledge of gradle. A resource won't work because it's also not available at compile time, I tried that. I was thinking about using a system property, but my the nature of gradle that is locked out for certain tasks, like assemble. At the moment I'm out of ideas to try, I may post a question on slack, but I have to figure out what the right question to ask is, and then hope someone answers it, which I would say is hit or miss, but with AST questions, it seems much more miss that hit...
So with the current changes for RC3 this issue might go away, but it would mean that Travis might not be doing static compilation...
Issue still present with RC3: https://travis-ci.com/INFINITE-TECHNOLOGY/SUPPLIES/builds/100773632
Figured a way around this, by using a custom compiler script I can set system properties, so that my AST transform, can access them.
This should be fixed in RC4 as I'm not using the directory as a way to get at the config.
Hi @virtualdogbert,
Please kindly take a look at Sample broken Travis CI build.
The local build runs OK using Gradle, however on Travis CI it fails.
After having a quick look - it seems that Travis is creating build in "/home/travis/build/" and EnterpriseGroovyASTTransformation.groovy is not scanning this dir for "conventions.groovy".
Not sure what is the best solution here - to add Enterprise plugin parameter in build.gradle to make 1 more configurable path or other solution (e.g. making conventions.groovy a resource file).
Note: I fixed the build by explicitly adding
@CompileDynamic
annotation to the failing class, so this is not an urgent issue.