Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If you end up with a huge exclude list, you should probably take that as an indication that something isn't right with your build process and the bundle. </p> <p>If it was me, the first thing I'd do is crack open your bundle and have a look at what classes it includes, and what packages it exports. I suspect you've got a pretty massive bundle, which means your bundle's dependencies are going to be pretty extensive. This means you lose a lot of the modularity benefits of OSGi, and it can cause a lot of practical problems too. </p> <p>Any time you declare a package to be optional, you're saying 'I'm happy to accept ClassDefNotFoundExceptions for classes in this package.' For your code you can probably know if a package genuinely is optional, but it's pretty tricky to guess which packages used by a third party are optional. This, of course, is why pre-bundleised jars are more convenient, but I realise this isn't much help to you. :)</p> <p>What you're doing by embedding the third party library is bundleising it, but in a way which isn't so reusable. (The other difference is that it will share a classloader with the embedding bundle, which could make things work a lot better if the third party library tries to load your classed by reflection, for example.) Since you're having problems with the dependencies, I'd be inclined to take the hit of adding a build step which wraps the third party jar, so that you can clearly see what classes and dependencies relate to your code, and which to this extra jar.</p> <p>The other thing I'd look at is your export package=* clause. This will export every package on your classpath, which means all those packages get built into your jar. And you get all their package imports, too. Your poor bundle becomes a whole application, rather than the lean OSGi module you were hoping for. You should restrict your exports to the bare minimum (you want to keep your innards private, and you definitely don't want to be sharing everyone else's innards).</p> <p>--</p> <p>Enterprise OSGi in Action: <a href="http://www.manning.com/cummins" rel="nofollow">http://www.manning.com/cummins</a> </p>
    singulars
    1. This table or related slice is empty.
    1. POProblems with maven built OSGi including dependencies
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USHolly Cummins
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COThank your for the clarification. I already narrowed down the `Export-Package` to the essential. What I did not fully understand was your suggestion "[…] take the hit of adding a build step which wraps the third party jar, so that you can clearly see what classes and dependencies relate to your code, and which to this extra jar." -- could you elaborate on this?
      singulars
      1. PO
      1. USqqilihq
    2. COThere are a few ways to do this, but most use the same mechanism which the maven bundle plugin is using under the covers, bnd. You can download bnd as a command line tool and then just call 'bnd wrap [yourjar]', with an optional bnd file to refine things like bundle name, imports, and exports. Alternatively you can use maven to do it (google 'maven bundle wrap goal'). These should both give you, pretty darn quickly, a version of your jar with OSGi metadata. Then you can look inside, confirm that you've only dragged in classes from the jar itself, and check the package imports are sensible.
      singulars
      1. PO
      1. USHolly Cummins
    3. COHolly, sorry for the late response and thank you for your hint. Very appreciated!
      singulars
      1. PO
      1. USqqilihq
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload