Оптимизация gradle для проекта spring-xd с временной зависимостью от scala

Я работаю над проектом, который содержит серию подпроектов модулей для Spring XD, которые имеют временную зависимость от немодульного подпроекта, который использует Scala:

ext {
  springXdVersion = '1.1.0.RELEASE'
  moduleProjects  = subprojects.findAll { project -> project.path.startsWith(':modules.')}
  javaProjects    = subprojects - (moduleProjects + nonJavaProjects)
}

configure(moduleProjects) { moduleProject ->
  apply plugin: 'spring-xd-module'
}

project('core-dependency') {
  apply plugin: 'scala'
  // configuration/dependencies
}

project('modules.source.example') {
  dependencies {
    provided(":core-dependency")
  }
}

// More modules bearing resemblance to modules.source.example

Core-dependency в конечном итоге устанавливается в пути к классам нашего xd-контейнера и таким образом предоставляется модулям во время выполнения.

К сожалению, кажется, что для каждого модуля, который его использует, зависимость от ядра перекомпилируется (что особенно дорого, поскольку оно также включает компиляцию scala). Это приводит к тому, что сборка выполняется к северу от 30 минут, что я хотел бы улучшить. Есть ли способ сократить время сборки? В идеале я бы не хотел перекомпилировать зависимость от ядра, но я не уверен, как это сделать, учитывая, что bootRepackage, по-видимому, отвечает за его запуск для каждого модуля. Я также пробовал другие приемы, такие как параллелизм, но пока это только заморозило мою систему. Я использую Gradle 2.1.

Я должен отметить, что в отчете профиля gradle указано, что для каждого модуля большая часть времени уходит на этап configureModule, который, согласно репозиторию spring-xd, выглядит следующим образом:

project.task('configureModule') << {
            project.configurations.provided.resolvedConfiguration.firstLevelModuleDependencies.each {
                excludeTransitiveDependencies(project, it)
            }
        }

gradle scala spring-xd
person Brandon McKenzie    schedule 28.05.2015    source источник
comment
У меня может быть рабочее решение: я создал конфигурацию с именем core и установил компиляцию для ее расширения (что означает, что она будет скомпилирована вместе с предоставленной областью). Поскольку моя основная зависимость больше не будет предоставляться, она не будет задействована в excludeTransitiveDependencies задачи configureModule. Это сократило мою сборку с 35 минут до 2 минут. Сейчас тестирую свои артефакты на работоспособность.   -  person Brandon McKenzie    schedule 28.05.2015
comment
К сожалению, это имело побочный эффект упаковки моих модулей с этой основной зависимостью и ее зависимостями, что лишало цели.   -  person Brandon McKenzie    schedule 28.05.2015
comment
configurations.exported.exclude module: 'core-dependency' смог исправить проблему в этом последнем комментарии. Экспортируемая конфигурация представлена ​​плагином spring-xd-modules, который используется для определения того, что входит в файл fatjar.   -  person Brandon McKenzie    schedule 29.05.2015

Ответы (2)


arrow_upward
0
arrow_downward

Зависимость от scala исходит из Spark streaming интеграции в SpringXD. Мы работаем над устранением зависимости искры от spring-xd-dirt и обслуживаем ее из модуля:

https://jira.spring.io/browse/XD-2857

От какого конкретного немодульного подпроекта вы зависите? Если это spring-xd-module, то вы можете попробовать 1.2.0.M1, где мы переместили искровую зависимость с spring-xd-module на spring-xd-dirt.

person Ilayaperumal Gopinathan    schedule 28.05.2015
comment
Подпроект является внутренней зависимостью; подпроект, состоящий из разработанных внутри инструментов, обычно используемых между нашими модулями. - person Brandon McKenzie; 28.05.2015

arrow_upward
0
arrow_downward

На этапе configureModule все проекты оцениваются на наличие транзитивных предоставленных зависимостей, которыми была core-dependency. Замедление было вызвано огромным количеством зависимостей, от которых зависит core-dependency и, следовательно, требует сканирования. Поскольку мы хотим избежать сканирования зависимости от ядра с помощью configureModule, потому что это слишком затратно по времени, и мы знаем, что его необходимо исключить из фатжаров модулей, соответствующий курс действий — удалить зависимость от ядра из предоставленной конфигурации и просто исключаем его из жирной банки сами.

Для этого скрипт сборки gradle модифицируется следующим образом:

ext {
  springXdVersion = '1.1.0.RELEASE'
  moduleProjects  = subprojects.findAll { project -> project.path.startsWith(':modules.')}
  javaProjects    = subprojects - (moduleProjects + nonJavaProjects)
}

configure(moduleProjects) { moduleProject ->
  apply plugin: 'spring-xd-module'

  configurations{
    core
    compile.extendsFrom(core)
  }

configurations.exported.exclude module: 'core-dependency'
}

project('core-dependency') {
  apply plugin: 'scala'
  // configuration/dependencies
}

project('modules.source.example') {
  dependencies {
    core project(":core-dependency")
  }
}

// More modules bearing resemblance to modules.source.example

«Основная» конфигурация, по сути, является второй «предоставленной» конфигурацией, которая не будет выбрана задачей configureModule, что позволяет избежать траты времени на ее оценку. Он также исключен из «экспортируемой» конфигурации, содержимое которой определяет, что попадает в толстую банку, которую создает bootRepackage.

person Brandon McKenzie    schedule 29.05.2015