Динамически добавлять зависимости в pom.xml во время компиляции, не нужно знать идентификатор и версию артефакта

Question

У меня есть проект A, который зависит от проекта I, который содержит интерфейсы, реализованные третьим проектом, B.

Я хочу, чтобы проект B динамически подключался к pom.xml проекта A во время компиляции, безизменение pom.xml A и предоставление свойств Maven из командной строки (пример

mvn package -Dmodule.artifactId=[B_ARTIFACTID] -Dmodule.version=[B_VERSION]

), где B_ARTIFACTID и B_VERSION относится к проекту B.

Цель состоит в том, чтобы пометитьверсия проекта A и через интерфейсы, содержащиеся в I, использовать реализацию, содержащуюся в четвертом проекте C, который реализует I с той же версией проекта A, просто меняя командную строку, которая его строит.

Iзнаю, что это возможно, используя свойства профиля, но в то время, когда проект A будет помечен, он не разрешит зависимость, как это исправить без использования зависимости по умолчанию?

B и C зависит от проекта, определяемого:

<groupId>project</groupId>
<artifactId>I</artifactId>
<version>0.1.0.0</version>

Проект A

<dependencies>
  <dependency>
    <groupId>project</groupId>
    <artifactId>I</artifactId>
    <version>0.1.0.0</version>
    <dependency>
      <dependency>
        <groupId>project</groupId>
        <artifactId>???</artifactId>
        <version>???</version>
        <scope>runtime</scope>
        <dependency>

РЕДАКТИРОВАТЬ: я сказал, что я не хочу делать это со свойствами, потому что он не будет разрешаться в зависимости отв то время, когда я отмечаю проект A.

Answer 1

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

Java - это динамическое связывание.Ничто не мешает вам скомпилировать A и I вместе, не ссылаясь ни на B, ни на C - он просто компилируется, но иногда вызывает исключение во время выполнения, поскольку не имеет реализаций для интерфейсов в I.

Выдолжен просто реализовать какую-то абстрактную фабрику, возвращающую объекты I после поиска правильной реализации.Критерии этой фабрики для принятия решений могут быть взяты из некоторого файла свойств или глубокого погружения в классы отражения / аннотирования и т. Д.

https://en.wikipedia.org/wiki/Abstract_factory_pattern

Сканирование аннотаций Java ввремя выполнения

Когда вы распространяете свое приложение, вы просто упаковываете свои банки A и I с реализациями: B, C или любым другим, что вы хотите расширить в будущем (D, E и т. д.).Однажды во время выполнения ваш AbstractFactory должен будет принять решение на основе настройки приложения и доступных реализаций.

В качестве примера, подумайте о Windows Media Player (я знаю, другая технология, но та же идея) и о том, как он выглядит для реализации кодеков, и как после того, как мы скачали и зарегистрировали их, он мог просто воспроизводить клипы без каких-либо изменений.к самому программному обеспечению.

Answer 2

Итак A компилируется нормально против I;существует зависимость от A до I.

. Реализацию I в C можно добавить как jar к A с помощью:

• <scope>runtime<scope> или
• <scope>provided<scope> если там, где выполняется банка A, есть банка C.

Тогда возникает вопрос об отсутствии зависимости.

Если jar C использует java SPI (интерфейс поставщика услуг), он может A выполнить поиск на некотором интерфейсе:

• I

  package net.i.api; interface Api { ... }
  

• C

  package net.c.api; class ApiImpl implements Api { ... }
  

  • Текстовый файл /META-INF/services/net.i.api.Api:

    net.c.api.ApiImpl