Let's not build a jar that is useless 99% of the time?

[Guillaume Smet]

Hi,

When building a Quarkus application, we are building our own app packaging (e.g. the one in target/quarkus-app when using the default fast-jar packaging) but... we are also building a standard jar, which is 99% of the time completely useless.

Building this jar takes some time, especially when you have a large application.

It is quite inefficient compared to what we now do when packaging a fast-jar.

For instance, with the Quarkus application I currently benchmark (~10 000 classes), this is how the time is spent in a `mvn clean package`:

Aggregation by mojo 33s 671ms(100%)
  org.apache.maven.plugins:maven-clean-plugin:3.2.0 (default-clean) 246ms(0%)
  org.apache.maven.plugins:maven-resources-plugin:3.3.1 (default-resources) 43ms(0%)
  io.quarkus:quarkus-maven-plugin:999-SNAPSHOT (default) 6s 653ms(19%)
  org.apache.maven.plugins:maven-compiler-plugin:3.14.1-SNAPSHOT (default-compile) 5s 495ms(16%)
  org.apache.maven.plugins:maven-resources-plugin:3.3.1 (default-testResources) 3ms(0%)
  org.apache.maven.plugins:maven-compiler-plugin:3.14.1-SNAPSHOT (default-testCompile) 968ms(2%)
  org.apache.maven.plugins:maven-surefire-plugin:3.5.2 (default-test) 41ms(0%)
  org.apache.maven.plugins:maven-jar-plugin:3.4.1 (default-jar) 19s 872ms(59%)

Out of 33 seconds of builds, 19 seconds are for building this useless jar.

If I disable the maven-jar-plugin and the maven-install-plugin, it's now less than half the time:

Aggregation by mojo 14s 542ms(100%)
  org.apache.maven.plugins:maven-clean-plugin:3.2.0 (default-clean) 245ms(1%)
  org.apache.maven.plugins:maven-resources-plugin:3.3.1 (default-resources) 39ms(0%)
  io.quarkus:quarkus-maven-plugin:999-SNAPSHOT (default) 7s 102ms(48%)
  org.apache.maven.plugins:maven-compiler-plugin:3.14.1-SNAPSHOT (default-compile) 5s 718ms(39%)
  org.apache.maven.plugins:maven-resources-plugin:3.3.1 (default-testResources) 3ms(0%)
  org.apache.maven.plugins:maven-compiler-plugin:3.14.1-SNAPSHOT (default-testCompile) 1s 33ms(7%)
  org.apache.maven.plugins:maven-surefire-plugin:3.5.2 (default-test) 45ms(0%)

While there might be cases where you actually want to build this jar and install it (or install the generated uberjar), I think we should disable these plugins by default in our application template and add comments in the pom.xml to clearly explain why you might want to enable them in some rare cases.

This makes quite a difference in your daily dev experience and I think it's worth the extra work in the corner cases.

In practice, we would add something like this to the generated template:

+            <!--
+            This section disables the build and installation of the default jar, which are in general not needed for a Quarkus application.
+            If you need to produce a standard jar for some reason, you can either remove this section.
+            -->
+            <plugin>
+                <artifactId>maven-jar-plugin</artifactId>
+                <version>3.5.0</version>
+                <executions>
+                    <execution>
+                        <id>default-jar</id>
+                        <phase>none</phase>
+                    </execution>
+                </executions>
+            </plugin>
+            <plugin>
+                <artifactId>maven-install-plugin</artifactId>
+                <version>3.1.4</version>
+                <configuration>
+                    <skip>true</skip>
+                </configuration>
+            </plugin>
+            <!-- End of section -->

Thoughts?

-- 

Guillaume

[David Lloyd]

Great idea, 10/10. Generating extra artifacts like this is just confusing. 

--

- DML • he/him

[Yoann Rodiere]

+1 makes sense, but:

> you can either remove this section.

You dropped the last part of the sentence with "or <some other thing you can do>".

Also, probably off-topic, but I wonder if this could be controlled by the quarkus-maven-plugin... Perhaps running it as an extension? Though it could be confusing I suppose.

Yoann Rodière
Hibernate team

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CANghgrSXBhO0sSJj_e29ELr9EYBNewiTqh%2Bb9UCbVWDUXN%3DVFQ%40mail.gmail.com.

[George Gastaldi]

+1 you can also set the maven.install.skip property to true to avoid cluttering the pom

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_O7nb-%3DTVpKL_zpzNaZvt5iN8z%3D8V35GsS3fCxMi-c3A%40mail.gmail.com.

[Guillaume Smet]

Thanks, I need to drop the `either` in the comment. Will do.

