https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
a
the test project is set up here https://github.com/adamko-dev/dev-publish-plugin/blob/56c7b8b4256fb5b1354acd4c52383c6cf16c9f2b/src/test/kotlin/MultiProjectTest.kt In the first test case :project-aggregate-some subproject explicitly depends on three subprojects • :project-kotlin-jvm1 has my plugin applied • :project-kotlin-jvm2 has my plugin applied • :project-kotlin-jvm-no-dev-publish does not has my plugin applied, and should be filtered out during aggregation, but apparently Gradle thinks the source files should be included??? I'd expect that the artifactView filters out :project-kotlin-jvm-no-dev-publish, but it doesn't. Even if it doesn't, trying to filter it out using ResolvedArtifactResult attributes results in an empty aggregate.
In the second case :project-aggregate-all blindly depends on all other subprojects using:
Copy code
dependencies {
  //devPublication(allprojects.filter { it.path != project.path })
  rootProject.allprojects.filter { it.path != path }.forEach {
    println(project.path + " is depending on " + it.path)
    devPublication(it)
  }
}
And now somehow it now duplicates a single class?? 
Execution failed for task... Entry KotlinNoDevPublishClass.kt is a duplicate
Seriously wtf. There's only one file.
a
Not a variant selection expert, but does it work if you use 
withVariantReselection()
? E.g. something like:
Copy code
conf.incoming
          .artifactView {
              withVariantReselection()
              attributes...
           }...
