Как модулировать (большое) Java-приложение?

Question

У меня есть довольно большое (несколько MLOC) приложение, которое я хотел бы разделить на более удобные для обслуживания отдельные части. В настоящее время продукт включает около 40 проектов Eclipse, многие из которых имеют взаимозависимости. Это само по себе делает систему непрерывной сборки неосуществимой, потому что она должна была бы очень много перестраиваться при каждой регистрации.

Есть ли способ "наилучшей практики", как

• идентифицирует части, которые могут быть немедленно отделены
• визуально взаимозависимости документов
• распутать существующий код
• обрабатывает «патчи», которые мы должны применить к библиотекам (в настоящее время обрабатывается путем помещения их в classpath перед фактической библиотекой)

Если есть (свободные / открытые) инструменты для поддержки этого, я был бы признателен за указатели.

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

Изменить 2009-07-10

Мы находимся в процессе разделения некоторых основных модулей, используя Apache Ant / Ivy . Действительно полезный и хорошо продуманный инструмент, не навязывающий вам так много, как Maven.

Я записал некоторые более общие подробности и личное мнение о том, почему мы делаем это в моем блоге - слишком долго, чтобы публиковать здесь и, возможно, не всем интересно, поэтому следуйте по своему усмотрению: www.danielschneller.com

Answer 1

Использование OSGi может подойти вам. Это позволило бы создавать модули вне приложения. Вы также можете организовать зависимости лучше. Если вы правильно определяете свои интерфейсы между различными модулями, вы можете использовать непрерывную интеграцию, поскольку вам нужно только перестроить модуль, который вы затронули при регистрации.

Механизмы, предоставляемые OSGi, помогут вам распутать существующий код. Благодаря тому, как работает загрузка классов, это также помогает вам легче обрабатывать исправления.

Некоторые концепции OSGi, которые кажутся вам подходящими, как показано в википедии:

Структура концептуально разделена на следующие области:

• Связки - Связки - это обычные компоненты jar с дополнительными заголовками манифеста.
• Службы - уровень служб динамически соединяет пакеты, предлагая модель «публикация-поиск-привязка» для простых старых объектов Java (POJO).
• Реестр сервисов - API для сервисов управления (ServiceRegistration, ServiceTracker и ServiceReference).
• Жизненный цикл - API для управления жизненным циклом (установка, запуск, остановка, обновление и удаление пакетов).
• Модули - уровень, который определяет инкапсуляцию и объявление зависимостей (как пакет может импортировать и экспортировать код).
• Безопасность - уровень, который обрабатывает аспекты безопасности, ограничивая функциональность пакета предварительно определенными возможностями.

Answer 2

Первое: удачи и хорошего кофе. Вам понадобятся оба.

Однажды у меня была похожая проблема. Устаревший код с ужасными циклическими зависимостями, даже между классами из разных пакетов, таких как org.example.pkg1.A, зависит от org.example.pk2.B и и наоборот.

Я начал с maven2 и новых проектов Eclipse. Сначала я попытался определить наиболее распространенные функции (уровень ведения журнала, общие интерфейсы, общие службы) и создал maven проекты. Каждый раз, когда я был доволен частью, я развертывал библиотеку в центральном хранилище Nexus, чтобы она была почти сразу доступна для других проектов.

Так что я медленно проработал слои. maven2 обрабатывает зависимости, а плагин m2eclipse предоставляет полезное представление зависимостей. Кстати, обычно не так уж сложно преобразовать проект Eclipse в проект Maven. m2eclipse может сделать это за вас, и вам просто нужно создать несколько новых папок (например, src / main / java) и настроить путь сборки для исходных папок. Занимает всего минуту или две. Но ожидайте больше трудностей, если ваш проект представляет собой плагин eclipse или приложение rcp, и вы хотите, чтобы maven не только управлял артефактами, но и создавал и развертывал приложение.

По мнению, затмение, Maven и Nexus (или любой другой менеджер хранилища Maven) являются хорошей основой для начала. Вам повезло, если у вас есть хорошая документация по архитектуре системы и , эта архитектура действительно реализована;)

Answer 3

У меня был похожий опыт в небольшой кодовой базе (40 клоц). Нет правил ° ":

• скомпилировано с и без «модуля», чтобы увидеть его использование
• Я начал с "листовых модулей", модулей без других зависимостей
• Я обработал циклические зависимости (это очень подверженная ошибкам задача)
• с maven есть много документации, которая может быть развернута в вашем процессе CI
• с помощью maven вы всегда можете увидеть, что использует то и другое на сайте и в netbeans (с
  очень хороший ориентированный граф)
• с помощью maven вы можете импортировать библиотечный код в вашу кодовую базу, применять исходные патчи и компилировать с вашими продуктами (иногда это очень легко, иногда это очень трудно)

Проверьте также анализатор зависимостей:
_{(источник: javalobby.org )}

Netbeans:

_{(источник: zimmer428.net )}

Answer 4

Первое, что вам нужно решить, это то, к какой инфраструктуре вы будете двигаться. Если это будет много независимо поддерживаемых модулей (что переводится в отдельные проекты Eclipse), или вы будете считать это отдельным фрагментом кода, который версионирован и развернут в целом. Первый хорошо подходит для перехода в среду сборки, похожую на Maven, а второй - для одновременного использования всего исходного кода.

В любом случае вам потребуется работающая система непрерывной интеграции. Ваша первая задача - сделать сборку кода автоматически, чтобы вы могли позволить своей системе CI следить за вашим исходным хранилищем и перестраивать его, когда вы что-то измените. Я выбрал здесь подход, отличный от Maven, и мы сосредоточены на создании простой среды Eclipse, поэтому я создал среду сборки, используя файлы ant4eclipse и Team ProjectSet (которые мы используем в любом случае).

Следующим шагом будет избавление от циклических зависимостей - это упростит сборку, избавится от предупреждений Eclipse и в конечном итоге позволит вам перейти к этапу «оформить заказ, скомпилировать, запустить». Это может занять некоторое время :-( Когда вы переносите методы и классы, не перемещайте их, а извлекайте или делегируйте их и оставляйте их старое имя без присмотра и помечайте их как устаревшие. Это отделит ваше удаление от рефакторинга и разрешит код вне вашего проекта, чтобы по-прежнему работать с кодом внутри вашего проекта.

Вы получите пользу от исходного хранилища, которое позволяет перемещать файлы и хранить историю. CVS очень слаб в этом отношении.

Answer 5

Maven болезненно мигрировать на существующую систему. Тем не менее, он может справиться со 100+ модульными проектами без особых трудностей.

Answer 6

Это не бесплатно, но Structure101 даст вам столько же, сколько вы получите с точки зрения поддержки инструмента для удара по всем пунктам пули. Но для записи я предвзят, так что вы можете попробовать SonarJ и Lattix тоже. ; -)

Answer 7

Я бы не рекомендовал Maven для устаревшей базы исходного кода. Это может доставить вам много головной боли, если вы просто попытаетесь все адаптировать для работы с ним.

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