https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
✅ 1
v
It is probably your best bet to publish the jar to some file-based local directory (but not 
mavenLocal()
) and then use that repository within your tests. The path to the repository could be a temporary directory that you give as parameter to the tests.
s
That makes sense in theory. Do you mean an actual pub repo? Seems like that would be the "easiest" way
Well, shoot. It actually needs multiple "local" projects - so that's going to be not-so-straight-forward
v
It is practically the same setup some people use to test the actual plugin, especially when there are class loader problems with 
withPluginClassPath()
for example because the plugin uses other optional plugins that are then only in a lower class loader in the test and then cannot be found by the plugin.
Unfortunately, I don't have an example at hand
s
No, you pointed me in a direction - I appreciate it
👌 1
I think GradleRunner may not be a good fit
v
No?
s
The issue I am trying to test against is very specifically processor dependency and transitivity
If I am "hacking" those jars into a "repo", kind of introduces potential problems into exactly what I am trying to test
v
😞
s
Really its Maven users the test is for
v
Yeah, then 
GradleRunner
seems to be not a too good match 😄
s
Well, I can "mock" it using Gradle
In the Maven world, applying a processor the "right way" is a pita
But you can do the same with Gradle by applying the processor using e.g. 
compileOnly
v
But that should not apply the processor since quite some versions, should it?
s
We had made a change that introduced implementation dependencies on the processor
What do you mean "not apply"?
afaik it will just not apply transitive deps "properly"
v
If you add an annotation processor jar to 
compileOnly
only, the annotation processor should not be invoked
s
hm, I don't think that's true. but I'll verify right now
v
The annotation processor should only be invoked when you add it to 
annotationProcessor
since many versions
s
adding it to compileOnly still puts it on the compile (javac) classpath
v
Yes, on the compile classpath it is put, but the annotation processor will not be invoked
s
Javac invokes it
v
Not if you run it through Gradle I think
s
Well that's what I'm testing right now 🙂
But that's not generally how javac works
v
Not javac, but Gradle 🙂
It probably gives 
proc:none
or so, I forgot the gory details
s
Gradle spwans 2 javac processes when you use 
annotationProcessor
? that would be unfortunate
i thought it just sets processorpath from 
annotationProcessor
v
If there is nothing on the configured annotation processor path, it supplies 
-proc:none
. If there is anything on the configured annotation processor path it sets 
-processorpath
.
So as I said, adding the annotation processor only to 
compileOnly
should not make it invoked.
See the issue you reported I linked above. 🙂
s
I mean looking at what you've said and code, I think you can trick Gradle to do it
Add one processor to 
annotationProcessor
and another to 
compileOnly
Because 
annotationProcessor
is not empty, you won't get 
proc:none
But whatever, ...
v
You won't get proc none, but processorpath and with that javac does not look at the classpath for processors
👍🏼 1
3 Views
Open in Slack
PreviousNext
Powered by