Многопроектная сборка Maven с модулями API, по-видимому, не включает зависимости уровня проекта в образ сборки - PullRequest
Новая
       15

Многопроектная сборка Maven с модулями API, по-видимому, не включает зависимости уровня проекта в образ сборки

0 голосов
/ 08 марта 2019

Здравствуйте, у меня есть мультипроектная сборка Springboot maven, которая собирает несколько изображений. Структура похожа на: 

- project-parent
   - common
   - project-b-parent
      - project-b-api
      - project-b-gateway
      - project-b-launcher
   - project-c-parent
      - project-c-api
      - project-c-gateway
      - project-c-launcher

Там, где * модули запуска - это мои Springboot, Uber jar и шлюзы - это контроллеры Spring mvc и поддерживающие классы, а apis - это зависимости уровня проекта в модулях запуска. например, project-c зависит от project-b-api

Мой проект-родитель имеет: 

   ...
   <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.2.RELEASE</version>
   </parent>
   <version>0.0.1-SNAPSHOT</version>
   <groupId>my.group</groupId>
   <artifactId>project-parent</artifactId>
   <packaging>pom</packaging>
   ...
   <modules>
        <module>project-b-parent</module>
        <module>project-c-parent</module>
    </modules>
    ...
    <properties>
        <jib.skip>true</jib.skip>
    </properties>
    ...
    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>com.google.cloud.tools</groupId>
                        <artifactId>jib-maven-plugin</artifactId>
                        <version>1.0.0</version>
                        <configuration>
                            <from>
                                <image>my.base.image:latest</image>
                            </from>
                            <to>
                                <image>my.image.registry/${project-name}</image>
                                <tags>
                                    <tag>${project.version}</tag>
                                    <tag>latest</tag>
                                </tags>
                            </to>
                            <allowInsecureRegistries>true</allowInsecureRegistries>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>

Заметьте, я добавил <jib.skip>true</jib.skip> в мой родительский пом. У меня есть <jib.skip>false</jib.skip> в средствах запуска, и это создает предполагаемое поведение только создания образов из модулей * средства запуска.

Все модули имеют версию 0.0.1-SNAPSHOT.

Когда я проверяю свое изображение с помощью погружения, у меня нет слоя SNAPSHOT DEPENDENCIES, и мои зависимости на уровне проекта не отображаются в изображении.

Когда я запускаю свои приложения, кажется, что они запускают SpringBoot и прослушивают порт, как бы не загружались конечные точки контроллера. Другой проект выдает исключение NoClassDefFoundError при попытке загрузить класс из зависимости уровня проекта.

Я пробовал все версии как 0.0.1 без SNAPSHOT, и мои зависимости уровня проекта не включены в мой уровень зависимостей.

Я также попытался запустить mvn -X -DjibSerialize=true clean compile jib:build > logs.txt и мои зависимости на уровне класса 

...
[INFO] --- jib-maven-plugin:1.0.0:build (default-cli) @ project-b-launcher ---
[DEBUG] Configuring mojo com.google.cloud.tools:jib-maven-plugin:1.0.0:build from plugin realm ClassRealm[plugin>com.google.cloud.tools:jib-maven-plugin:1.0.0, parent: sun.misc.Launcher$AppClassLoader@5c647e05]
[DEBUG] Configuring mojo 'com.google.cloud.tools:jib-maven-plugin:1.0.0:build' with basic configurator -->
[DEBUG]   (f) allowInsecureRegistries = true
[DEBUG]   (f) mainClass = project-b.stuff.ApplicationKt
[DEBUG]   (f) container = com.google.cloud.tools.jib.maven.JibPluginConfiguration$ContainerParameters@77662d13
[DEBUG]   (f) image = my.registry/distroless-java:latest
[DEBUG]   (f) from = com.google.cloud.tools.jib.maven.JibPluginConfiguration$FromConfiguration@6a0328d7
[DEBUG]   (f) project = MavenProject: my.company:project-a-launcher:0.0.1 @ C:\my-programs\project-parent\project-b-parent\project-b-launcher\pom.xml
[DEBUG]   (f) session = org.apache.maven.execution.MavenSession@51ec2df1
[DEBUG]   (f) skip = false
[DEBUG]   (f) image = my-new-image
[DEBUG]   (f) tags = [0.0.1, latest]
[DEBUG]   (f) to = com.google.cloud.tools.jib.maven.JibPluginConfiguration$ToConfiguration@6370bf52
[DEBUG] -- end configuration --
[INFO] 
[INFO] Containerizing application to my.registry\project-parent\project-b-parent\project-b-launcher, my.registry\project-parent\project-b-parent\project-b-launcher\customer-launcher\project-b-launcher:0.0.1-SNAPSHOT, my.registry\project-parent\project-b-parent\project-b-launcher\customer-launcher\project-b-launcher...
[DEBUG] Containerizing application with the following files:
[DEBUG]     Dependencies:
[DEBUG]         C:\my-programs\project-parent\project-c-parent\project-c-gateway\target\classes
[DEBUG]         C:\my-programs\project-parent\project-c-parent\project-c-api\target\classes
[DEBUG]         C:\Users\me\.m2\repository\org\springframework\spring-web\5.1.4.RELEASE\spring-web-5.1.4.RELEASE.jar
...

Обратите внимание, что я переименовал множество конфиденциальных каталогов и т. Д. В этом выводе журнала DEBUG. Я не уверен, должны ли вторая и третья нижние строки (зависимости уровня проекта) указывать на target \ classes \ - они должны ссылаться на .jars? Я думаю, что они не могут, если я только делаю jv компиляции mvn: build

Надеюсь, я разместил это в правильном месте.

1 Ответ

0 голосов
/ 11 марта 2019

Оказалось, что были проблемы с настройкой проекта ОП.(Подробности в https://github.com/GoogleContainerTools/jib/issues/1539.) Как правило, spring-boot-maven-plugin и jib-maven-plugin были применены в корне pom.xml. В результате

  • spring-boot-maven-plugin пытается создать работоспособный JAR длякаждый подмодуль, некоторые из которых являются библиотеками, которые не имеют основного класса.
  • jib-maven-plugin пытается создать образ для каждого подмодуля, а также верхнего проекта.
...