https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
I'm a bit confused. You say your worker api code should call X (X being the 3rd party library), but it should not have a runtime dependency on X and the users of your plugin should also not declare a dependency on X. So where should X come from at runtime?
a
there’s a custom Configuration with a default dependency on X that will be resolved when the Task is triggered
v
Ah, that you meant with custom configuration, stupid me. My brain is already on vacation. 😄
And where do you want to / need to hide X from then?
a
if you add a dependency on 
implementation("dev.adamko.dokkatoo:dokkatoo-plugin:0.0.4")
in buildSrc (or included plugin build) you’ll get an error, because some of the classes extend from dokka-core (which is the 3rd party lib)
v
What error exactly?
Because sounds strange
a
I thought I fixed all those problems in v1.0.0 by using Kotlin/binary-compatibility-validator, but I missed a class because of generic type erasure, so a 
Property<SomeDokkaCoreClass>
requires a dependency on dokka-core. I really want to prevent this from happening again by segregating the source sets, so that one is private and has a dependency on dokka-core, but another is public and has no dokka-core dependency
v
Ah, now I get what you mean. You actually added an X class to your Public API and want to avoid that happening again by separating the concerns. How about simply splitting the worker code into an own project / artifact that gets published too and depended upon from your plugin?
a
yes exactly
it’s really convenient being to publish one artifact to Gradle Plugin Portal so yes, multiple projects would probably be best. But I wanted to try and squeeze it into one.
What error exactly?
Copy code
> Task :buildSrc:compileKotlin FAILED
e: Supertypes of the following classes cannot be resolved. Please make sure you have the required dependencies in the classpath:
    class dev.adamko.dokkatoo.dokka.parameters.DokkaSourceSetSpec, unresolved supertypes: org.jetbrains.dokka.DokkaConfigurationBuilder
Adding -Xextended-compiler-checks argument might provide additional information.

e: /projects/x/buildSrc/src/main/kotlin/buildsrc/convention/dokkatoo.gradle.kts: (21, 5): Cannot access 'org.jetbrains.dokka.DokkaConfigurationBuilder' which is a supertype of 'dev.adamko.dokkatoo.dokka.parameters.DokkaSourceSetSpec'. Check your module classpath for missing or conflicting dependencies

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':buildSrc:compileKotlin'.
> A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction
   > Compilation error. See log for more details

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
v
Would it maybe be an option to cover it with tests? If you have tests without X, you should hopefully also get such failures.
a
yes that’s an option too
I do have integration tests, but I suspect the Plugin DSL is being clever. It doesn’t seem to be a problem when the plugin is applied via its plugin ID
v
o_O
a
but actually looking at it, I’ve added X as an implementation dependency…
v
Ah, well, now looking at your error, it is the 
compileKotlin
that fails. So yeah, applying with ID then of course does not have that problem.
If you separate things but then want to have it in one jar it is imho always a bit unclean. I'm not aware of a built-in way to separate code, but then have it in one jar, you always have to fiddle around if you need something like that.
a
I think I just need to change 
implementation("dokka-core")
to 
compileOnly("dokka-core")
v
Maybe another option with tests would be some "architecture testing", there are tools or libs for it. So that a test can e.g. verify that only classes in package Y use classes from X.
c
^^^ have used archunit for exactly that.
👍 1
v
I think I just need to change 
implementation("dokka-core")
to 
compileOnly("dokka-core"
Didn't you say it is a compile only dependency?
a
I thought it was, but I was mistaken :)
v
^^^ have used archunit for exactly that.
Ah, yeah, tried to remember that name, thanks 🙂
👍 1
I thought it was, but I was mistaken 🙂
But it wouldn't change anything, would it? As long as you don't make it 
api
, it will not be in the compile classpath of the consumer and thus give that error on compilation
a
ArchUnit gives me nightmares of working with someone who took ‘defensive programming’ to it’s absolute extreme maximum 😬
and thus give that error on compilation
I want an error on compilation! The X classes should only be used by the Worker API at runtime, which has an isolated classpath which contains X
c
ArchUnit gives me nightmares of working with someone who took ‘defensive programming’ to it’s absolute extreme maximum 😬
like any tool it can certainly be abused. If used selectively to enforce constraints that’s fine; if it becomes pedantic, well…
👍 1
a
I want an error on compilation!
or maybe I don’t… I’m getting lost
v
At least it would be a build-time error 🙂
Another option that does not separation-but-then-combination-trickery - but of course needs more time - is to just have a second source set that compiles the files that should not need X. They then get compiled twice, but you would get a compilation error. 😄
If archunit gives you nightmares you could also have a simple text search check, that verifies the package of X is used nowhere except for the approved files. archunit-light so to say. 😄
21 Views
Open in Slack
PreviousNext
Powered by