Issues using the new Maven's quarkus packaging with native console application. what to do ?

[cvgaviao]

Hello.

I changed the packaging type from jar to quarkus on our microservices and everything was ok.

And today I tried to do the same for our native image based console applications. But their Jenkins pipelines started to fail.

The reason is that the new quarkus packaging's lifecycle doesn't contains maven-install-plugin nor maven-deploy-plugins goals associated to it.

So, doing a "mvn deploy" doesn't calls deploy:deploy...

I tried to attach the maven-deploy-plugin in the project's pom, but it fails because this plugin needs to have something which is produced by the maven jar or install plugin and added to the build context, so it didn't work.

I also noted that build-helper-maven-plugin, which is used to attach the generated native image to the project's artifacts, also didn't work.

So, for now I've rollback the changes.

Anyone have experience this kind of issues and fixed ?

[quarkus-bot[bot]]

/cc @quarkusio/devtools (maven)

[Martzcode]

The quarkus packaging lifecycle intentionally omits maven-install-plugin and maven-deploy-plugin goals — it was designed for fast inner-loop dev, not for CI artifact publishing workflows. This is a known gap when migrating console/native apps.

Root cause

The quarkus packaging type replaces the default Maven lifecycle bindings. It doesn't bind install:install or deploy:deploy because the primary use case is running the app, not publishing a JAR. For microservices this is often acceptable, but for native console applications that Jenkins needs to archive or deploy as artifacts, it breaks the pipeline.

Working solution for native console apps

Keep <packaging>jar</packaging> (or quarkus for microservices) and use the native profile separately. The native binary is produced by the quarkus.package.type=native property, not by the packaging type:

<profiles>
  <profile>
    <id>native</id>
    <properties>
      <quarkus.package.type>native</quarkus.package.type>
    </properties>
  </profile>
</profiles>

Then in Jenkins: mvn deploy -Pnative

This way the full lifecycle (including deploy:deploy) runs correctly.

If you need the quarkus packaging type specifically

You can re-bind the missing goals explicitly in your pom.xml:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-deploy-plugin</artifactId>
  <executions>
    <execution>
      <id>default-deploy</id>
      <phase>deploy</phase>
      <goals><goal>deploy</goal></goals>
    </execution>
  </executions>
</plugin>

But you'll also need build-helper-maven-plugin to attach the native binary as an artifact before the deploy phase:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>build-helper-maven-plugin</artifactId>
  <executions>
    <execution>
      <id>attach-native</id>
      <phase>package</phase>
      <goals><goal>attach-artifact</goal></goals>
      <configuration>
        <artifacts>
          <artifact>
            <file>${project.build.directory}/${project.artifactId}-${project.version}-runner</file>
            <type>bin</type>
            <classifier>native</classifier>
          </artifact>
        </artifacts>
      </configuration>
    </execution>
  </executions>
</plugin>

Recommendation

For console native apps in CI pipelines, the simplest path is to keep jar packaging + native profile. The quarkus packaging type adds value for dev mode and fast restarts; for native binary publishing workflows it's not yet fully integrated.