a
thanks, I did forget to try that, but I don't see any change unfortunately
v
If you look at the 
:project-kotlin-jvm-no-dev-publish:outgoingVariants
output, you should see the problem.
On the variant 
mainSourceElements
there is no usage attribute. So it is a candidate for when you request any usage.
And in your case that variant was the best match according to the documented algorithm and thus was selected
If you for example set and request a category too, you become fine
a
the attributes in the other project shouldn't matter, if I select 
withVariantReselection()
then it says it only considers the attributes in the artifactView
v
So?
You request only usage. Usage is absent. Absent is compatible by definition.
a
so it shouldn't consider the attributes in the other project
v
How should it not consider those? o_O
The attributes in the dependencies are matched against the attributes in the configuration and / or artifact view
a
that's what the docs says
or it's another bug]
v
They do not and it is not
They say that for variant reselection the attributes on the configuration on which you do the artifact view are ignored
But how should any attribute selection work if the attributes of the dependencies would not be considered
That is what the requested attributes are compared against
a
either way - I can't control what attributes the other project sets so setting all possible attributes doesn't sound feasible
v
Of course you cannot control, and you don't have to. You just have to fit into the ecosystem
a
I'm not sure, ask the Gradle docs 🤷
v
And that in your case means, you should also use the category
What should I ask the Gradle docs?
Why you read something out of them they don't say?
a
But how should any attribute selection work if the attributes of the dependencies would not be considered
v
That is not a question for the Gradle docs, as they don't state something like that
That's a question for you, so you can recognize, that this cannot make any sense 🙂
a
the docs for 
withVariantReselection()
say it "re-resolve the artifacts using only the attributes in the view's attribute container", but it's using attributes defined in the project where my plugin isn't defined
v
Again, what this means is, that the attributes on the configuration on which you create the view are not used when you do variant reselection. This is just about the attributes that are requested.
To do any selection, these attributes have to be compared to the provided attributes, or you could not select a variant
a
that's an interesting interpretation, but I think not what it's saying
v
It's not an interpretation, it is a fact and exactly what it means
a
it says it only uses attributes in the artifactView, but it's using attributes that aren't in the attributeView
like you said, Usage is absent, so it's using Usage when it's not present
v
Besides that, the words are:
When invoked, this view will disregard existing attributes of its parent configuration and re-resolve the artifacts using only the attributes in the view's attribute container.
It even explicitly states which attributes are disregarded
it says it only uses attributes in the artifactView, but it's using attributes that aren't in the attributeView
Yes, only the ones in the view, not the ones in the parent configuration.
a
either it's a bug or the docs are wrong 🤷
v
Besides that, usage is in the view, it is the only one in the view
That's your problem
a
right, but it's also using ones in the providing project
v
It's neither a bug, nor wrong documentation
It might be too unclear documentation, as you refuse to understand it. But it is not wrong.
This is only about the attributes that are used on the consumer side
And there the attributes on the parent configuration are disregarded and only the ones on the view used
That is, only those, not the ones from the parent configuration
a
I'm quite happy to understand, but it says it "only the attributes in the view's attribute container" but it's using attributes from the providing project
v
If the ones from the dependencies would not be considered, there would be nothing that could be matched for selection, so this is just simply an interpretation that makes not sense at all
Again, what that doc is talking about, is the consumer attributes. You are mixing up and together consumer attributes with provider attributes.
Besides, again, even if you only consider usage, which is present in the view, you have exactly that problem
Exactly because you are only using usage
a
well yes, that's the point, the artifactView says "I want Usage" and the project says "Okay, here are some random files that aren't Usage" and the artifactView should follow the docs and say "I'm only using attributes that are in the attribute container, as per the spec, so no thanks, this doesn't match"
v
For that you have to read and understand the docs about variant selection algorithm and attribute compaatibility
If attribute Usage is requested to be "foo", then a not set Usage attribute is considered compatible with that
a
I have read it and it says it "only the attributes in the view's attribute container" but it's using attributes from the providing project
v
And this is with only considering the Usage attribute
Ok, you are in an endless loop, and I stop here
cu
a
that's okay, thanks anyway. I'll make a bug report 👍
v
Feel free to do so. But be prepared that it will be closed as "works as designed" or whatever. Because it works as designed and also as documented. You even said it. It considers the attributes in the view. The Usage attribute is in the view. So the Usage attribute is considered and compared.
It is the same Usage attribute in the dependency
It might have a different value, or an absent value, but it is the same attribute, the one that is in the view
a
oh do you want to continue?
the doc says it should only consider the attributes in the view. I've only requested Usage. But now it's considering other attributes too, and providing random files.
v
Just a desparate last try to make it clear to you so you don't waste your time creating an issue that will be closed right away with 98% certainty. 🙂
But now it's considering other attributes too, and providing random files.
No, it is not
It considers the Usage attribute
You request usage "foo"
Usage is not set on that variant and thus is compatible
No other attributes are considered and you get the files of that variant
By only using the attributes in the view
What other attributes do you think are used?
What I said was, that this is your exact problem. You have too few / the wrong attributes in your view to get the result that you want
a
What other attributes do you think are used?
my plugin should be agnostic to that - I can't control what other attributes are/aren't set in other projects
v
Yes, but you have to design your plugin so that it fits in the ecosystem in which it is used
a
> Usage is not set on that variant and thus is compatible yes exactly, that's the problem, "no Usage attribute" is not compatible with "only use Usage"
v
Actually, you could also filter for those dependencies that have the attribute not unset. But that's a bit abusive as that is not how the mechanism is designed.
yes exactly, that's the problem, "no Usage attribute" is not compatible with "only use Usage"
Sure it is and that is what also is documented
a
no it's not... I'll quote it again since it makes you think I'm going in a loop instead of you not reading it haha
"using only the attributes in the view's attribute container." (emphasis mine)
"Give me Usage=x" "I don't have Usage, have SomethingElse=random" "Oh great thanks, I only want Usage but you gave me SomethingElse"
v
Why do you think I don't read it? I did read it and it is exactly what is happening. It only uses the Usage attribute as it is in your view. And then it compares the value for that attribute in the consumer with the value for that attribute in the producer.
And the documented logic for "requested X, provided <nothing>" is a match
a
Why do you think I don't read it?
Because you don't seem to understand what it means, and I'm not sure which part is confusing
v
Tell me what you mean
But try it with different words instead of repeating yourself
a
the documented logic is only use the attributes in the artifactView, because that's what the doc says
v
Repeating will not make me understand it better
And only that attribute is used
a
yes, it's used, but it's not the only attribute that's used
v
Yes it is
What other attribute do you think is used?
a
whatever other attributes are provided by the other subproject
v
No, they are not, why do you think they are used?
Only the Usage attribute is used
a
if it only used Usage then it wouldn't return random files
v
It does not return random files. By only using the Usage attribute, it found a compatible variant and gives you the files it provides.
a
It does return random files...
see the screenshot at the top - it's returning a random source file that wasn't requested
v
No, nothing random at all. You did request it.
a
a compatible variant that doesn't have the Usage attribute, so it should be disregarded because it doesn't have the Usage attribute, because the artifactView says it should only use the Usage attribute
it's okay if you don't get it....
I'll try something else
v
You requested give me "Usage X". That dependency does not have a variant that provides "Usage X", but it has a variant that provides "Usage <notset>", so that is what you request
I do get it
But you contradict yourself
You say it should only use the attribute in the view
This attribute is Usage
And exactly that attibute is used
Usage X is compatible with Usage <none>
It is still both the Usage attribute
And it is documented that <none> is ompatible with whatever you request
a
ah but that's the point, if the docs said "using only the attributes in the view's attribute container, or attributes with no values", then that would match what you're saying
v
No, you are confusing attribute with attribute value
The attribute is "Usage", the value in the consumer is "dev-repo" or what you called it, the value in the producer is unset.
But the attribute is "Usage"
And the documented value compatibility is, that "dev-repo" is compatible to unset
a
again: bug or bad docs, either one works for me
v
Imho, neither :-)
Well, bad docs anyway, as the artifact view is not really properly documented at all, but for that there already is an issue
But the docs that are there are correct and it works as designed. 🙂
But again, feel free to ingore me and open an issue, just tried to help you understand it and save you from wasting your time formulating the issue 🙂
a
the subproject is creating some Configuration with an attribute container, and it's not setting Usage=null, that's forbidden. So in my case the artifactView says "I only use Usage", but it's using whatever other attributes that Configuration has instead
"I'm having a BBQ, go to every shop on the high street and only consider items with attribute=BBQ" "'I went to the shops: here are some ribs, cola, and the complete works of William Shakespeare" "wtf, Shakespeare doesn't have attribute=BBQ" "Yes, but it doesn't not have no attribute=BBQ!"
But the docs that are there are correct and it works as designed.
yeah that's kind of the biggest problem with Gradle...
v
The biggest problem with Gradle is, that its documentation is correct and it works like intended? That's a great compliment 🙂
> So in my case the artifactView says "I only use Usage", but it's using whatever other attributes that Configuration has instead Why do you keep saying that? No other attribute is used, only the Usage attribute.
Besides that, I also told you that you can filter for only those dependencies that do actually have the attribute set. It is just an abuse of the mechanism in a way it is not designed and I highly recommend against doing it here.
2 Views
Open in Slack
PreviousNext
Powered by