Yeah so I thought about having some magic doing it (not sure it's doable, I would have to dig), but in the end, I think it's better to be explicit rather than hiding it entirely and adjust the default behavior of Maven without showing it explicitly.

Alexey had this idea that we could have our own Maven packaging (e.g. different from pom/jar/...) but I'm not sure we want to pile up one more Quarkus oddity.

One thing is that it's easier to change the behavior in the future if it's completely hidden from the user... but again... we are already doing a lot of things that are very specific and I'm not sure we should always take this path, when there are more explicit solutions that are not that bad.

It's open for discussions if people have a strong opinion about it, though.

[David Lloyd]

I agree in the short/near term. But I think long term we might want to rethink our relationship with Maven (and Gradle). This would probably be a good discussion for Q1/Q2 though.

--

- DML • he/him

[Guillaume Smet]

On Fri, Dec 12, 2025 at 6:09 PM George Gastaldi <gegas...@gmail.com> wrote:

+1 you can also set the maven.install.skip property to true to avoid cluttering the pom

Yeah, I would have done that if there was a similar property for the maven-jar-plugin. But I couldn't find one and I really wanted this stuff to be all in one place.

-- 

Guillaume 

[Guillaume Smet]

On Fri, Dec 12, 2025 at 6:09 PM Guillaume Smet <guillau...@gmail.com> wrote:

Alexey had this idea that we could have our own Maven packaging (e.g. different from pom/jar/...) but I'm not sure we want to pile up one more Quarkus oddity.

One thing is that it's easier to change the behavior in the future if it's completely hidden from the user... but again... we are already doing a lot of things that are very specific and I'm not sure we should always take this path, when there are more explicit solutions that are not that bad.

For future reference about the packaging type: https://stackoverflow.com/questions/1427722/how-do-i-create-a-new-packaging-type-for-maven . 

It doesn't look that bad and I think people would still be able to tweak the build so that might be a good option.

-- 

Guillaume

[Alexey Loubyansky]

On Fri, Dec 12, 2025 at 6:09 PM Guillaume Smet <guillau...@gmail.com> wrote:

It's about what packaging means and what we are trying to fit into it. For example, "maven-plugin", "ejb" also produce JARs but they use different packaging and lifecycle binding [1].

Most of Quarkus package types aren't even typical JARs. From that perspective, it could also be seen as oddity to fit into "jar" packaging something that is not a typical JAR or not a JAR at all and actually suppress the expected outcome for "jar" packaging.

Does it make practical sense to produce this default JAR? In most cases it doesn't. But it looks like a consequence of not using some "quarkus" packaging from the beginning and this step is taking it further in what looks like a wrong direction. I am not against it if it helps but this is how it looks.

BTW, we even had/have users who use custom packaging for Quarkus applications and we even have a test for it [2] and [3].

[1] https://maven.apache.org/ref/3.9.11/maven-core/default-bindings.html

[2] https://github.com/quarkusio/quarkus/tree/main/integration-tests/maven/src/test/resources-filtered/projects/custom-packaging-app

[3] https://github.com/quarkusio/quarkus/tree/main/integration-tests/maven/src/test/resources-filtered/projects/custom-packaging-plugin

 

It's open for discussions if people have a strong opinion about it, though.

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9w8g0GdPMhhdCX1iRRD0JeF9NCvi0Fiitqu7mte6jiNg%40mail.gmail.com.

[Guillaume Smet]

I started experimenting with a new packaging type yesterday. 

Le 14 déc. 2025 à 09:17, 'Alexey Loubyansky' via Quarkus Development mailing list <quark...@googlegroups.com> a écrit :



To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAJ97idGtSXuEtMo%3DpTEPwrFw9ZvwRRVP75qA34wqbi%3Do6ZfJPQ%40mail.gmail.com.

[Alexey Loubyansky]

There was a somewhat related PR some time ago https://github.com/quarkusio/quarkus/pull/19852

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/612469B7-086A-4700-9CE0-F56F334B6838%40gmail.com.

[Guillaume Smet]

Ah yes, interesting, I will include it in my work.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAJ97idFktJQBV97xoZEUNkZNwoKKdw31AJEQmLD%2BGRHFhPkFgA%40mail.gmail.com.

[Martin Kouba]

It would be great if we could just use:

<packaging>quarkus</packaging> -> fast-jar

and with quarkus.package.jar.type=uber-jar -> uber-jar

but I guess that it's not that easy, or?

>> bindings.html <https://maven.apache.org/ref/3.9.11/maven-core/default-
>> bindings.html>
>> [2] https://github.com/quarkusio/quarkus/tree/main/integration-tests/
>> maven/src/test/resources-filtered/projects/custom-packaging-app
>> <https://github.com/quarkusio/quarkus/tree/main/integration-tests/
>> maven/src/test/resources-filtered/projects/custom-packaging-app>
>> [3] https://github.com/quarkusio/quarkus/tree/main/integration-tests/
>> maven/src/test/resources-filtered/projects/custom-packaging-plugin
>> <https://github.com/quarkusio/quarkus/tree/main/integration-tests/
>> maven/src/test/resources-filtered/projects/custom-packaging-plugin>

>>
>>
>> It's open for discussions if people have a strong opinion about
>> it, though.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to quarkus-dev...@googlegroups.com

>> <mailto:quarkus-dev...@googlegroups.com>.

>> To view this discussion visit https://groups.google.com/d/msgid/
>> quarkus-dev/

>> CALt0%2Bo9w8g0GdPMhhdCX1iRRD0JeF9NCvi0Fiitqu7mte6jiNg%40mail.gmail.com <https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9w8g0GdPMhhdCX1iRRD0JeF9NCvi0Fiitqu7mte6jiNg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it, send

>> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
>> dev+uns...@googlegroups.com>.

>> To view this discussion visit https://groups.google.com/d/msgid/
>> quarkus-dev/

>> CAJ97idGtSXuEtMo%3DpTEPwrFw9ZvwRRVP75qA34wqbi%3Do6ZfJPQ%40mail.gmail.com <https://groups.google.com/d/msgid/quarkus-dev/CAJ97idGtSXuEtMo%3DpTEPwrFw9ZvwRRVP75qA34wqbi%3Do6ZfJPQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
> dev+uns...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-

> dev/612469B7-086A-4700-9CE0-F56F334B6838%40gmail.com <https://
> groups.google.com/d/msgid/quarkus-dev/612469B7-086A-4700-9CE0-
> F56F334B6838%40gmail.com?utm_medium=email&utm_source=footer>.

--
Martin Kouba
Principal Software Engineer
Red Hat, Czech Republic

[Alexey Loubyansky]

Yes, that's what it could be.

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/edb6ebc4-0e6a-4661-a66f-e03073b56677%40redhat.com.

[Stephane Epardaud]

Big +1 on all this.

On another note, I wonder if we should not improve how much custom XML there needs to be to make a Quarkus application in a pom.xml? Here you were talking about adding come more XML to disable the jar (then you went on to try a different strategy, great). But in general, I feel like it's almost impossible to create a Quarkus application without getting a pom.xml skeleton from either code.quarkus.io or creating the application with quarkus. Because there's all sorts of required XML.

If a single quarkus packaging line (or something else, whatever) in the pom would be enough to make a regular Maven app into a Quarkus app, that'd be AWESOME.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAJ97idFhSzpqWzO_F1BissVv4vaJnOTr8wnmS8udw3MFQaCZOA%40mail.gmail.com.

--

Stéphane Épardaud

[Guillaume Smet]

Hi,

Alexey merged my pull request and I did an experiment on a very large project I have around.

This is the initial timing of a `mvn clean package -DskipTests` for this project:

================

Aggregation by project 2m 5s(100%)
  fr.spacefox.perftests.quarkus:perftests-quarkus:1.0.0-SNAPSHOT 2m 5s(99%)
Aggregation by phase 2m 5s(100%)
  clean 895ms(0%)
  process-resources 576ms(0%)
  compile 20s 146ms(16%)
  generate-test-sources 940ms(0%)
  process-test-resources 4ms(0%)
  test-compile 3s 366ms(2%)
  test 43ms(0%)
  package 1m 39s(79%)
Aggregation by mojo 2m 5s(100%)
  org.apache.maven.plugins:maven-clean-plugin:3.2.0 (default-clean) 895ms(0%)

  org.apache.maven.plugins:maven-resources-plugin:3.3.1 (default-resources) 43ms(0%)

  io.quarkus:quarkus-maven-plugin:999-SNAPSHOT (default) 14s 962ms(11%)
  org.apache.maven.plugins:maven-compiler-plugin:3.14.0 (default-compile) 20s 146ms(16%)
  org.apache.maven.plugins:maven-resources-plugin:3.3.1 (default-testResources) 4ms(0%)
  org.apache.maven.plugins:maven-compiler-plugin:3.14.0 (default-testCompile) 3s 365ms(2%)
  org.apache.maven.plugins:maven-surefire-plugin:3.5.2 (default-test) 43ms(0%)
  org.apache.maven.plugins:maven-jar-plugin:3.4.1 (default-jar) 1m 25s(68%)

================

Then I applied this diff to switch to the new quarkus lifecycle:

================

diff --git a/pom.xml b/pom.xml
index 98660b8..3c60220 100644
--- a/pom.xml
+++ b/pom.xml
@@ -5,6 +5,7 @@
     <groupId>fr.spacefox.perftests.quarkus</groupId>
     <artifactId>perftests-quarkus</artifactId>
     <version>1.0.0-SNAPSHOT</version>
+    <packaging>quarkus</packaging>
 
     <properties>
         <compiler-plugin.version>3.14.0</compiler-plugin.version>
@@ -66,16 +67,6 @@
                 <artifactId>quarkus-maven-plugin</artifactId>
                 <version>${quarkus.platform.version}</version>
                 <extensions>true</extensions>
-                <executions>
-                    <execution>
-                        <goals>
-                            <goal>build</goal>
-                            <goal>generate-code</goal>
-                            <goal>generate-code-tests</goal>
-                            <goal>native-image-agent</goal>
-                        </goals>
-                    </execution>
-                </executions>
             </plugin>
             <plugin>
                 <artifactId>maven-compiler-plugin</artifactId>

================

And I got:

================
 Aggregation by project 36s 661ms(100%)
  fr.spacefox.perftests.quarkus:perftests-quarkus:1.0.0-SNAPSHOT 36s 656ms(99%)
Aggregation by phase 36s 661ms(100%)
  clean 895ms(2%)
  process-resources 571ms(1%)
  compile 16s 729ms(45%)
  process-test-resources 765ms(2%)
  test-compile 3s 231ms(8%)
  test 37ms(0%)
  package 14s 101ms(38%)
Aggregation by mojo 36s 661ms(100%)
  org.apache.maven.plugins:maven-clean-plugin:3.2.0 (default-clean) 895ms(2%)
  org.apache.maven.plugins:maven-resources-plugin:3.4.0 (default-resources) 40ms(0%)
  io.quarkus:quarkus-maven-plugin:999-SNAPSHOT (default-generate-code) 530ms(1%)
  org.apache.maven.plugins:maven-compiler-plugin:3.14.0 (default-compile) 16s 729ms(45%)
  org.apache.maven.plugins:maven-resources-plugin:3.4.0 (default-testResources) 3ms(0%)
  io.quarkus:quarkus-maven-plugin:999-SNAPSHOT (default-generate-code-tests) 762ms(2%)
  org.apache.maven.plugins:maven-compiler-plugin:3.14.0 (default-testCompile) 3s 231ms(8%)
  org.apache.maven.plugins:maven-surefire-plugin:3.5.2 (default-test) 37ms(0%)

  io.quarkus:quarkus-maven-plugin:999-SNAPSHOT (default-build) 14s 100ms(38%)

================

So we went from 2 minutes+ to 37 seconds by applying the new lifecycle.

This is the result of dropping the maven-jar-plugin jar build by default, which is extremely slow (`org.apache.maven.plugins:maven-jar-plugin:3.4.1 (default-jar) 1m 25s(68%)`).

That's some Green IT!

But it is also interesting to compare the quarkus-maven-plugin contribution in main versus 3.25.1, which is the version I started to work with.

If we compare the quarkus-maven-plugin goals between 3.25.1 and main, we have:

3.25.1: all quarkus plugin goals: ~ 29s

main: all quarkus plugin goals: ~ 15s

Obviously, this case is very extreme and doesn't represent your typical Quarkus app, but still, it should be beneficial for all apps out there.

-- 

Guillaume

[George Gastaldi]

That's awesome! Good job Guilhaume!

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_wiW-BDoSC%2B8KXzJQb5v7dMNJgWW2roYyyTsms4CE_bQ%40mail.gmail.com.

[Georgios Andrianakis]

🎉

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAK6y9v14fbs%2BTUSbg8S9FpTbcksY3eq6CNB5CF3%3DgC22HY4LeQ%40mail.gmail.com.

[Bruno Baptista]

This is excellent.

Should we apply it to all the IT test projects as well?

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-kJZO9Ymny0mDeSf6LsrH6xZpN%3D%3DCzhq7wdJPp7DAFz9A%40mail.gmail.com.

--

Bruno Baptista

@brunobat.bsky.social

[Guillaume Smet]

On Thu, Dec 18, 2025 at 6:20 PM Bruno Baptista <brun...@gmail.com> wrote:

This is excellent.

Should we apply it to all the IT test projects as well?

That's something we could consider.

I have modified the Maven tests for now, but not the ITs projects. 

[William Burke]

So long as fat-jar, traditional jar builds aren't removed as an option.  This is still used in some places.

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_O7nb-%3DTVpKL_zpzNaZvt5iN8z%3D8V35GsS3fCxMi-c3A%40mail.gmail.com.

--

Bill Burke

IBM

[Guillaume Smet]

I had a look and from what I can see, we already don't build a jar using the maven-jar-plugin for these so there won't be any benefit.

[Guillaume Smet]

On Thu, Dec 18, 2025 at 8:42 PM 'William Burke' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

So long as fat-jar, traditional jar builds aren't removed as an option.  This is still used in some places.

Yeah, I confirm it's completely orthogonal, you can still build an uber jar as you are used to. The uber jar is also built by our infrastructure, not the maven-jar-plugin.