Avoiding Dynamic-Import *?

[jecalvert]

Does anyone have any insight on OSGi bundling tooling to avoid this sort of catch-all setting? I am using the Maven-bundle-plugin from org.apache.felix to generate my MANIFEST. However, I keep having to track the real packages needed in the build file and that's frankly annoying. It misses a lot. For instance:

I have an application that uses Spring to construct a javax.sql.DataSource object. Pretty standard. The DataSource clearly gets wired up with the Driver class name. In this case it is Postgres, and I accordingly have a Postgres dependency in my POM file marked as a runtime dependency. Yet in the generated MANIFEST is no mention of org.postgresql package. Thus when I drop my JAR into Fuse ESB, blueprint kicks off, starts initializing everything and then Boom the DataSource blows up with a ClassNotFound.

These types of things become irritating. It's really easy for a plugin to look and see what you are actually importing in your Java code and add those packages to your manifest, but any situation where classes are loaded by name or specified in configuration ALA Spring, these dependencies get glossed over. It's sort of double irritating, because part of the point is that it's nice that the code has no direct dependencies on Postgres, and you have the notion that you could just drop in a new library and change your beans.xml and use Oracle.

Or am I just being too picky and I should be quiet and embrace Dynamic-Import? (Which OSGi people typically condemn)

[davsclaus]

I think I have heard somewhere the bundle plugin would be / or is capable of scanning the Spring XML files and detect usages of 's. I may be mistaking.

In terms of JDBC drivers, you can attach those as a OSGi bundle fragment to your bundle, which means the JDBC driver would be fully available to your bundle.

[jecalvert]

The bundle plugin mostly gets it right, but there are inevitably some secondary and tertiary type dependencies that get missed. Then again, to be an apologist, the reason is because for so long there have been so many developers which have used "Stupid ClassLoader Tricks" (I am guilty of this sin myself).

Regardless, I feel as if there is some piece of the puzzle that I am missing.

For instance, I have a service, exposed via JAX-RS on CXF. It has an 'operations' class that wraps some entity business logic. The operations class imports a DAO from a bundle that contains Hibernate entities. The DAO exposes a way for you to pass in a string which is executed as HQL. Sounds pretty straightforward! However, running it, BAM there is a ClassNotFound on org.hibernate.hql.ast.somethingorother. Well that doesn't make sense, Hibernate is imported...I get the error to go away by doing dev:dynamic on the CXF bundle. That seems terribly terribly wrong.