Опубликовать бомбу из мультимодульного проекта

Мы являемся крупной компанией с примерно 2000 отдельными проектами Java. По историческим причинам у нас нет мультимодульных проектов, но мы хотели бы представить их.

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

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

Итак, вкратце, нам нужна спецификация, которая содержит версии всех 50 проектов, которые являются частью многомодульного проекта. Интересно, каким будет "путь Maven" для создания такой спецификации. О чем я могу думать:

  • Бом - это 51-й проект мультимодульного проекта. Версии зависимостей задаются свойствами родительского pom.
  • Бом генерируется из информации, присутствующей в многомодульном проекте и публикуется как побочный артефакт (для этого, вероятно, требуется написать плагин Maven для этого).

Что было бы целесообразно?

ОТВЕТЫ

Ответ 1

Мы также используем спецификации для наших проектов с несколькими модулями, но мы не связываем их создание или обновление с сборкой этих модулей.

Спецификация только обновляется, когда наш процесс управления выпуском завершает доставку встроенного модуля (или группы модулей): после доставки, затем спецификация обновляется и помещается в Nexus (сохраняется как версия 1.0-SNAPSHOT, постоянно переопределенная после каждой поставки)

Затем BOM включается в наш POM (для моно- или многомодульных проектов) и используется только для управления зависимостями, что означает, что наши проекты зависят от артефакта без версии: управление зависимостями из спецификации содержит самую последнюю версию другие зависимые модули.

Другими словами, мы разделяем аспект сборки (сделанный здесь с maven) из части выпуска: "спецификации материалов" представляют собой то, что было доставлено, и обеспечивают, чтобы все проекты строились с версиями, которые, как считается, хорошо работают вместе (поскольку они были поставлены в производство вместе).

Ответ 2

Я никогда не видел 2K коммерческих проектов Java, поэтому я буду основывать свой ответ на том, как работает open source:

  • Библиотеки не должны группироваться людьми - они должны быть сгруппированы по проблемам, которые они решают. Часто проекты с открытым исходным кодом имеют несколько библиотек, например. Джексон имеет jackson-databind, jackson-datatype-jsr310 и т.д. Эти библиотеки тесно связаны друг с другом и могут зависеть друг от друга.
  • Такие группы не должны быть слишком большими. Некоторые проекты могут иметь 1, другие - 5 или 10. 50 библиотек в группе слишком много звучат.
  • Легче, если libs в группе будут выпущены в одно и то же время (даже если обновляется только один). Это упрощает отслеживание версий в приложениях, которые используют несколько библиотек из группы.
  • Должна быть нет зависимостей между группами! И это, вероятно, самое важное правило. Глубокая иерархия библиотек, которые зависят друг от друга, неприемлема, потому что теперь вам нужно поддерживать совместимость между многими проектами и библиотеками. Это просто не масштабируется. Это означает, что между libs будет время от времени копировать-вставить код - это меньшее зло.
  • Могут быть некоторые исключения из последнего правила (возможно, lib, который используется повсюду), но они должны поддерживать обратную совместимость открытого API до тех пор, пока не будет проектов, которые зависят от старого API. Такие библиотеки очень трудно поддерживать, и лучше их открывать.

Автономные проекты теперь могут зависеть от библиотек из той же или разных групп, но поскольку версия внутри группы одинакова, легко установить ее как свойство только один раз. В качестве альтернативы:

  • Вы можете посмотреть <scope>import</scope>, который позволяет импортировать разделы <dependencyManagement> из других файлов POM, таких как родительские POM в группе (по какой-то причине мне никогда не приходило в голову).
  • Или в xxx-all modules - модуль, который зависит от всех других модулей внутри группы и, следовательно, когда вы зависеть от него, вы также зависите от других транзитивно.