Estou no processo de refatoração de um aplicativo Java para usar o OSGi. Um recurso do aplicativo é a compilação Java on-the-fly usandojavax.tools.JavaCompiler. No aplicativo original, esse processo funcionava, alimentando o compilador com o caminho de classe existente, assi

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();

No entanto, isso não funcionará em um pacote OSGi, pois o caminho de classe não contém mais os caminhos necessários. Na versão OSGi refatorada do aplicativo, o compilador precisa acessar as classes que estão dentro do mesmo pacote configurável que o código acima, bem como as classes de outros pacotes configuráveis. Como conscientizo o compilador sobre essas classe

Pensei em duas soluções possíveis:

Dê ao compilador o carregador de classes usado pelo pacote que contém o código acima, pois ele conhece todas as classes necessárias. No entanto, isso não parece uma solução viável do que eu liAqu eAqu. Crie o caminho de classe usando os locais físicos dos pacotes configuráveis instalados. Eu olhei paraorg.osgi.framework.Bundle.getLocation() mas não tenho certeza se isso seria uma solução confiável. Os caminhos que recebo de volta (pelo menos ao implantar no Eclipse) são relativos e não tenho certeza se eles seriam seguros para uso em todas as plataformas e situaçõe

A opção dois acima parece possível? Existe uma solução melhor