Add required properties for expansion in the build ConfigSource

[radcortez]

• Fixes Quarkus Maven Plugin : can't use properties generated by maven build-helper #14788
• Fixes maven-property provided by maven-plugin leads to exception in mutable-jar when devmode is activated #13980

While this adds any required property for expansion, there are some situations we cannot really control:

• Since expansion properties are set by other plugins, we may still fail if these plugin do not execute before our own.
• In a typical case where you run just the Quarkus plugin with quarkus:dev we don't have any generated expansion property available, so you still get the error. In this particular case, we can discuss if we need to eagerly initialize the ConfigRoot for the ContainerImage, since it should not be required in quarkus:dev.
  • This can be avoided by just setting the property in the %dev profile.

[radcortez]

/cc @rmanibus

[rmanibus]

Thank you very much, I think this will be really useful at least for build time config properties.

The problems with settings that properties in application.properties are :

• in a multi modules project this make a lot of duplication
• we can't really have "generated" values, like the git branch case (this can be achieved with maven filtering, but then the filtering must be performed before to have a correct result)
• I préfere not to see build time config after the build

There is really something with quarkus:dev, many times It would have been useful to execute other tasks / plugins around.

Maybe we can advocate on maven side to implement some kind of "custom phase" ?

[aloubyansky]

Looks good @radcortez, thanks! A little testcase with a non-quarkus. property in the pom would be good to add though.

[aloubyansky]

We should add the same in Gradle, btw.

[aloubyansky]

Maybe we can advocate on maven side to implement some kind of "custom phase" ?

How would that work @rmanibus ?
Perhaps a less elegant alternative would be to add a possibility to provide a list of plugins that should be invoked from the dev mojo.

[rmanibus]

@aloubyansky
I was thinking of a user defined phase that is not in the normal lifecycle but that link plugin together in a single command.

We could also imagine to give it a rank, for example when this phase is invoked execute all phase before compile.

[aloubyansky]

Would you mind sketching an example pom config? I guess in the dev mojo we could try looking for plugins configured for let's say pre-dev phase and invoking them.

[rmanibus]

A typical use case would be to use to invoke docker plugin to start a dB and then inject some data with dbunit plugin. I will draft something about that !

[aloubyansky]

This maybe related https://groups.google.com/g/quarkus-dev/c/EQpAI9kBrGk/m/URMR8OibBAAJ

[rmanibus]

@aloubyansky in my reproducer regarding this issue, running quarkus:dev will fail because it can not expand quarkus.container-image.tag even if it's not formally required to start the Dev mode. I think we managed to pass this by setting a default value that get overridden by the git plugin, so the branch is wrong during quarkus dev but it has no impact because it is not used.

I think it would be cleaner to execute everything before compile when running quarkus:dev

Thanks for the link, I will take a look !

[radcortez]

There is really something with quarkus:dev, many times It would have been useful to execute other tasks / plugins around.

Maybe we can advocate on maven side to implement some kind of "custom phase" ?

This is very tricky, because the amount of combinations and plugins is huge and you have no idea which ones the user wants to execute or not from our perspective. It would have to be the user to state that somehow.

I think we managed to pass this by setting a default value that get overridden by the git plugin, so the branch is wrong during quarkus dev but it has no impact because it is not used.

Yes, that is one way to do it. I usually set all the properties I'm going to need in the properties section of the POM anyway, even with empty values, just because these plugins generated properties are not recognised by the IDE and they don't have auto completion :)

[gsmet]

@radcortez do you have plans to add a test or should we merge as is?

[radcortez]

@radcortez do you have plans to add a test or should we merge as is?

Yes, I'll add some in the evening. Is that fine for the Monday release, or do you need it earlier?

[aloubyansky]

Perfect @radcortez, thanks!

[radcortez]

Perfect @radcortez, thanks!

Great. I didn't do that before, because without the fix the build would just fail and I thought it was sufficient :)

[gsmet]

Rebased.