Расширение / наследование проектов Tomcat

Question

Мы разрабатываем веб-приложения с плагином Eclipse + Tomcat. Недавно мы запустили новое приложение, которое будет работать на Facebook и StudiVZ (конкурент FB в Германии). Поскольку функциональность приложения будет на 95% одинаковой, мы разделили код на отдельные проекты Eclipse (app-core, app-facebook, app-vz). Проект -core связан с исходным кодом в проектах -facebook и -vz в Eclipse. Мы также используем Hudson для CI и создали ant-скрипты, которые импортируют код из -core проекта перед сборкой. Таким образом, в основном мы пытались наследовать на уровне проекта.

Описанный метод имеет некоторые недостатки:

• Управление версиями сложное
• Проект -core не запускается автономно, что делает автоматическое тестирование частично невозможным
• Нам нужно изменить некоторые модели, в которых классы -core проектов зависят от
• Другие проблемы, которые заставляют меня думать, что это не лучшее решение

У кого-нибудь есть предложения по лучшему решению?

Answer 1

Для Java доступно множество инструментов сборки, специально предназначенных для управления зависимостями и управления версиями. Многие из них интегрируются с Hudson и Eclipse.

Я бы посоветовал взглянуть на Maven и узнать, как это делает управление зависимостями хорошей отправной точкой. Даже если вы не используете Maven , многие из существующих решений основаны на механизме управления зависимостями Maven. Что-то вроде Apache Ivy позволяет вам использовать управление зависимостями maven, но при этом использовать собственные скрипты Ant; тогда как что-то вроде Gradle является оптовой заменой.

Answer 2

Вы должны иметь возможность разделить ваш проект на 3 или более частей, а затем установить зависимости через Java Build Path.Вам необходимо очистить зависимости между проектами.Если вам необходимо настроить основные компоненты в зависимости от того, является ли это проектом -facebook или -vz, вам может потребоваться разделить конфигурацию, возможно, даже использовать Spring или аналогичную инфраструктуру внедрения зависимостей.

При попытке ввести повторное использованиев веб-проекты Java обычно возникают проблемы в коде пользовательского интерфейса.Не так много фреймворков было построено с учетом этого подхода.

Answer 3

Я не использую / ненавижу Eclipse [1], но могу указать, как мы имеем дело с подобной проблемой.

Мы используем Maven с IntelliJ. В частности, оба из них поддерживают модули , которые определили внутренние зависимости. В вашем случае это могут быть -fb и -vz модули в зависимости от core , или вы можете разделить ядро ​​на более мелкие части (например, DAO *). 1012 *, бизнес-логика и т. Д.).

При компиляции результаты «верхних» модулей будут использоваться для построения «нижних» модулей.

Давайте рассмотрим вопросы / недостатки, которые вы подняли:

• управление версиями больше не является проблемой, поскольку все находится под тем же корневым каталогом Subversion / GIT / VCS по вашему выбору
• Почему это проблема? Конечно, это не должно быть проблемой для модульных тестов, так как, как я понимаю, TDD не требует сложных сред. Для автоматизированных тестов вам придется тестировать API ядра (так как это интерфейс между ядром и всем остальным, верно?), Следовательно, для этого не требуется никаких дополнительных действий?

• вам нужно объяснить другие моменты, чтобы объяснить, почему вам это не нравится

  1. Запретить разработчикам использовать что-либо кроме IDE по своему выбору противозаконно.