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:
dependencies with embedded JAR in them;
same packages contained by different dependencies.
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.
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.
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.
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.