OSGi split package problem

[dhermanson]

Hello,

First of all, thank you for this fantastic library.

I'm using your library along with graphql-java in an OSGi context, specifically Apache Karaf. I believe I'm running into a problem with what in OSGi terms is called a split package. Both this project and the graphql-java project export the package graphql.schema.idl package.

I'm relatively new to OSGi and Karaf. I've been using it for about 8 months. My current approach to fix my problem will be to fork this project and move the single DirectiveBehavior file into a package that would not result in my split package problem.

Forgive me if this question is misinformed. But, is there any particular reason why this DirectiveBehavior class needs to sit inside the graphql.schema.idl package? I believe this causes a problem for all OSGi users who are using this library.

Perhaps OSGi support is not a goal of this project. If so, that's completely fine. I just wanted to explain my current approach to solving my problem, and see if perhaps that single file could be moved into a package that wouldn't be in conflict with the packages that graphql-java is exporting.

If anyone has a better approach for me, please inform me. As I said, I'm only about 8 months into my OSGi and Karaf knowledge.

PS - I'm pretty new to creating issues. So please forgive me if I didn't structure this properly.

Thanks!

[dhermanson]

I see the @Internal annotation on SchemaGeneratorDirectiveHelper in graphql-java, now. Moving DirectiveBehavior outside of graphql.schema.idl would make it so that DirectiveBehavior would no longer have access to some of the classes it depends on.

I think my only option now may be to wrap both graphql-java and graphql-java-tools and embed them in a new bundle using something like bndtools or apache felix's maven-bundle-plugin.

[dhermanson]

Alternatively, I may fork the graphql-java project, and simply add the DirectiveBehavior class there, since it doesn't seem to depend on anything in this graphql-java-tools project.

[oliemansm]

@dhermanson This has the same cause and fix as #282. The PR to fix make that SchemaGeneratorDirectiveHelper public so we can use it from another package has been merged, but not yet released. Once that has happened this can be fixed here too.