Skip to content
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

Publishing fails for Open-Api artifacts generated with spring-doc #171

Open
cgrabmann opened this issue Aug 21, 2023 · 1 comment
Open
Assignees

Comments

@cgrabmann
Copy link
Contributor

The integration of the org.springdoc:springdoc-openapi-gradle-plugin Plugin runs into a problem while publishing an artifact.

Running the clfGenerateOpenApiDocumentation task and therefore the generateOpenApiDocs task on their own works without issues.

But if the generateOpenApiDocs task is run during publishing it results in an error similar to this:

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':skeleton-server:javadocJar' (type 'Jar').
  - Gradle detected a problem with the following location: 'C:\cloudflight\src\cloudflight\autoconfigure-gradle-plugin\src\test\fixtures\springdocopenapi\kotlin-springboot-angular\skeleton-server\build\libs\skeleton-server-0.11.2-SNAPSHOT-javadoc.jar'.
    
    Reason: Task ':skeleton-server:forkedSpringBootRun' uses this output of task ':skeleton-server:javadocJar' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
    
    Possible solutions:
      1. Declare task ':skeleton-server:javadocJar' as an input of ':skeleton-server:forkedSpringBootRun'.
      2. Declare an explicit dependency on ':skeleton-server:javadocJar' from ':skeleton-server:forkedSpringBootRun' using Task#dependsOn.
      3. Declare an explicit dependency on ':skeleton-server:javadocJar' from ':skeleton-server:forkedSpringBootRun' using Task#mustRunAfter.
    
    For more information, please refer to https://docs.gradle.org/8.2/userguide/validation_problems.html#implicit_dependency in the Gradle documentation.

* Try:
> Run with --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

This happens because the springdoc-openapi-gradle-plugin uses the gradle-execfork-plugin to start the spring-boot application. But the gradle-execfork-plugin declares the working directory as @InputDirectory which causes gradle to track all tasks creating files in the build-directory and then assumes that the forkedSpringBootRun is wrongly configured, since it has those files as input but does not declare a dependency on the generating tasks. This is already tracked in this issue.

As a workaround for now we can disable state tracking for the forkedSpringBootRun task. But this also disables gradle caching and might have undesirable consequences since the job might be run even if it does not need to, resulting in way longer build times then necessary.
We can try to make sure that the open-api documentation generation is only depended on when a publish task is run, but this only solves the issue for projects that do not manage its frontend in the same project. Projects which generate the frontend-api inside the same project will depend on the generated api-spec artifact and therefore run its generation every time the frontend is build.

Another workaround might be to use a dummy working directory for the forkedSpringBootRun task. But this might cause the spring boot application to not start correctly and therefore failing to generate the api-spec completely.

@cgrabmann cgrabmann self-assigned this Aug 21, 2023
cgrabmann added a commit that referenced this issue Aug 22, 2023
* we work around this by creating a dummy directory which we will use as a working directory for the forked spring bootRun task. Because some other tasks also seem to use this directory we also make them depend on this task. But that list might be incomplete.

Signed-off-by: Clemens Grabmann <[email protected]>
@cgrabmann cgrabmann added this to the v-1.0.0 milestone Aug 22, 2023
cgrabmann added a commit that referenced this issue Aug 22, 2023
…#172)

* we work around this by creating a dummy directory which we will use as a working directory for the forked spring bootRun task. Because some other tasks also seem to use this directory we also make them depend on this task. But that list might be incomplete.

Signed-off-by: Clemens Grabmann <[email protected]>
@cgrabmann
Copy link
Contributor Author

for now I implemented a workaround that configures the working directory for the forked spring boot run to be some dummy directory that does not have any content, therefore this error does no longer happen.

But a fix in the plugins themselves would still be preferred.

@cgrabmann cgrabmann removed this from the v-1.0.0 milestone Sep 1, 2023
rspiegl added a commit that referenced this issue Jun 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant