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