Require-Capability: compile-only

[David Leangen]

Hi,

I could not find any documentation about this:

  Require-Capability: compile-only

It is generated by bndtools in enRoute when I choose a project of type "api".

Is somebody able to explain the significance, and why I would want this?

Cheers,

=David

[Neil Bartlett]

Hi David,

“compile-only” is a requirement namespace, and the choice of namespaces is completely arbitrary*. In this case the requirement deliberately prevents the bundle from resolving at runtime, because there is presumably no other bundle that provides a runtime capability of “compile-only”.

The point of this is to define a bundle that should be used for compilation but not at runtime. In En Route the philosophy is that API packages should be included in provider bundles, therefore it is unnecessary and confusing to have runtime bundles that only export APIs without providing (i.e. implementing) them. I should say that this philosophy is not universally accepted in OSGi circles, but nevertheless En Route is “opinionated software” so that is what it does.

However it’s still useful to have a compile-time JAR that contains only API, because consumers can build against this without any danger of accidentally depending on implementation details that are specific to one provider. It’s also use for those compile-time JARs to be real bundles with versioned Export-Packages, so that bnd can generate correct ranges on your Import-Packages.

So, we create these API bundles and then flag them as “Require-Capability: compile-only” to prevent them being used at runtime. Unfortunately different people are doing this with different namespaces… I have seen “no.resolve” and “do.not.resolve” for example. It would be nice if we could agree a single consistent name, maybe En Route will help with that.

Regards,

Neil

* though only the OSGi Spec is allowed to define namespaces that begin with “osgi.”.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Leangen]

Hi Neil,

Thank you for your quick and informative reply. I think I buy into the concept.

I'm a bit curious about the choice of "no-compile" as a namespace, though. I would have thought a namespace would be something like "enroute" or "bnd", making this requirement "enroute.no-compile" or "bnd.no-compile" (and eventually "osgi.no-compile" if ever it makes the spec). But maybe my understanding of what is intended by "namespace" is incorrect.

I'm also guessing that, at this time, to understand this type of enRoute philosophy I need to ask on this list. :-)

Cheers,

=David

[Neil Bartlett]

Well, the conventions are being discovered/created at the moment, so none of this is settled. For me, “compile-only” is fine because it’s a universal concept. It’s also a little bit different because it’s specifically intended *not* to match a provided capability.

For other namespaces, I agree some kind of company or organisation prefix is sensible.

Regards,

Neil

[David Leangen]

So you are saying that namespaces depend on the universality of a concept? I was under the impression they were to partition by the “owner” of the concept. It doesn’t jive with my mental model of, for instance, the “osgi” namespace, which to me signals that they are “owned” by the Consortium. The only reason I knew where to ask is because it was generated by enRoute. Had I seen this in the wild, I would never have known, so “enroute" as the namespace would have helped, I can imagine.

In any case, those are only my shallow thoughts, and I’m sure I’m missing the complete picture. As you say, let’s wait and see what happens.

Thanks again for the explanations.

Cheers,

=David