After upgrade to 4.7 (from 4.4) task is no longer found

Help/Discuss
1

Hello !
We’ve just upgraded from gradle 4.4 to 4.7, and a task that used to be run, is now stuck with :

  • What went wrong:
    A problem occurred evaluating project ‘:terracotta-db’.
> Could not get unknown property 'javadocJar' for project ':terracotta-ehcache-client' of type org.gradle.api.Project.

This task is created in a build.gradle file this way :

task javadocJar(type: Jar, dependsOn: javadoc) {
  from javadoc.destinationDir
  classifier = 'javadoc'
}

and is being used in another build.gradle file this way :

  into('client/ehcache/javadoc') {
    from project(':terracotta-ehcache-client').javadocJar
  }

So apparently gradle stopped supporting calling tasks defined in projects (between 4.4 and 4.7), do you have any suggestions how to fix this task ?
Thank you !

2

The second project needs to indicate its evaluation depends on the first one, that will guarantee that the javadocJar task has been defined before you reference it. That is done with evaluationDependsOn to declare a configuration time dependency.

Changes in Gradle most likely caused it to perform the configuration of projects in a different order in 4.7 compared to 4.4.

3

Projects should not reach into each other’s object model. It introduces weird ordering issues. evaluationDependsOn is something I strongly discourage, as it’s just a band aid.

Ideally you should use artifacts and project dependencies instead to properly isolate the projects at configuration time. For this simple case another solution would be referencing the task as a String, which Gradle will evaluate only when needed.

from ':terracotta-ehcache-client:javadocJar'

That being said, there should be no change in this ordering in a minor release. So if you have a reproducible example, please file a bug on github.

Looking at the project names I’d be surprised if this worked before - evaluation is hierachical and alphabetic. In your case terracotta-db would always come before terracotta-ehcache. Are you sure you didn’t change anything else about the project?

4

indeed, that worked to use evaluationDependsOn in the consumer build.gradle - thank you !
now investigating @st_oehme suggestion

5

@st_oehme your suggestion also worked fine, and I’ll probably go with it to keep the build setup clean.

Now, we only changed 4.4 to 4.7 and it broke the build with the messages I pasted in the description
Nothing else.
I’ll try to set up a reproducible test case

Thank you both @st_oehme and @ljacomet , we can now upgrade !

6

so I created a simple project to show you @st_oehme that just changing the version from 4.4 to 4.7 breaks the :

from project(':terracotta-ehcache-client').javadocJar

but of course, in this simple project , https://github.com/anthonydahanne/gradle-4.4-to-4.7 , it does not work, even with 4.4 …
So… meh, I won’t create a bug…

7

Thank you for verifying and happy you have a working setup again :slight_smile:

8

haha ! I talked too fast !

Our windows build failed with :

FAILURE: Build failed with an exception. 
* What went wrong:
Could not normalize path for file 'E:\jenkins\workspace\tc\distribution\kit\:terracotta-ehcache-client:javadocJar'.
The filename, directory name, or volume label syntax is incorrect

I haven’t investigated yet, will let you know if I find something

9

Sorry, my bad. You can’t use a String there since it’ll be interpreted as a file.

The cleanest solution is using a project dependency. I.e. attach the javaDoc jar as an artifact to a configuration in one project and then use a project dependency pointing to that configuration in the downstream project.

producer:

configurations {
  docs
}
artifacts {
  docs javadocJar
}

consumer:

configurations {
  aggregatedDocs
}
dependencies {
  aggregatedDocs project(path: ':producer', configuration: 'docs')
}
docTask {
  from configurations.aggregatedDocs
}
10

thanks again @st_oehme !

Unfortunately, I’m afraid my gradle fu is really too weak for the path you suggested to me !

I reverted back to the working 4.4 / non working 4.7 configuration, and applied your suggestions.

I first got :

Required keys [path] are missing from map {name=terracotta-ehcache-client, configuration=docs}.

Fair enough, let’s use name instead of name then

Project with path 'terracotta-ehcache-client' could not be found in project ':terracotta-db'.

oh ok, let’s try

 aggregatedDocs project(path: 'terracotta-ehcache-client', configuration: 'docs')

Cool, going further :

Could not get unknown property 'javadocJar' for project ':terracotta-ehcache-client' of type org.gradle.api.Project.

Ah ! back to square one ! But now, I have a configuration set, let’s try this :

into('client/ehcache/javadoc') {
 from configurations.aggregatedDocs
}

Now I have :

Could not find method docTask() for arguments  [build_bdz129koya7rsebqxn27xh783$_run_closure10@4dcd0b54] on project ':terracotta-db' of type org.gradle.api.Project.

Probably because docTask should be a task, let’s do this :

task docTask {
  from aggregatedDocs
}

and now :

Could not get unknown property 'aggregatedDocs' for task ':terracotta-db:docTask' of type org.gradle.api.DefaultTask.

and… I’m out of ideas, I definitely need more gradle experience to setup such dependency set up…

Pff… oh well, gradle won over me; I think I’ll go with @ljacomet solution !

THanks again !

11

My suggestion was pseudo code, you need to adjust it to your example. docTask was meant to represent your task that aggregates documentation (you didn’t tell me its name). Just remove that line, since you already adjusted the right one.

Please don’t use evaluationDependsOn :slight_smile:

12

right, and I somehow missed that… Anyway, I just gave it another try, and it seemed to work on my mac (it wasn’t exactly called from a task like the docTask you described, but rather from a definition named distributions > main > contents)
—I’m waiting for my windows build to pass— windows build passed, yay !, but at least, I compared the content of a previous archive built with 4.4 and the new one built with 4.7, they are consistent, javadoc-wise at least !

1 Like