Skip to content

Conversation

@NaveenPokhriyal
Copy link

Erlier with version 3 we have control over depencies which to include or exclude for apollometadata however it's not the case with newer version of apollo that's why adding support for excluding dependencies from the metadata.
ex : Apollo V3

apolloMetadata(libs.apollo.commomodels.metadata.get().toString()){
        exclude group: 'com.x.y.z', module: 'main-api-schema'
 }

Apollo V4 : with this implementation

dependsOn(
            dependencyNotation = libs.apollo.commomodels.metadata.get().toString(),
            excludes = listOf(
                DefaultExcludeRule(group = "com.x.y.z", module = "main-api-schema"),
                DefaultExcludeRule(group = "com.example", module = "another-module")
            )
        )

@apollo-cla
Copy link

@NaveenPokhriyal: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

@martinbonnin
Copy link
Contributor

Thanks for opening this 🙏

That's a fair point and something that was indeed lost in v4. I'm a bit wary of adding too many options there since the dependency resolution APIs in Gradle are probably more than just exclude, we might want to revert to a single configuration per service that is extended by all the other ones.

Out of curiosity, what's the use case? I didn't expect dependency conflicts to happen there.

@NaveenPokhriyal
Copy link
Author

NaveenPokhriyal commented Jan 9, 2025

Out of curiosity, what's the use case? I didn't expect dependency conflicts to happen there.

So we have a common module which basicaly inherit a schema module as an dependency so whenever we are publishing the common module metadata it also including metadata info of parenet schema module.
as i have seen this is the default behaviour of Mavenpublication,

void from(SoftwareComponent component)
Provides the software component that should be published.

  • Any artifacts declared by the component will be included in the publication.
  • The dependencies declared by the component will be included in the published meta-data.

https://docs.gradle.org/current/dsl/org.gradle.api.publish.maven.MavenPublication.html

so to resolve this issue earlier i used to exclude parent schema module from the artifact but with V4 i can't do it anymore.

@martinbonnin
Copy link
Contributor

So we have a common module which basicaly inherit a schema module as an dependency so whenever we are publishing the common module metadata it also including metadata info of parenet schema module.
as i have seen this is the default behaviour of Mavenpublication,

So your setup is looking like so?

common/build.gradle.kts

dependencies {
  implementation(project(":schema"))
}

apollo {
  service("service") {
    dependsOn(project(":schema"))
  }
}

schema/build.gradle.kts

apollo {
  service("service") {
    generateApolloMetadata.set(true)
  }
}

If yes then you'll need to publish both common and schema. Excluding schema will most likely lead to missing information.

@NaveenPokhriyal
Copy link
Author

common/build.gradle.kts

dependencies {
  implementation(project(":schema"))
}

apollo {
  service("service") {
    generateApolloMetadata.set(true)
  }
}

schema/build.gradle.kts

apollo {
  service("service") {
    generateApolloMetadata.set(true)
  }
}

Yes we have similar setup but common does not dependsOn the schema.

@martinbonnin
Copy link
Contributor

Yes we have similar setup but common does not dependsOn the schema.

So then there is no need to exclude it or is there?

FWIW, I think you have a good idea and allowing to customize dependency resolution in general is a good idea but doing it in a future-proof way might take a bit of design time and I'm trying to understand if there's a way you could have your setup working without this.

@NaveenPokhriyal
Copy link
Author

NaveenPokhriyal commented Jan 9, 2025

So then there is no need to exclude it or is there?

Yes that issue is there cause of that dependency. but i have a local workaround for this.
where i have created a filtered configuration without this dependency by modifying AdhocComponentWithVariants and then publishing that.

@martinbonnin
Copy link
Contributor

martinbonnin commented Mar 6, 2025

@NaveenPokhriyal I'm going to close this in favor of #6408. #6408 adds 2 new user-exposed configurations (per service) that you can use in your dependencies {} block with all the tools from Gradle dependency management:

  • feature/build.gradle.kts
apollo {
  service("service") {
    packageName.set("com.example")]
    generateApolloMetatata.set(true)
    alwaysGenerateTypesMatching.set(emptyList())
  }
}

dependencies {
  // The name of the configuration is "apollo${serviceName.capitalized()}"
  add("apolloService", project(":schema")) {
    exclude(group = "com.x.y.z", module = "main-api-schema")
  }
}
  • schema/build.gradle.kts
apollo {
  service("service") {
    packageName.set("com.example")]
    schemaFiles.from("src/main/graphql/schema.graphqls")
    generateApolloMetatata.set(true)
    alwaysGenerateTypesMatching.set(emptyList())
  }
}

// This needs to be **after** the apollo {} block
dependencies {
  // The name of the configuration is "apollo${serviceName.capitalized()}UsedCoordinates"
  add("apolloServiceUsedCoordinates", project(":feature"))
}

I think it'll allow you to add exclude rules as you see fit. Let us know if it doesn't. In all cases, thank you very much for opening this discussion 🙏

@NaveenPokhriyal
Copy link
Author

Hey @martinbonnin , thanks for the update sure this could help with the missing configurations. 👍

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

Successfully merging this pull request may close these issues.

3 participants