Compilation Error in case of multiple Schema files about dgs-codegen HOT 8 CLOSED

We do have the option of specifying the generated package, but not per schema file - it's for all the generated files, so that doesn't address your use case.
Are you able to use extend type Query {} for the queries in the second schema file? That should avoid defining the constants again.

from dgs-codegen.

So my use case is, i have stored 2 different schema files in a single directory. And hence I am getting the conflicts. Bascially, both the files are not related to each other. Hence both of them generate Query and Mutation constants in the same package and hence creates a conflict.

from dgs-codegen.

So do you want codegen to be run on both the files or just one of them?If just one, you can specify the schema path to point o the one file in the gradle config. If you want codegen on both, then you will need to update one of the schema files to have this for the query/mutation definition:

extend type Query {
    yourQuery()
}

The other option is to have the schema files and related implementations in separate modules with separate build.gradle files that each define their own generateJavaTask.

Hope that helps.

from dgs-codegen.

Well i wanted to run the codegen on both the files. 1st opt I don't think is the right way to do it. 2nd option I have already implemented as a workaround.

However, just a suggestion why cannot we extend the platform to specify different packages for different files?

from dgs-codegen.

Could you elaborate on why extending the query type is not a good solution for your use case?

Extending the query/mutation type when we have multiple schema files in the same project is a common way to split your schema across different files in a project. This is how we use it internally as well.

While adding more configuration is definitely possible,it would make more sense if there isn't an existing solution for dealing with multiple schema files.

from dgs-codegen.

If you want to split generation for different schema files completely - for example when generating a Query API for an external service, the recommendation is put this schema file in a separate Gradle submodule, so that it can also have its own codegen configuration.

from dgs-codegen.

Not implementing a solution for this, since we already have recommendations for handling this use case.

from dgs-codegen.

The reason for not implementing this is that in most use-cases you would need to specify different codegen config altogether, not just package names, so typically it isn't the right setup.

from dgs-codegen.