Проблема сборки сборки OSGi в Gradle

Question

У меня есть простой пример построения пакета OSGi с использованием инструмента построения Gradle. Сборка успешно, если в пути сборки есть Java-файлы, но в противном случае это не сработает.

Я использую плагин «osgi» внутри сценария градиента и пытаюсь построить без каких-либо java-файлов. Сборки всегда терпит неудачу с ошибкой при слежении:

Не удалось скопировать MANIFEST.MF в

Я уверен, что должен быть какой-то способ сделать это в Gradle, но не в состоянии точно. Любая идея, что можно сделать для решения этой проблемы в зависимости от вашего опыта.

Answer 1

Запуск с --stacktrace указывает, что osgi плагин не правильно иметь дело со случаем, когда применяются оба osgi и java плагинов, но нет кода Java нет. Удаление плагина java должно решить проблему.

Answer 2

Я столкнулся с этим и сегодня, и исправление @ Peter не сработало для меня (я не применил Java-плагин в первую очередь ...). Однако после нескольких часов работы в Гуглинг я нашел this thread, что помогло мне найти проблему.

В основном, это, кажется, что происходит ошибка (as Peter stated), когда никакие файлы классов не будут найдены в банке - я думаю, потому что плагин, то не может сканировать классы для имен пакетов, на основе которых можно все Import и Export информацию.

Моего решения было добавить следующий манифест спецификации:

classesDir = theSourceSet.output.classesDir 
classpath = theSourceSet.runtimeClasspath 

В моей фактической коде сборки, я перебираем все источниками устанавливает для создания jar задач для них, так, то это выглядит следующим образом:

sourceSets.each { ss -> 
    assemble.dependsOn task("jar${ss.name.capitalize()}", type: Jar, dependsOn: ss.getCompileTaskName('Java')) { 
     from ss.output 
     into 'classes' 

     manifest = osgiManifest { 
      classesDir = ss.output.classesDir 
      classpath = ss.runtimeClasspath 
      // Other properties, like name and symbolicName, also set based on 
      // the name of the source set 
     } 

     baseName = ss.name 
    } 
} 

Answer 3

У меня была такая же проблема и при наличии Java-кода. Добавление этих двух линий к закрытию osgiManifest исправили проблему:

classesDir = sourceSets.main.output.classesDir 
classpath = sourceSets.main.runtimeClasspath   

- Erik