search

eclipse-jkube / jkube

Build and Deploy java applications on Kubernetes
https://www.eclipse.dev/jkube/
Eclipse Public License 2.0
774 stars 521 forks source link

assembly / descriptorRef seems not to be supported #644

Open edrandall opened 3 years ago

edrandall commented 3 years ago

Description

Switched an existing project over from docker-maven-plugin to org.eclipse.jkube:kubernetes-maven-plugin:1.1.1 and immediately encountered an error:

[ERROR] Failed to execute goal org.eclipse.jkube:kubernetes-maven-plugin:1.1.1:build (docker-build) on project build-compiler: Unable to parse configuration of mojo org.eclipse.jkube:kubernetes-maven-plugin:1.1.1:build for parameter descriptorRef: Cannot find 'descriptorRef' in class org.eclipse.jkube.kit.common.AssemblyConfiguration -> [Help 1]

Info

Plugin configuration:

    <build>
        <pluginManagement>
            <plugins>
                <!-- Build container images and push to repository using Fabric8-->
                <plugin>
                    <groupId>org.eclipse.jkube</groupId>
                    <artifactId>kubernetes-maven-plugin</artifactId>
                    <version>1.1.1</version>
                    <extensions>true</extensions>
                    <executions>
                        <execution>
                            <id>docker-build</id>
                            <phase>package</phase>
                            <goals>
                                <goal>build</goal>
                            </goals>
                        </execution>
                        <configuration>
                        <sourceDirectory>.</sourceDirectory>
                        <dockerHost>${docker.host}</dockerHost>
                        <verbose>true</verbose>
                        <useColor>true</useColor>
                        <autoPull>on</autoPull>
                        <images>
                            <image>
                                <name>%a:${docker.release.tag}</name>
                                <build>
                                    <contextDir>.</contextDir>
                                    <cacheFrom>
                                        <image>${project.artifactId}:${docker.release.tag}</image>
                                        <image>${docker.repository}/${project.artifactId}:${docker.release.tag}</image>
                                    </cacheFrom>
                                    <assembly>
                                        <!-- Ref. http://maven.fabric8.io/#build-assembly-descriptor -->
                                        <name>dependencies</name>
                                        <descriptorRef>artifact-with-dependencies</descriptorRef>
                                    </assembly>
                                    <cleanup>try</cleanup>
                                    <compression>gzip</compression>
                                    <optimise>true</optimise>
                                </build>
                            </image>
                        </images>
                    </configuration>
                </plugin>
rohanKanojia commented 3 years ago

I'm not able to find descriptorRef mentioned in the documentation[0]. What's your use case?

[0] https://www.eclipse.org/jkube/docs/kubernetes-maven-plugin

manusa commented 3 years ago

Relates to: #497 #272 #94 (#94 comment on actions taken)

Refs are no longer supported, please see https://github.com/eclipse/jkube/issues/497#issuecomment-728957843 for alternatives.

If you really feel that this is something needed we might re-evaluate in the future. The main reason to remove Maven specific functionality is that JKube can now be used as a stand-alone Java API or (in the near future) as Gradle plugins. In this cases, Maven specific configs don't make sense.

As stated in the referenced comment, the idea would be to preprocess you assembly using the maven-assembly-plugin and then use the output directory and add it in the JKube specific assembly configuration.

edrandall commented 3 years ago

My use-case is to be able to simply archive a few common files as a .tar artifact in another module of the multi-module project, then have that made available to the Dockerfile in the current module simply by declaring it as a dependency in the usual maven way. I don't see that this is a particularly special use-case at all, far from it, very normal.

We already use maven-assembly-plugin to create the .tar file; If I was using Gradle I'd surely want to do something similar too. Maven only exists for its dependency mechanism, I don't need to be hard-coding a relative path between modules. I don't think the #497 alternatives consider the multi-module use-case.

Module 1 pom.xml, "common-resources":

    13    <artifactId>common-resources</artifactId>
    15    <packaging>pom</packaging>
    16
    17    <build>
    18      <plugins>
    19        <!-- package common files in a .tar for docker ADD -->
    20        <plugin>
    21          <artifactId>maven-assembly-plugin</artifactId>
    22          <executions>
    23            <execution>
    24              <id>tar</id>
    25              <phase>package</phase>
    26              <goals>
    27                <goal>single</goal>
    28              </goals>
    29              <configuration>
    30                <appendAssemblyId>false</appendAssemblyId>
    31                <attach>true</attach>
    32                <descriptors>
    33                  <descriptor>assembly.xml</descriptor>
    34                </descriptors>
    37              </configuration>
    38            </execution>
    39          </executions>
    40        </plugin>
    41      </plugins>
    42    </build>

Module 2 pom.xml: a docker build which requires files from module 1 (and perhaps other dependencies, my choice):

    13    <artifactId>dockerbuild</artifactId>
    15    <packaging>jar</packaging>
    16
    20    <dependencies>
    21      <dependency>
    22        <groupId>mygroup</groupId>
    23        <artifactId>common-resources</artifactId>
    24        <version>${project.version}</version>
    25        <type>tar</type>
    26      </dependency>
    27    </dependencies>
    32    <build>
    33      <plugins>
    34        <plugin>
    35            <groupId>io.fabric8</groupId>
    36            <artifactId>docker-maven-plugin</artifactId>
    37        </plugin>
    38      </plugins>
    39    </build>

Full docker-maven-plugin configured using PluginManagement in parent pom.xml, as in initial post above.

In the Dockerfile, I can simply:

ADD dependencies/common-resources-${project.version}.tar ./
edrandall commented 3 years ago

Seems to me that removing support for dependencies opens a big functionality gap and JKube needs to seriously rethink this approach.

We are a big maven shop. What's our use-case? Our use-case is having a maintainable and up-to-date maven build system. We're only looking at JKube as an evolution from docker-maven-plugin and fabric8-maven-plugin. JKube makes a big fanfare of having taken over that project and being the next stage of evolution from that. If large parts of functionality are going to be removed, this becomes a dead-end for us. We don't want to have to completely restructure our build on a whim.

The maven-free technical purity of some Java API is not my concern, but missing functionality is. There will of course be a build-system-agnostic way to incorporate dependencies into the API that can then be mapped back to the maven plugin and usable via dependencyRef. I'm sure Gradle probably has a comparable dependency mechanism at some level and Gradle users will want that too.

manusa commented 3 years ago

Functionality has been removed from the core logic, however, there are plenty of ways to overcome this issue with a few extra configurations. (Even with multimodule, you could configure your assembly as you please, simply need to preprocess into a common output directory/file and then add a proper assembly configuration for JKube. Everything you pointed out here is possible now)

I do understand your specific point and that's why the dependency sets feature is still up for discussion, please upvote #272 if you think this should be part of the feature-set JKube offers.

Your initial issue was about descriptorRef which nothing has to do with dependency sets. In this case, I do see that this is something very Maven-specific and will be hard to embed in the core logic of JKube. However, if you still see a point in adding/keeping support for this feature, please say so.

davidecavestro commented 3 years ago

If descriptorRef support has been dropped, then maybe the migration guide from fabric8 maven plugin should be updated, right?

davidecavestro commented 3 years ago

The plugin docs still claim

This plugin uses the assembly descriptor format similar to the one used in maven-assembly-plugin to specify the content which will be added to the image.

I'm not sure it is still true.

BTW it would be great if the migration guide is updated keeping the original fabric8 example which makes use of descriptorRef, so that we get a clear reference on how to produce a simple docker image with the main artifact when migrating to jkube.