Hi Scott, <tldr>
If you’re using JDBC you don’t really care about JPA. Therefore you should compile against the OSGi jar, but not worry about deploying it at runtime. Instead you can just deploy the Aries Transaction Control implementation (which includes a substitutable export of the Transaction Control API). I would suggest that you want to start by using tx-control-service-local <https://github.com/apache/aries-tx-control/tree/tx-control-1.0.1/tx-control-services/tx-control-service-local> and tx-control-provider-jdbc-local <https://github.com/apache/aries-tx-control/tree/tx-control-1.0.1/tx-control-providers/jdbc/tx-control-provider-jdbc-local> at runtime. </tldr> Now, the JPA dependency. The JPA (much like the servlet container) specification versioning policy is not done very well. Marketing versions have been used for the APIs despite the fact that backward compatibility has been maintained between versions. This breaks the cardinal rule of semantic versioning, which is that changes to the major version indicate breaking changes. In any event, there is a part of the transaction control specification (in this case the JPA resource provider) which provides EntityManager instances, coupling it to the JPA API (there is a similar coupling for the JDBC resource provider and javax.sql). The reason that the version range starts at 1.0 is not because the specification is old, but because all versions (back to 1.0) are supported. Unfortunately where JPA APIs have been versioned using their marketing versions (2.0, 2.1, 2.2) this means that they don’t match a version range of "[1,2)”. The general solution to this is to use the “osgi.contract” namespace <https://osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html#service.namespaces-osgi.contract.namespace> there is a contract name defined for JPA <https://www.osgi.org/portable-java-contract-definitions/>. This however needs API bundles that provide the contract... Please get in touch if you have more questions, All the best, Tim > On 7 Apr 2020, at 05:57, Markus Rathgeb via osgi-dev <osgi-dev@mail.osgi.org> > wrote: > > As I am using OSGi for a lot of projects on a pure Maven build with > the help of all the bnd maven plugins. > For easily testing I used bndrun files. > > I don't want to create the set of bundles that are allowed to be used > at runtime all the time and so I started to create pom files that > contains all of them (one for bundles that are used at compile time > and one for bundles that are potentially used at runtime). > Using that approach my bnd application can depend on that runtime pom > using scope "runtime" and could consume the specified artifacts to > resolve its requirements. > > The runtime pom contains also the bundles that has been necessary for > me to use transaction control, hibernate, ... > If you want to have a look at: > https://github.com/maggu2810/osgideps/blob/master/runtime/pom.xml > > As you can see I used the following persistence API bundle: > <groupId>org.apache.aries.jpa.javax.persistence</groupId> > <artifactId>javax.persistence_2.1</artifactId> > <version>2.7.0</version> > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
