Hello,
I use this options to change graphql default directory folder with this :
schemaFilePath = project.projectDir.absolutePath + '/src/main/java/com/xxxxx/backendlibrary/network/schema.json'
outputPackageName = 'com.xxxxx.networklibraryGql'
(In my graphql default folder I had this tree) :
/graphql/*.graphql
/graphql/user/*.graphql
/graphql/page/*.graphql
Before using this new option I was able to use this import : com.xxxxx.networklibraryGql.user.****. Apollo was builing my classes with keeping folders tree.
And when I use the new outputPackageName option it's not getting my sub folder user correctly like by default. And all of my generated classes are generated in the same folder.
All my classes are here com.xxxxx.networklibraryGql.****
Is it possible to keep my sub folders architecture with custom path?
Yeah seems like we should do this.
What is the proposed solution here? outputPackageName is singular. Reading the name, I would expect it to cause all generation to have a single package name.
If you want to have a hierarchy, have them under a package structure, just like your code and don't use outputPackageName. Wouldn't that simply reolve your issue?
@tasomaniac
If you want to have a hierarchy, have them under a package structure, just like your code and don't use outputPackageName. Wouldn't that simply reolve your issue?
Yes this should work but I guess the intention here is to use relative folder structure as package with a base provided in outputPackageName configuration.
So in original case the intended outcome will be:
com.xxxxx.networklibraryGql.*
com.xxxxx.networklibraryGql.user.*
com.xxxxx.networklibraryGql.page.*
Does it make sense?
Yes but you could easily achieve the same by putting them inside com/xxxx/networklibrary folders, no? I mean, you can potentially add this as a feature but it makes it more complex with not much additional benefit.
I believe that in case of setting explicitly target package, the folder structure where queries are stored is not respected as subpackages, all generated models will be stored on the same provided package level.
Just a context, when you set explicitly path to schema it is required to provide a package where all models are been generated. One common use when you need to explicitly set location for schema is when it shared between iOS, Android possibly with the back end, outside of the Android project
What about adding a rootPackageName that will be prepended to all classes and deprecate packageName ?
For users with an "external" schema.json:
src/main/graphql/user/User.graphql
src/main/graphql/page/Page.graphql
with configuration:
apollo {
services {
create("networklibraryGql") {
schemaFilePath = "./src/main/java/com/xxxxx/backendlibrary/network/schema.json"
rootPackageName = "com.xxxxx.networklibraryGql"
}
}
}
would compile to:
com/xxxxx/networklibraryGql/user/User.kt
com/xxxxx/networklibraryGql/page/Page.kt
com/xxxxx/networklibraryGql/type/CustomType.kt
com/xxxxx/networklibraryGql/fragment/Fragment.kt
For those who include the schema inside src/main/graphql, they could achieve the same with:
src/main/graphql/com/xxxxx/networklibraryGql/schema.json
src/main/graphql/com/xxxxx/networklibraryGql/user/User.graphql
src/main/graphql/com/xxxxx/networklibraryGql/page/Page.graphql
with configuration:
apollo {
}
I'm currently looking into this, I can add it to https://github.com/apollographql/apollo-android/pull/1507
I was also thinking about the same. Single property would be better for this. But of course, this change will be breaking for some.
We can keep the existing packageName and deprecate it in favor of rootPackageName with a nice warning message. We'll have to maintain some glue code for some time but hopefully we'll be able to remove all the glue in apollo 1.3 :)
Closed by an accident
@bellierjonathan can you try with the incubating plugin ? (see https://github.com/apollographql/apollo-android#incubating-plugin for how to enable it)
Thanks for this I didn't see your message.
We are currently on 1.0.1 I will test this after updating the library to 1.2.0. We have some blokers for now. Thanks ;)
This issue is most likely obsolete now @bellierjonathan let us know if you still have the issue on latest versions.