2014-12-02 6 views
0

Я пишу пользовательскую задачу Gradle (на Java) с использованием подхода buildSrc. Я хотел бы задачу на самом деле самонастройки контекста Spring основного модуля, так что класс пользовательских задач выглядит примерно так:Gradle: доступ к классам проектов и зависимостям от пользовательской задачи

buildSrc/main/java/CustomTask.java:

import org.gradle.api.DefaultTask; 
import org.gradle.api.tasks.TaskAction; 
import org.springframework.context.ApplicationContext; 
import org.springframework.context.support.ClassPathXmlApplicationContext; 
import org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean; 

public class CustomTask extends DefaultTask { 

    @TaskAction 
    public void run() { 
     ApplicationContext context = new ClassPathXmlApplicationContext("core-context.xml"); 
    } 
} 

Однако задача не может скомпилировать из-за Spring не является доступный. Весна - это, конечно, компиляция зависимости основного модуля.

Каков наилучший способ рассказать Gradle о том, что исходный набор buildSrc зависит от исходного набора модуля? (Идеально таким образом, чтобы не требовалось дублировать объявления зависимостей).

+0

Что именно вы подразумеваете под «Я бы хотел, чтобы задача фактически загрузила контекст Spring для основного модуля»? Какова цель задачи? –

+0

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

ответ

0

Невозможно добавить скомпилированный код основной сборки в путь класса buildscript, поскольку путь этого класса сконструирован до выполнения любой задачи (например, compileJava). Вместо этого вы можете реализовать решение, основанное на загрузчике классов, которое заполнено, скажем, sourceSets.main.runtimeClasspath. Как правило, CustomTask не знал бы об этом, но получил бы с настройкой с соответствующей дорожкой класса.

+0

Ничего себе. Я добавил Spring & Hibernate к buildSrc/build.gradle, и мне удалось захватить основной путь к исходному набору runtimeClasspath в plugin apply(). Другими словами, я использовал менее идеальное решение для проблемы компиляции, и теперь я столкнулся с проблемой времени выполнения. Нет ли другого способа добавить исполняемый файл сценария проекта к скрипту/заданию сборки, кроме пользовательского загрузчика классов? –

+0

Кроме того, вы можете запускать код в отдельной JVM. Это, вероятно, не проще, но безопаснее, так как нет риска заразить JVM Gradle (daemon) (утечки памяти и т. Д.). Класс загрузчик, заполненный с помощью 'sourceSets.main.runtimeClasspath', уже будет содержать Spring и Hibernate, если они объявлены как зависимости в основной сборке. –

+1

Подумайте об этом, не можете ли вы просто добавить основной класс в основную сборку, которая делает то, что вы хотите, и запустить ее с помощью задачи «JavaExec»? Это кажется намного проще. –

Смежные вопросы