https://gradle.com/ logo
Join SlackCommunities
Powered by
This message was deleted.
# community-support
s
This message was deleted.
j
If I understand correctly , I guess the other way would be to create another submodule such as 
protocol
that generates the code and then have your 
rest-app
and 
service-client
depend on 
protocol
b
well, i want to generate two separate code bases, with different generator configurations from the same api spec definition file
v
It is a checked-in file, not something generated by the build, right?
Why don't you just reference the file from both projects and have their own generate tasks each?
b
i can, but what's the best way to reference a single file across two modules? just put it in the parent and have a file system ref? "../../MyApiSpec.yml" etc?
n
we make it available as a publication artifact, so other modules can just have a project dependency on the spec
b
so, i guess that means i need a 3rd module just to hold the api spec? 
api-model
already publishes a bunch of classes, that would conflict with the classes generated into 
service-client
v
Not necessarily. If it fits semantically into one of the existing modules, you can just make a feature variant that publishes that file, or of it is just for usage within the build, but not for consumption by downstream projects, you can also just make a consumable configuration that you depend on.
☝️ 1
b
ahh, a consumable configuration probably makes sense
I’m struggling to figure out the right gradle encantation for sharing the ApiSpec file between two projects. project `a`: 
src/main/resources/static/apispec/ApiSpec.yaml
build.gradle.kts
Copy code
val apiSpec: Configuration by configurations.creating {
    isCanBeResolved = false
    isCanBeConsumed = true
}


artifacts {
    // the build path resulting from (i assume) result of `processResources`
    add("apiSpec", file("build/resources/main/static/apispec/ApiSpec.yaml"))
]
openApiGenerate {
    inputSpec.set("src/main/resources/static/apispec/ApiSpec.yaml")
   // configure code generation into project a ...
}
configure<SourceSetContainer> {
    named("main") {
        java.srcDir(openApiGenerate.outputDir.get())
    }
}

tasks.withType<JavaCompile>().configureEach {
    dependsOn(tasks.named("openApiGenerate"))
}
project 
b
(consumes ApiSpec from 
a
): 
build.gradle.kts
Copy code
val apiSpecConfiguration by configurations.creating {
    isCanBeConsumed = false
    isCanBeResolved = true
}
dependencies {
    apiSpecConfiguration(project(path=":a", configuration="apiSpec"))
}
val apiSpecFile = apiSpecConfiguration.incoming.artifacts.artifactFiles.singleFile
openApiGenerate {
    inputSpec.set(apiSpecFile.absolutePath)
   // configure code generation into project b ...
}
tasks.withType<JavaCompile>().configureEach {
    dependsOn(tasks.named("openApiGenerate"))
}
on a clean build i now get:
Copy code
* What went wrong:
A problem was found with the configuration of task ':b:openApiGenerate' (type 'GenerateTask').
  - In plugin 'org.openapi.generator' type 'org.openapitools.generator.gradle.plugin.tasks.GenerateTask' property 'inputSpec' specifies file '/Users/me/projects/myproj/a/build/resources/main/static/apispec/ApiSpec.yaml' which doesn't exist.

    Reason: An input file was expected to be present but it doesn't exist.

    Possible solutions:
      1. Make sure the file exists before the task is called.
      2. Make sure that the task which produces the file is declared as an input.
what is the proper way to declare that consuming 
a
configuration 
apiSpec
depends on 
processResources
to copy the file into build? or should i just add the file from the 
src/
path into the artifact as that will always be present (there’s no post-processing)?
v
As you use a plain path declaration and not some task output, you have to tell Gradle manually which task generates the file using
Copy code
add("apiSpec", file("build/resources/main/static/apispec/ApiSpec.yaml")) {
    builtBy(tasks.processResources)
}
Or, as you said, just use the source path, that is also what you use to generate the code in 
a
so would probably be more consistent.
b
the above (including builtBy) results in the same error
using the one in src/main/resources like:
Copy code
artifacts {
    add("apiSpec", apiSpecFile) {
        builtBy(tasks.processResources)
    }
}
seems to work fine (though, not really reliant on processResources but 🤷 )
v
Hm, would have to play with it. 🤷‍♂️ But if you use the source file, remove the 
builtBy
.
👍 1
4 Views
Open in Slack
PreviousNext
Powered by