But the moment I uncomment the project { }, I get:
Caused by: org.gradle.api.internal.MissingMethodException: Could not find method pom() for arguments [build_4vy411cu6b99sjp1dveviwcg0$_run_closure3_closure41_closure46@5e9de4cf] on task ':mycompany-myproject:writeNewPom'.
at org.gradle.api.internal.AbstractDynamicObject.methodMissingException(AbstractDynamicObject.java:68)
at org.gradle.api.internal.AbstractDynamicObject.invokeMethod(AbstractDynamicObject.java:56)
at org.gradle.api.internal.CompositeDynamicObject.invokeMethod(CompositeDynamicObject.java:172)
at org.gradle.api.DefaultTask_Decorated.invokeMethod(Unknown Source)
at build_4vy411cu6b99sjp1dveviwcg0$_run_closure3_closure41.doCall(/home/shevek/java/compilerworks/build.gradle:127)
at org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:548)
at org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:529)
at org.gradle.api.internal.tasks.TaskMutator$1.execute(TaskMutator.java:77)
at org.gradle.api.internal.tasks.TaskMutator$1.execute(TaskMutator.java:73)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61)
Possibly useful differences between my standalone test project and this real one:
Test project has only the root project. Real project has the above code in a subprojects {} block.
JDK is Azul Zulu 8.6.0.1
I don’t even know what else to write, I’m totally foxed by this. Surely { println } is a closure just as { project { } } is, so if one works, the other should. It’s complaining about pom(Closure) not project anyway.
This is likely due to the fact the Maven plugin hasn’t been applied when you are attempting to call pom(). I would add the following to the subprojects { } block.
I was only able to replicate this issue if you define a named argument for the subprojects { } closure named project. If you are doing so either rename the argument or remove it.
@mark_vieira Removing the project -> has introduced a new issue: Now the pom has no dependencies in it.
It feels as if the pom is generated with respect to the root project, even though it’s in a subprojects{} scope. The group id is missing, and the project name in the generated pom is still my root project name.
A few printlns shows me that while ‘project’ has the subproject value, it seems that ‘this’ references the root project.
No luck yet. Of course I’ve constructed a minimal test case, and that passes, whereas my main project fails, and I’m playing spot-the-difference. all my printlns print equivalent things in both systems, though. What else can I print to help me figure this out?