Problem with Simple sharing of artifacts between projects

Help/Discuss
1

Hello,
I have altered the multi-project build sample according to https://docs.gradle.org/current/userguide/cross_project_publications.html that is I have added the lines of

  • Example 1. Declaring an outgoing variant
  • Example 2. Attaching an artifact to an outgoing configuration

To the “producer” project’s gradle.build, which is supposed to produce an artifact that is used by the “consumer” project. (:list)

Also, the “producer” project includes the 'java-library' plugin through the file /buildSrc/src/main/groovy/demo.java-library-conventions.gradle

Then I have added

  • Example 4. An explicit configuration dependency

To the gradle.build of the “consumer” project which is supposed to use this jar. (:app)

I understood Example 3 on the same page in that way, that I would have to encode the configuration by much more detail but in this case I don’t actually have to “because”

the Jar task extends AbstractArchiveTask

Consequently I did not put the code under Example 3 anywhere. Also because someTask is only a token symbol for some arbitrary Task implementation.

Sadly trying to build this spawns the error message:

> Could not find method instrumentedClasspath() for arguments [DefaultProjectDependency{dependencyProject='project ':list'', configuration='instrumentedJars'}] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

Thank you,
von Spotz

2

Well, your consuming project does not have a configuration named instrumentedClasspath.
That is just an example.
Use the configuration where you want to have that artifact pulled into or declare a configuration like instrumentedClasspath.

3

Dear Vampire,

thank you very much for your answer.

I have overseen Ex 5 in the tutorial which is the following code for the configuration instrumentedClasspath

Example 5. Declaring a resolvable configuration on the consumer

configurations {
    instrumentedClasspath {
        canBeConsumed = false
        canBeResolved = true
    }
}

But to be honest: I wouldn’t have had any idea myself what the semantics of the configuration should have been having to be. I would have reached out for something like project.classpaths.instrumented or sourceSets.main.instrumentedClasspath if that is even any valid object - but then: what? Add what to that classpath?

What, to begin with, does even the prefix instrumented signify? Could you explain this to me maybe and could you tell me how wrong my approach described in the latter paragraph would have been and why? Ich wäre sehr dankbar!

I really don’t know how to acquire all this knowledge of the “behind the scenes” of Gradle without a point to start. It’s veritable witchcraft :slight_smile:

4

And now it spawns another error

artifacts {
    instrumentedJars(instrumentedJar)
}

So yes, I have yanked the code from the example into the gradle.build of :list but where should it know the symbol instrumentedJar from ?

5

I wouldn’t have had any idea myself what the semantics of the configuration should have been having to be.

A configuration has the semantic you give it.
In that example its semantic is to contain instrumented jars, whatever that might mean.

I would have reached out for something like project.classpaths.instrumented

project.classpaths is not even a thing.
And even if it were, it knows nothing about something called “instrumented” unless you or some plugin tells it so.

or sourceSets.main.instrumentedClasspath if that is even any valid object

Also this is nothing that Gradle would know about, I feels like you are just making up random expressions.

but then: what? Add what to that classpath?

How should I know what you want to add to it?
If you don’t want to add anything, why are you exploring the approach at all?
Obviously you must have some use-case in mind why you try to understand this.
Or if you just want to gather more insight - or also if not -, read the docs a bit more and not just the examples.
Imho the Gradle docs are pretty well written and make things pretty clear usually.

What, to begin with, does even the prefix instrumented signify?

Absolutely nothing, you make this up.
As already said, you are just reading an example, you can name it however you like and however it fits your semantics.
Gradle knows nothing about somthing called “instrumented” unless you or some plugin teaches it so.

It’s veritable witchcraft

It’s neither witchcraft, nor rocket science. And imho the docs are pretty good and explain things pretty well in most cases.

So yes, I have yanked the code from the example into the gradle.build of :list but where should it know the symbol instrumentedJar from ?

It is explained directly after the example:

Here the “artifact” we’re attaching is a task that actually generates a Jar

If you do not have such a task or a plugin that adds it, then it will not know the symbol and fail execution.

6

Again, this chapter is a fictious example of how to provide an auxiliary jar built by some task - in the example instrumentedJar - to another project in the same build properly.
All names are made up and part of the example and you can use any names that match your semantics.