-
Notifications
You must be signed in to change notification settings - Fork 411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Could not read file exception with 1.8.10 + java 18 #2956
Comments
could this be a duplicate of #2877 ? |
Can you please try running it with different versions of Java/Gradle/Kotlin/Dokka? There might be a correlation here, Gradle has fixed something similar: #20463 If you can't find the cause, ideally, we'd need an isolated reproducer project, or at least the full stacktrace - at the moment it's unclear if it's even Dokka's fault (we use a few dependencies for code analysis), and where (how) exactly it happens. Without it, there's not much we can investigate, unfortunately |
@IgnatBeresnev Thanks for the reply! In the meantime, I have just tried with gradle 8.1 + dokka 1.7.10: same result unfortunately
|
grade 8.1 + dokka 1.8.10
|
I tried to toggle more features on/off
for compilation modules reverting to 11 is something we would really like NOT to have to do though. Among other things because JDK 17 will soon be necessary to run the android gradle plugin |
AGP 8.0.0 is stable now so we are now there. |
Thanks for researching it!
This is interesting. Are you using a task called AGP 7.1 did start bundling a very old version Dokka, which led to a bunch of compatibility problems for existing Dokka users (see #2472), so here there might be a similar problem here. Judging by the stacktrace, it looks like the version of the kotlin compiler used to generate the docs does not support Java 18. If AGP bundles a very outdated version of Dokka, no wonder! I've just tried running Dokka with Java 19, and it works just fine: plugins {
kotlin("jvm") version "1.8.10"
id("org.jetbrains.dokka") version "1.8.10"
}
tasks.named("compileKotlin", org.jetbrains.kotlin.gradle.tasks.KotlinJvmCompile::class.java) {
compilerOptions {
jvmTarget.set(JvmTarget.JVM_19)
}
} Log:
So it might be an upstream bug of AGP. Can you share which task you're using just to make sure? |
Summary: This is currently breaking our jetpack-compose build and blocks the entire release as a consequence: #4970 There are all sorts of workarounds but they require changing the java target which could have other downstream consequences: Kotlin/dokka#2956 We don't actually rely on these artefacts at all, so it's probably safe to just disable this. Closes #4970 Test Plan: ./gradlew publishToMavenLocal
Summary: [gradle] Remove dokka plugin This is currently breaking our jetpack-compose build and blocks the entire release as a consequence: #4970 There are all sorts of workarounds but they require changing the java target which could have other downstream consequences: Kotlin/dokka#2956 We don't actually rely on these artefacts at all, so it's probably safe to just disable this. Closes #4970 Pull Request resolved: #4995 Test Plan: ./gradlew publishToMavenLocal Reviewed By: antonk52 Differential Revision: D48062872 Pulled By: passy fbshipit-source-id: aef0696d5ac83dd50bcbb96b0552f9b222f5a566
interesting, so we have had more time to dig into this as we need to find a solution to adopt compose 1.5. This has allowed us to dig deeper into the doc generation as we still see this issue. we are indeed using our `solution' has been to disable this task for the one specific module where this happens So I have tried to use We will investigate further and decided whether to contribute a fix at the vanniktech level or to migrate to our own internal publish plugin (we already have one, still incubating). Hard to know for sure without digging more into its codebase, but I think that the core issue is due to how vanniktech declares dependencies between modules. |
Just updated a project to AGP 8.1.1 and Kotlin 1.9.10 and getting the same error when I try to
|
I see the same error like @nate-eisner with Java 17 installed. |
If you have this problem, you can temporarily disable this task. In my case this happened during maven publishing, I disabled this task and it worked fine. // https://github.com/Kotlin/dokka/issues/2956
tasks.matching { task ->
task.name.contains("javaDocReleaseGeneration", ignoreCase = true)
}.configureEach {
enabled = false
} |
Wouldn't then that not generate the javadoc (whole point of running dokka)? |
We're running into this issue too, but I'm not convinced it's purely a Dokka issue. The step that fails during execution, I've tried creating a minimal repo that recreates this, but I haven't had any luck yet. All of the files that it shows in the errors. are sealed classes, but not all sealed classes are erroring. |
To address Kotlin/dokka#2956
Running into a similar problem after adding Lottie Compose to the project. Kotlin 1.9.22 sourceCompatibility, targetCompatibility and Kotlin JVM target all set to Java 11.
|
According to this Slack message, at least my problem has been caused by AGP bundling some older version of Dokka, which activates when in the AGP's
The workaround was to remove
|
Hello,
We decided to go with 2. As we had Kotlin plugins configured, here's the commit implementing the same in Kotlin: |
We have the same issue after changing targetJVM to 17 from 11. |
Nope, just failed much later in the build. |
# [DCMAW-10696](https://govukverify.atlassian.net/browse/DCMAW-10696): Fix the pipeline on the UI repo - Swaps the remaining configuration to use mobile-android-pipelines - Fixes publishing by removing JavaDoc tasks [taken from here](Kotlin/dokka#2956) ### Commits - [chore: Standardise build.gradle.kts](367a591) - small reformat - [chore: Delete buildSrc](2286889) - delete's unused directory - [chore: Update compose dependency usage](0bcc236) - Align's compose dependency usage with Android's suggestions* - [chore: Use mobile-android-pipelines](9635d3c) - delete a lot of unused config - [chore: KtFormat](6acc54c) - Run KtFormat - [fix: SonarQube issues](5a16806) - SonarQube moaned about some stuff, so I fixed it to be sure - [fix: Disable javaDoc tasks](012fe8c) - the actual fix (I can pull this out if people are worried) - [fix: Correct Vale Config location](cd9b504) - I'd messed up the vale config bit during the config deletions, this fixes that *This was actually an attempt at a fix as it was compose's @PreviewParameter that was throwing the exception ## Evidence of the change - None ## Checklist ### Before creating the pull request - [x] Commit messages that conform to conventional commit messages. - [x] Ran the app locally ensuring it builds. - [x] Tests pass locally. - [x] Pull request has a clear title with a short description about the feature or update. - [x] Created a `draft` pull request if it's not ready for review. ### Before the CODEOWNERS review the pull request - [x] Complete all Acceptance Criteria within Jira ticket. - [x] Self-review code. - [x] Successfully run changes on a testing device. - [x] Complete automated Testing: * [x] Unit Tests. * [x] Integration Tests. * [x] Instrumentation / Emulator Tests. - [x] Review [Accessibility considerations]. - [x] Handle PR comments. ### Before merging the pull request - [x] [Sonar cloud report] passes inspections for your PR. - [ ] Resolve all comments. [Sonar cloud report]: https://sonarcloud.io/project/overview?id=di-mobile-android-ui [Accessibility considerations]: https://developer.android.com/guide/topics/ui/accessibility/testing [DCMAW-10696]: https://govukverify.atlassian.net/browse/DCMAW-10696?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
wDescribe the bug
I am migrating my android library project to kotlin 1.8.10, but I started getting this exception:
Expected behaviour
Not crashing would be very nice and polite
To Reproduce
It seems to occur when a module refers to classes from another module (and both of these modules use dokka)
Dokka configuration
Installation
Additional context
Are you willing to provide a PR?
Potentially yes, I might need some guidance to pinpoint the source thoug
The text was updated successfully, but these errors were encountered: