https://kotlinlang.org logo
Join Slack
Powered by
Randomly our team hits this issue: > Cannot c...
# dokka
a
Randomly our team hits this issue:
Cannot change dependencies of dependency configuration 'aws runtimedokkaGfmPlugin' after it has been resolved.
Project builds fine from cli but intellij won't load the project. Anyone have any insights how to solve?
I've submitted an issue for this: https://github.com/Kotlin/dokka/issues/2424 that has more details. Our only recourse so far has been to just disable dokka to work in Intellij which is less than ideal
i
Hi! Thanks for reporting the problem, we haven't heard much about such problems I did some googling and it seems like the problem is caused by dokka and some other gradle plugin competing for something. A few other plugins have had the same problem, otherwise very little is known for some people it helps to reorder some tasks and/or dependencies in their build file, but I found nothing that looks suspicious in your build files :( if it reproduces consistently and locally, maybe try to remove certain blocks of dokka configuration or move things around in build.gradle.kts to see if it helps? In other words, try to isolate the problem? That would help a lot! In the meantime, we'll have a look at it as I think it's something to be fixed before going into Stable
a
@Ignat Beresnev Thanks. I did try some isolation and can see the problem happens just from applying the plugin at the root project and having it disabled everywhere else
interestingly I tried the latest Intellij 2022.1 RC build and it loads the project fine. I'm not sure why there would be a behavior difference between invoking from CLI and loading it from intellij but something about how intellij is invoking gradle perhaps?
i
I was thinking about the order of execution, actually. i.e maybe idea tries to run things in parallel and something happens earlier/later than it should, so it closes the window for dokka. whereas if run via the wrapper it's all sequential or the timings are just "better", not sure. Just a wild guess 🙂 I'll ask if anything like this has been fixed in 2022.1, thanks!
a
yeah I thought the same. I added 
org.gradle.parallel=false
to 
gradle.properties
but no change in behavior. We do run builds in CI and for releases with 
--parallel
though so even from CLI gradle still loads and builds the project fine when running in parallel
🤔 1
i
While I have you here, is there anything specific that I need to do after opening the project in IDEA to reproduce the behavior? Other than running 
:codegen:sdk:bootstrap
?
a
you don't even need to do 
:codegen:sdk:bootstrap
. That just generates all the service clients. Day to day when working on the project I don't even load most service clients unless I need to
👌 1
literally just opening the project should be enough. Most of the time we also have a copy of smithy-kotlin loaded as a composite build (having it as a sibling to 
aws-sdk-kotlin
will automatically load it as a composite)
our build is obviously a little bit larger and more complex than most and this issue doesn't seem to recreate easily (my colleagues hit it a while ago and switched to working on a remote desktop to get around, I just hit it for first time after mucking with version upgrades for gradle/kotlin/kotlin-plugin, etc)
if you have any questions though feel free to reach out directly, happy to provide any support we can
i
Yeah, will do, thanks! I'll keep you posted as soon as there's any info Poor aws-sdk-kotlin team btw, first OOM issues, now this 😅 your project has been great to debug on though, so hopefully we'll get through this one as well
a
if you've already done the bootstrap you can remove all the projects and unload them with:
Copy code
git clean -dfx services/
If you want to get a smaller number of services loaded you can do:
Copy code
./gradlew :codegen:sdk:bootstrap -Paws.services=+s3
which will only generate the 
s3
client for instance (having one or two present is probably more representative of what our builds look like in development at any given time)
🙏 1
Poor aws-sdk-kotlin team btw, first OOM issues, now this 😅 your project has been great to debug on though, so hopefully we'll get through this one as well
Ha yeah it's a good stress test project with everything loaded lol
...and now hitting it on 2022.1
i
We haven't confirmed it yet, but the problem may come from other plugins in your buildscript or from some task configuration. Something seems to resolve classpath before dokka is able to add dependencies to it. Unfortunately, until we've confirmed that everything is as it should be on our side, I can only suggest commenting out pieces of the buildscript to see if it helps 😞
a
I suspect you may be right. I've disabled an internal intellij plugin we use and the issue has so far disappeared.
i
Can you share some details, which plugin? Maybe I'll be able to find what exactly is causing this, if it's open source
a
unfortunately it's not open source, it's an internal plugin for dealing with internal build systems
I actually don't know much about it, only installed it relatively recently compared to most people which is how I even made the connection
I'm not 100% sure that's the issue but it aligns with the behavior (only happening in intellij vs through gradle command line)
i
I see. Btw, I wasn't able to reproduce the problem, I've re-imported your project like 50 times and no problems thus far, presumably because I don't have the plugin installed. Moreover, we haven't really heard such reports from anyone. Not sure what to do with this problem now 😅 Anyhow, we'll check that dokka is not violating gradle best practices and doesn't do anything funny. There's still a possibility that dokka might be partially at fault here, but it's low
a
Thanks for the assistance, I'll let you know if we see it without this plugin but for now I'm unblocked
👍 1
3 Views
Open in Slack
PreviousNext
Powered by