Should native image be an extension?

[David Lloyd]

We configure a lot of the native image stuff via the build (Maven or
Gradle), but I wonder if it wouldn't be better to make it all depend
on the application.properties configuration. This would tend to imply
that native image generation (and in fact all our different backends)
could possibly be extensions, meaning that if I want a given output
type (regular JAR, uber JARs of various types, native image, container
images of various types, etc.) then there would need to be an
extension for it.

This in turn would imply that each target type would be a build item.
Each target type extension would declare the item as a final (build
result) item. This would also make it a lot easier for extensions to
perform actions that are specific to the build type (such as
generating classes, which can be expensive for JVM mode but a very
cheap/free optimization for native images).

The advantage of such an approach is that we become more build system
agnostic, we centralize our configuration more instead of having it
spread in multiple places, and we could potentially really lighten up
the core by pushing much of the output-specific stuff out.

In Maven at least, the user could select single outputs using simple profiles.

Any thoughts?
--
- DML

[Sanne Grinovero]

Could you make an example of which "stuff" you'd rather see configured in application.properties ?

I do like the idea of having "targets" handled differently but in terms of naming things I suspect it could be confusing to conflate these with the notion of extensions.

For the record, with Gradle today there's no configuration needed for the native-image target, so for that specific case I don't see much value in changing this. (Not being against either, and possibly not fully understood what you have in mind).

Thanks,

Sanne

--
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.
Visit this group at https://groups.google.com/group/quarkus-dev.
For more options, visit https://groups.google.com/d/optout.

[David Lloyd]

On Sat, Mar 23, 2019 at 6:55 PM Sanne Grinovero <sa...@hibernate.org> wrote:
>
> Could you make an example of which "stuff" you'd rather see configured in application.properties ?

Memory sizes, GC configuration, memory sizes for the compile process
itself, heap dump and call tree output control, etc.

> I do like the idea of having "targets" handled differently but in terms of naming things I suspect it could be confusing to conflate these with the notion of extensions.

I wouldn't see them as conflation, I see it more as a thing that
extensions could do (but don't). It is consistent with our original
objectives to determine the complete set of features of the target
application by way of the set of installed extensions.

This also allows an extensible way to add target types without having
to add support to the core for every last one, meaning the core can be
closer to minimal rather than growing every time we add a new target.

> For the record, with Gradle today there's no configuration needed for the native-image target, so for that specific case I don't see much value in changing this. (Not being against either, and possibly not fully understood what you have in mind).

Right we want a no-config minimum for sure, but I just think that the
things that *are* configured should be done in a consistent way. The
stuff that is currently *possible* to configure in the Maven plugin
(which I assume must also exist in some form on Gradle) should be
moved to the application.properties for this reason.

--
- DML

[Scott Stark]

How would the artifact generation fit into the current extension architecture, and would this relate to the command line image?

[David Lloyd]

The current runner JAR generation would probably be built in, but to
produce any other artifact type you'd just add the appropriate
dependency, e.g. `quarkus-native-image` or `quarkus-uberjar`.

I don't think it would affect the command line image, but we'll talk
about that next week I expect.

> --
> 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.
> Visit this group at https://groups.google.com/group/quarkus-dev.
> For more options, visit https://groups.google.com/d/optout.

--
- DML

[Emmanuel Bernard]

I can imagine only wanting native generation for specific profiles (staging and prod but not dev). I wonder how the idea of using the presence of an extension copes with that.

I do like the idea of centralisation of controls. Though we might get resistance from people wanting these to be handled by “their build tool”. I don’t know how religions people can be of this.

[David Lloyd]

On Mon, Mar 25, 2019 at 2:19 AM Emmanuel Bernard <eber...@redhat.com> wrote:
>
> I can imagine only wanting native generation for specific profiles (staging and prod but not dev). I wonder how the idea of using the presence of an extension copes with that.

The idiomatic Maven approach would be to use Maven profiles here.
OTOH, we could also support build-time config profiles. In fact
config profiles is probably something we should discuss separately.

> I do like the idea of centralisation of controls. Though we might get resistance from people wanting these to be handled by “their build tool”. I don’t know how religions people can be of this.

Enabling features via dependency seems to do both: we centralize the
mechanism but we also allow the build tool to control how it is
applied.

--
- DML

[Sanne Grinovero]

On Sun, 24 Mar 2019 at 19:09, David Lloyd <david...@redhat.com> wrote:
>
> The current runner JAR generation would probably be built in, but to
> produce any other artifact type you'd just add the appropriate
> dependency, e.g. `quarkus-native-image` or `quarkus-uberjar`.

I do like your idea in principle, but in terms of usability I'm not
convinced that I want to need adding more dependencies to get basic
stuff working. This really should be automated.

You persuaded me before that adding some dependencies automatically
based on configuration parsing was a bad idea; would you consider
adding "this kind" of extensions to be a special case enough to allow
build tools to automatically pull-in additional extensions based on
the build target?

Alternatively, maybe consider having some of such extensions available
by default - assuming we can all agree on which ones to bless in such
way, and which ones need explicit opt-in.

[David Lloyd]

On Mon, Mar 25, 2019 at 7:31 AM Sanne Grinovero <sa...@hibernate.org> wrote:
>
> On Sun, 24 Mar 2019 at 19:09, David Lloyd <david...@redhat.com> wrote:
> >
> > The current runner JAR generation would probably be built in, but to
> > produce any other artifact type you'd just add the appropriate
> > dependency, e.g. `quarkus-native-image` or `quarkus-uberjar`.
>
> I do like your idea in principle, but in terms of usability I'm not
> convinced that I want to need adding more dependencies to get basic
> stuff working. This really should be automated.

It depends on what you mean by "basic". We already require the user
to add dependencies for things like HTTP, which one could argue is
basic (but I wouldn't, because sometimes you don't want it). Just as
you sometimes don't want/care about native image, or uberjar, or
docker.

> You persuaded me before that adding some dependencies automatically
> based on configuration parsing was a bad idea; would you consider
> adding "this kind" of extensions to be a special case enough to allow
> build tools to automatically pull-in additional extensions based on
> the build target?

No, I still think that the dependencies should select the features you
have enabled; that's a good clean system that has served well so far.
You add dependencies based on the features you want, and then you
configure based on what default behaviors you want to override.

> Alternatively, maybe consider having some of such extensions available
> by default - assuming we can all agree on which ones to bless in such
> way, and which ones need explicit opt-in.

The only reason I suggested having the "plain" JAR always available is
that it seems like you should have *something* available. But I could
(very) easily be convinced that we should require the user to provide
a dependency for JAR output as well e.g. `quarkus-jar`, and simply
print an error if the Maven/Gradle plugin is run with no output types
given.



--
- DML