Gradle взорвать почтовый индекс в buildDir

Question

Мой проект имеет удаленную зависимость, которая на самом деле представляет собой просто почтовый индекс определенных файлов, который необходимо где-то разархивировать, чтобы сборка могла генерировать новые исходные файлы Java из файлов. (Я говорю в общих чертах, чтобы сосредоточиться на основной проблеме, а не на специфике)

Я бы не ожидал, что это будет так сложно, но я не смог заставить его работать. Вот что я создал:

Я определил новую конфигурацию:

configurations {
    newConf
}

Позже я определил одну зависимость для этой конфигурации. Это разрешает к почтовому файлу, который мне нужно взорвать:

dependencies {
    newConf "group:name:version@zip"
}

Пока что все это пахнет правильно, хотя, если кто-то не согласен, я слушаю.

Наконец, мне нужно определить задачу, которая разбивает почтовый индекс в каталог, который затем становится входом для более поздней команды генерации кода.

task explodeModel {
    description = "unzip model into the specified 'modelSrc' directory"

    //input is a "files" collection (usually just one:  the zip)
    //output is the specified modelSrc dir

    File modelSrc = new File("$buildDir/modelSrc")
    outputs.files modelSrc

    doLast {
        configurations.newConf.allArtifacts.each { artifact -> println artifact }
    }

}

Очевидно, что doLast еще ничего не разархивирует, я просто пытаюсь получить абсолютный путь к самому zip-файлу, и вот где я застрял. Я понятия не имею, как получить путь к файлу, чтобы я мог распаковать его. Любая помощь?

Большое спасибо

Answer 1

Попробуйте что-нибудь в этом духе, оно должно работать:

task explodeModel(type: Copy){
  configurations.newConf.filter { it.toString().endsWith(".zip") }.each{
    from zipTree(it)
  }
  into 'output/dir'
}

Конечно, вы можете опустить фильтрующую часть .zip, если вы уверены, что артефакты в конфигурации - это zips.

Answer 2

Я сделал нечто подобное в плагине, который я написал.Это должно работать для вас:

configurations.newConf.singleFile

Предполагается, что есть только один файл.Тип возвращаемого значения java.io.File.Для получения дополнительной информации проверьте этот класс GaePlugin.groovy .Метод релевантности configureDownloadSdk.Задача, которая выполняет распаковку: GaeDownloadSdkTask.groovy .

Answer 3

Вот что я делал в последнее время, и я был счастлив с этим:
(В этом примере предполагается, что конфигурация называется zipFiles и включает только ZIP-файлы.)

ext.unpackedZipFiles = fileTree("$buildDir/unpackedZipFiles") { builtBy 'unpackZipFiles' }
task unpackZipFiles(type: Copy) {
    from configurations.zipFiles.files.collect { zipTree(it) }
    into unpackedZipFiles.dir
}

---

Подробнее

В этом подходе мне нравится несколько вещей:

1. Вместо магической строки "$buildDir/unpackedZipFiles", разбросанной по всей сборке, результат распаковки представлен фактическим FileTree. Это делает использование вывода в будущих копируемых задачах довольно простым:

   aCopyLikeTask(type: Copy) {
       from unpackedZipFiles
       // ...
   }
   

2. Задачи, которые используют разархивированные файлы, не зависят напрямую от задачи, которая разархивирует файлы. Скорее они зависят от самого FileTree, который знает, как распаковать файлы. Обратите внимание, что FileTree расширяет Buildable, и поэтому может зависеть от задачи:

   aNonCopyTask(dependsOn: unpackedZipFiles) << {
       // ... do stuff that references unpackedZipFiles.dir
   }
   

3. Project.fileTree() фактически возвращает ConfigurableFileTree, поэтому мы можем указать одну или более задач, на которых она построена. Этот интерфейс также обеспечивает File корня дерева через свойство dir, что часто удобно. Например:

   myExecTask(dependsOn: unpackedZipFiles) << {
       "${unpackedZipFiles.dir}/bin/runMe".execute([], unpackedZipFiles.dir)
   }
   

Answer 4

Мое решение (адаптированное к нашему коду) было бы что-то вроде

task explodeModel(type: Copy) {
    configurations.newConf.resolvedConfiguration.resolvedArtifacts.each { artifact ->
        if (artifact.file.name.endsWith('.zip')) {
            from zipTree(artifact.file)
            into '.'
        }
    }
}

Преимущество этого решения в том, что оно работает против разрешенных (в отличие от запрошенных ) артефактов.