Change to only allow a single output type

[stuartwdouglas]

No description provided.

[gsmet]

I think this is mostly good to go but here are a few fixes and suggestions.

[gsmet]

Why do you return a null ServiceStartBuildItem? To force the ordering?

[stuartwdouglas]

So it is run at all

[gsmet]

OK, we will need to also change all the quickstarts.

[stuartwdouglas]

Yes, the current way still works, so existing projects will work as normal.

[gsmet]

Suggested change

	You can provide additional options for `native-image` command using `quarkus.native.additional-buildA-args=foo,bar` in `application.properties`. Provided options have to be `,` separated.
	You can provide additional options for `native-image` command using `quarkus.native.additional-build-args=foo,bar` in `application.properties`. Provided options have to be `,` separated.

[gsmet]

We will need some serious work on a migration guide to have people moving their native-image config from the pom to the application.properties.

[stuartwdouglas]

The pom.xml way still works, and all the properties have the same name. We should definitely document this, but it is not something that should cause any breakage.

[gsmet]

Suggested change

	We use a profile because, you will see very soon, packaging the native executable takes a _few_ seconds. You could
	We use a profile because, you will see very soon, packaging the native executable takes a few minutes. You could

That's more in line with what I observe. But maybe I just have a slow machine? I know it was supposed to be sarcastic but I'm not sure users will get it.

[gsmet]

Suggested change

	These are properties are normal Quarkus config properties, so if you always want to build in a container
	These are normal Quarkus config properties, so if you always want to build in a container

[gsmet]

I would rewrite this paragraph and include the properties directly with:

include::{generated-dir}/config/quarkus-core-native-config.adoc[opts=optional]

[dmlloyd]

This is a bit of a major design change, did I miss the list discussion about this? There was some discussion in chat but I don't think the conclusion was "do it".

[stuartwdouglas]

The problem is that without this change we don't really get much extra flexibility from doing native in a build step (and eventually in an extension). You can produce extra stuff that goes into the image, but that is it.

[stuartwdouglas]

There are also quite a few other problems with the current build step approach:

• Anything that wants to consume the output (e.g. to zip it up into a deployment package) must pick the type of jar they want to consume. If the user has selected a different type both are generated.
• If there is the possibility of generating both we need different names for the uberjar and thin jar in the output dir.

If this PR is a problem then I would rather revert the change to building in build steps and worry about this post 1.0 than stick with the current approach of allowing multiple outputs, as I think it is very limiting and not something we want to get stuck supporting.

[dmlloyd]

There are other ways to get the same kinds of additional flexibility (which we'd want to enumerate anyway). I think we should have a discussion about whether we want to go this route.

In principle I like it because it's simpler - however it's also pretty different from what we had discussed previously from a usability standpoint. We basically have to be OK with telling the user that they need multiple modules or profiles or something to build multiple output types.

I'm OK with revisiting it later though if nobody else objects.

[stuartwdouglas]

You could do it by having some way of filtering particular build items so they only apply to particular output types, but it is much more complex.

Technically an extension could actually force the generation of multiple output types if required, e.g. by consuming both the JarBuildItem and NativeImageBuildItem. I can't really think of a valid use case where you would want both Uber and Thin jars though, at the moment you can't do it and AKAIK nobody has asked for it.

[stuartwdouglas]

@dmlloyd are you ok with this now after our conversation the other day?

[dmlloyd]

Yes I'm OK with it. I think that even if we introduce the multi-augment strategy, this change would be a reasonable basis to start with.