[
https://issues.apache.org/jira/browse/ARIES-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842542#comment-15842542
]
Timothy Ward commented on ARIES-1672:
-------------------------------------
{quote} Shouldn't the capability be provided by the implementation bundle
rather than the API ? I mean, it's like the extender capability to some degree,
you just don't want it to be available by simply deploying the API bundle, but
the whole RI.
{quote}
In general it is correct that capabilities should be provided by
implementations, not by the API, but the contract namespace is a special one
designed to cope with "non semantically versioned" APIs (e.g. Java EE specs).
You can see a description of it here:
https://www.osgi.org/portable-java-contract-definitions/
The contract definition is provided so that users of the API can import it
reliably without using a version range. That way the Java EE specs which make
"major" version bumps can still be used safely (JPA, JAX-RS, Servlet...). The
contract definitely applies to the API, and therefore should go on the API
bundle, not the implementation (unless the implementation also exports the
API).
> JPA API contract is required
> ----------------------------
>
> Key: ARIES-1672
> URL: https://issues.apache.org/jira/browse/ARIES-1672
> Project: Aries
> Issue Type: Bug
> Reporter: Timothy Ward
> Assignee: Christian Schneider
>
> The OSGi JPA service spec requires the presence of an OSGi contract for the
> JPA API. This will probably require Aries JPA to package up its own version
> of the JPA API. Note that this will only be necessary to function as the
> official RI, and we can still support using other public API bundles.
> Provide-Capability: osgi.contract;osgi.contract=JavaJPA;
> version:List<Version>="2.1,2,1";uses:="javax.persistence,javax.persistence.criteria,javax.persistence.metamodel,javax.persistence.spi"
> We could optionally choose not to support versions 2 or 1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
