Is javac enough to build an OSGi package?

To build a package from source using a tool like javac, you need to provide it with a linear classpath. Unfortunately, it won't work in some situations that are perfectly legal from an OSGi perspective:

• dependencies with embedded JARs in them;

• the same packages that are contained in different dependencies.

Since javac doesn't understand OSGi metadata, I can't just but the dependencies in the classpath. It seems like a more subtle approach to batch processing is needed.

How is this problem solved by people using OSGi in an automated process (continuous integration)? Funnily enough, there are many resources on the internet on how to create a JAR package (metadata generation, JAR generation) assuming you have the classes / internal JAR to inject internally, but very little on how to actually get the class classes compiled.

Let's take an example: my package needs two other packages to compile, both contain Xerces as an embedded JAR, but in two different and incompatible versions. This is not a problem as only one of them exports some xerces packages, which my package in turn imports. Perhaps not a very clean situation, but something that can "finish" in an OSGi container without issue.

Now how can I compile it? I cannot put two dependencies in my classpath (the built-in Xerces JAR will not be found by javac), then I cannot flatten out (the two versions of Xerces will collide, and maybe the one that was not exported will be the first one) the solution is to create a "classpath" at the package level, not package-wide, javac is not used at all.