Hm, so what should be the rules like? A template from the root application archive overrides templates provided by dependencies/extensions?

(or build-items)

In the sense of a TemplatePathBuildItem where the template is not backed by a file?

We could assign a priority to all discovered templates (e.g. root=5, dependency/extension=3, TemplatePathBuildItem=custom value), then identify the highest priority and fail if multiple templates for the same path define this priority. But it could be quite confusing. ALso it would be a breaking change. So we have to be careful.

add a new property: quarkus.qute.fail-on-duplicates and keep it to true by default, then your priority idea seems like a good option

add a new property: quarkus.qute.fail-on-duplicates and keep it to true by default, then your priority idea seems like a good option

I don't think it's a good idea. From my exprience, non-default options are rarely used. OTOH it's a good idea to add a switch that can be used to revert the original behavior, i.e. quarkus.qute.fail-on-duplicates=false by default.

@mkouba any update on this?

I'm struggling to define the priority assignment rules. For example, I can imagine a use case where a template from src/main/resources/templates should always take precedence...

There is also #41449 and #43749 which may overlap with this :-)

I'm struggling to define the priority assignment rules. For example, I can imagine a use case where a template from src/main/resources/templates should always take precedence...

That makes sense, is there an issue to achieve this? AFAIK resources on the same path are sorted depending on the build tool resolution, so it should be determinist and the src/main/resources should be the first.

I'm struggling to define the priority assignment rules. For example, I can imagine a use case where a template from src/main/resources/templates should always take precedence...

That makes sense, is there an issue to achieve this? AFAIK resources on the same path are sorted depending on the build tool resolution, so it should be determinist and the src/main/resources should be the first.

I'm not so sure this would work well in multi-module apps.

Also my original question was about a use case where a template from a build item overrides some other template. Which in some use cases might not be what a user needs 🤷 .

I would put priority, for example:

• Classpath resources 10 (then sorted by resolution order)
• Built item, default to 20, but can override the value
• app src 30

For multi-module apps I think it's the same as any classpath dependency

After reading all this i got an idea which is kinda relevant but does not solve the original feature request but maybe can be implemented alongside.

Instead of overwriting them maybe we can have all the templates under different "namespace".

So if template hello.html exists in mutiple projects, you can still use it with the fully qualified name (project group id + artifact id + directory + etc) + the template name.

You can already include templates that are under a different directory. {#include directory/hello.html}

I would put priority, for example:

* Classpath resources 10 (then sorted by resolution order)

* Built item, default to 20, but can override the value

* app src 30

In other words, application root has the highest priority and take precedence over templates from extensions and other dependencies, unless they're defined by a TemplatePathBuildItem (which can specify any priority).

Also add quarkus.qute.fail-on-duplicates=false that would fallback to the original behavior.

@ia3andy correct?

That sounds good to me..