Estoy en el proceso de refactorizar una aplicación Java para usar OSGi. Una característica de la aplicación es la compilación de Java sobre la marcha usandojavax.tools.JavaCompiler. En la aplicación original, este proceso funcionó alimentando al compilador con el classpath existente, así.

JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
String[] options = {"-classpath", System.getProperty("java.class.path")};
DiagnosticListener<JavaFileObject> listener = new DiagnosticListener<JavaFileObject>() {...};
StandardJavaFileManager fileManager = compiler.getStandardFileManager(listener, null, null);
Iterable<? extends JavaFileObject> fileObjects = fileManager.getFileObjects(sourceFile);
CompilationTask task = compiler.getTask(null, fileManager, listener, Arrays.asList(options), null, fileObjects);
task.call();

Sin embargo, esto no funcionará en un paquete OSGi ya que classpath ya no contiene las rutas necesarias. En la versión OSGi refactorizada de la aplicación, el compilador necesita acceso a las clases que están dentro del mismo paquete que el código anterior, así como a las clases de otros paquetes. ¿Cómo hago para que el compilador conozca estas clases?

He pensado en dos posibles soluciones:

Proporcione al compilador el cargador de clases utilizado por el paquete que contiene el código anterior, ya que conoce todas las clases necesarias. Sin embargo, esto no parece una solución viable de lo que he leídoaqu yaqu. Cree el classpath usando las ubicaciones físicas de los paquetes instalados. He mirado aorg.osgi.framework.Bundle.getLocation() pero no estoy seguro de si esta sería una solución confiable. Las rutas que recupero (al menos al implementar dentro de Eclipse) son relativas y no estoy seguro de si serían seguras de usar en todas las plataformas y situaciones.

¿Parece posible la opción dos anterior? ¿Hay una mejor solución?