Добавьте зависимость к Задаче linuxPackageMapping в Sbt-Native-Packager (sbt 1.2) - PullRequest
Новая
       21

Добавьте зависимость к Задаче linuxPackageMapping в Sbt-Native-Packager (sbt 1.2)

0 голосов
/ 15 января 2019

Я пытаюсь построить rpm с помощью собственного плагина упаковщика, который содержит файлы, созданные с помощью пользовательской задачи обработки файлов с использованием sbt 1.2.7.

То, как я изначально это делал, было processFiles.value вызовом в одном из моих обновлений linuxPackageMapping 

    Rpm / linuxPackageMappings += {
      val postDir = (Compile / processFiles / target).value
      val pfiles = (Compile / processFiles).value
      val profile = profileData.value
      val myDir = postDir / "tango"
      val files =  myDir * "*" filter { _.isFile }
      // Create packageMapping here
    }

Это работало нормально, но я заметил, что на самом деле я не использовал pfiles. Я позаботился о том, чтобы он запустился, так что postDir заполняется, но, поскольку я выполнял поиск файлов, чтобы фактически извлечь нужные мне файлы, мне показалось излишним его там (и во многих других местах кода, где эта картина была повторена). Поэтому я решил быть умным и преобразовать это в один. настройка более высокого уровня. 

linuxPackageMappings := (linuxPackageMappings.dependsOn(Compile / processFiles)).value,
Rpm / linuxPackageMappings := ((Rpm / linuxPackageMappings).dependsOn(Compile / processFiles)).value,

Из моего понимания документов это должно привести к запуску (Compile / processFiles) до того, как что-то произойдет в linuxPackageMappings.

Я подтвердил с помощью печатных операторов, что этого не происходит. Выполнение rpm:packageBin после clean приводит к генерированию RPM, в котором отсутствуют выходные данные задачи processFiles. Переменная files в приведенном выше фрагменте пуста. Если я затем снова выполню ту же задачу, новые обороты будут иметь выходные данные. Ручная проверка выходного каталога процесса после первого запуска rpm:packageBin показывает, что файлы там. Так что это срабатывает, но не совсем скоро в процессе это выглядит.

Задача processFiles использует FileFunction.cached, чтобы предотвратить ее повторный запуск, но не имеет какой-либо явной потоковой обработки (что может привести к ее параллельному выполнению).

Я могу обойти эту проблему, вставив вызов (Compile / processFiles).value обратно во все linuxPackageMapping вызовы, которые нуждаются в его выводе, но я бы предпочел, чтобы график задач работал правильно.

...