[ https://issues.apache.org/jira/browse/SLING-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385358#comment-17385358 ]
Bertrand Delacretaz commented on SLING-10619: --------------------------------------------- bq. ...they also in turn advertise a capability for each schema / partial they provide... Do you envision generating those capabilities automatically at build time? Maybe with a bnd plugin like https://github.com/apache/sling-org-apache-sling-bnd-models ? I think from the developer's point of view the ideal scenario should be: * Add the Sling-GraphQL-Schema header pointing to the path where partials are found * Add any partial schema files in there * That's it And at build time the tooling should: * a) Validate the syntax of the partial files * b) Generate the corresponding OSGi provide-capability and require-capability headers And maybe later a Sling feature analyser can * c) verify that the required partials are provided as well as ideally verify the syntax of the aggregated schema. That's the ideal case but I think we need at least b) to avoid having to duplicate information, and that requires a) to extract the relevant values. > Remove sling.graphql-schema-aggregator capability if not useful > --------------------------------------------------------------- > > Key: SLING-10619 > URL: https://issues.apache.org/jira/browse/SLING-10619 > Project: Sling > Issue Type: Improvement > Components: GraphQL > Reporter: Bertrand Delacretaz > Priority: Minor > Fix For: GraphQL Schema Aggregator 0.0.2 > > > The {{ProviderBundleTracker}} currently requires provider bundles to define > an [OSGi > capability|https://github.com/apache/sling-org-apache-sling-graphql-schema-aggregator/blob/04474a2fe16389c0df60471922f38e7dcfc637ef/src/main/java/org/apache/sling/graphql/schema/aggregator/impl/ProviderBundleTracker.java#L48], > I think the idea is for that class to efficiently ignore bundles which are > not provider bundles. > However I don't think this is more efficient than just having > {{addingBundle(...)}} test for the {{Sling-GraphQL-Schema}} header. > I would argue that doing the following in that method would be at least as > efficient than the current code in terms of ignoring non-provider bundles: > {code:java} > @Override > public Object addingBundle(Bundle bundle, BundleEvent event) { > final String providersPath = > bundle.getHeaders().get("Sling-GraphQL-Schema"); > if (providersPath == null) { > // not interested in that bundle > return; > ... > {code} > Currently, requiring this capability means provider bundles must declare both > the {{Sling-GraphQL-Schema}} header and the > {{sling.graphql-schema-aggregator}} capability. > Unless there are definite advantages in having both, I'd be in favor of > requiring just the {{Sling-GraphQL-Schema}} header to keep things as simple > as possible. > [~radu] I know you were in favor of using the capability, if we agree that > the above code has no performance impact, do you see another benefit of using > the capability? -- This message was sent by Atlassian Jira (v8.3.4#803005)