Управление зависимостями с приложениями Play 2.0

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

Мы считаем, что структура Play очень привлекательна для разработки веб-приложений. Рамка отличная, но управление зависимостями для наших локально разработанных библиотек несколько раздражает. Мы используем RC2 в Play 2.0, и хотя мы можем получать изменения в наших библиотеках, загруженных в Play, это, безусловно, неудобный процесс, который прерывает нормально гладкий процесс воспроизведения.

То, что мы делаем, - это подталкивание наших библиотек к нашему локальному (на каждом компьютере разработчиков) репозиторию Maven, а затем импорт этих же библиотек обратно в проект Play. Это работает, но, как я уже сказал, это неудобно.

Есть ли какие-то лучшие практики, которые мы должны использовать, которые сделают эту работу более плавно?

Я получаю хорошие ответы о том, как улучшить процесс сборки Maven, и я ценю это. Однако это не совсем тот ответ, который я ищу.

Чтобы сделать это конкретным, предположим, что я создаю как службу, так и веб-приложение для мониторинга/управления службой. Служба представляет собой простой проект Java/ Scala, а веб-приложение - это игра! проект. Мы будем называть эти "Сервис" и "Приложение". (Пожалуйста, не задирайте эту предложенную структуру, я упрощаю ее для целей вопроса)

В Eclipse или IntelliJ я могу добавить модуль "Service" (или Project for Eclipse) в качестве зависимости от проекта "App". Это позволяет очень быстро работать с разработчиками при внесении изменений в библиотеку "Сервис" (например, я добавляю свойство модели). Перекомпилировать и запустить на несколько порядков быстрее, чем компилировать, упаковывать, развертывать, импортировать и перезагружать браузер.

Основываясь на моем чтении документации Play 2.0 и SBT, мой единственный реальный ответ - сделать "Сервис" субпроектом "Приложения". Есть ли лучший ответ на этот вопрос?

Ответы

Ответ 1

У вас есть 2 варианта.

Первый, как сказал Rich, является локальным репозиторием. Это не означает, что локальная папка на вашем компьютере-разработчике maven создается как локальный кеш, и вы используете. Это означает, что центральный сервер в вашей локальной сети, где вы сохраняете версии приложений для воспроизведения для последующего извлечения. Nexus, как рекомендовано Rich, это отличный вариант.

Второй вариант - просто создать свои банки и развернуть их как неуправляемые библиотеки в папке "lib" . Затем вы можете зафиксировать это в своей системе управления версиями, и все разработчики будут иметь то же самое.

Я рекомендую первый подход, гораздо лучший долгосрочный, но это ваш выбор.

ИЗМЕНИТЬ КОММЕНТАРИЙ вы говорите, что не хотите управлять зависимостями. Единственный третий сценарий, который я могу себе представить, это то, что вы хотите, чтобы весь код был блоком. В этом случае вы можете использовать subprojects. Я не вижу других альтернатив.

Ответ 2

Вам следует нажать на локальное зеркало/прокси Maven, например Nexus.

Ответ 3

Игра действительно вызывает большой интерес в большинстве случаев. Но есть один случай, когда Play не может быть лучшим решением, именно проблема, о которой вы указываете: когда есть другие компоненты, libraires должны быть интегрированы в приложение.

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