title: Is javac enough to build an OSGi bundle?
body: <p>To produce a bundle from source using a tool such as javac, you need to provide it with a linear classpath. Unfortunately, it won't work in some situations still perfectly legal from an OSGi point of view:</p>
  
  <ul>
  <li><p>dependencies with embedded JAR in them;</p></li>
  <li><p>same packages contained by different dependencies.</p></li>
  </ul>
  
  <p>Since javac doesn't understand OSGi metadata, I won't be able to simply but the dependencies in a classpath. A finer package grained approach seems necessary.</p>
  
  <p>How this problem is addressed by people using OSGi in an automated process (continuous integration)? Strangely, there is a lot of resources on the web on how to create bundle JAR (creating the metadata, creating the JAR) provided you have the classes/inner JAR to put inside, but very few things on how actually get theses classes compiled.</p>
  
  <p>Let's take an example: my bundle need two other bundles to compile, both contains Xerces as an embedded JAR but in two different and incompatible versions. It is not a problem since only one of them export some packages of xerces my bundle is in turn importing. Not a very clean situation maybe but something that could "legaly" happen in an OSGi container without problem.</p>
  
  <p>Now, how can I compile it ? I can't put the two dependencies in my classpath (the embedded Xerces JAR won't be found by javac), I can't flatten then either (the two versions of Xerces will collide and maybe the one not exported would be first). If the ony solution is to create a "classpath" on a package level, not on a full bundle scale, javac is not usable at all.</p>