ожусь в процессе рефакторинга Java-приложения для использования OSGi. Одной из особенностей приложения является компиляция Java на лету с использованиемjavax.tools.JavaCompiler, В исходном приложении этот процесс работал, передавая компилятору существующий путь к классу, вот так.

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

Однако, это не будет работать в пакете OSGi, так как путь к классу больше не содержит необходимые пути. В переработанной версии приложения для OSGi компилятору требуется доступ к классам, которые находятся в том же пакете, что и приведенный выше код, а также к классам из других пакетов. Как сделать так, чтобы компилятор знал об этих классах?

Я подумал о двух возможных решениях:

Дайте компилятору загрузчик классов, используемый пакетом, содержащим приведенный выше код, поскольку он знает обо всех необходимых классах. Тем не менее, это не похоже на жизнеспособное решение из того, что я прочиталВот а такжеВот.Создайте classpath, используя физические местоположения установленных пакетов. Я смотрел наorg.osgi.framework.Bundle.getLocation() но я не уверен, что это будет надежным решением. Пути, которые я получаю (по крайней мере, при развертывании в Eclipse), являются относительными, и я не уверен, будет ли их безопасно использовать на всех платформах и в любых ситуациях.

Второй вариант кажется возможным? Есть ли лучшее решение?