Allow to provide additional fragment filename mappings

[rhuss]

Description

Currently, the mapping from filename suffixes to resource kinds is predefined within the plugin (now via an internal configuration implemented for #1372).

To be more future proof for new kinds it would be nice to allow the user to specify additional mappings.

This could be done in several ways:

• Providing a single property pointing to a properties file holding the mapping (e.g. with suffix=kind properties. Maybe with a sensible default for the filename which, when it exists, is automatically picked up (like the fragments)
• Allow a plugin configuration to specify the mapping in XML style.

[lordofthejars]

@rhuss

Maybe with a sensible default for the filename

Should be the default disk-based or classpath based? Not sure about the best usage for default.

If disk-based, which would be the best default folder location for a Maven plugin?

[rhuss]

Maybe we could allow both:

• Disk-based for a quick and explicit way to specify the mapping. As a default path we unfortunately currently can't use src/main/fabric8 as everything within this folder is considered to be reserved for profiles and fragments. But maybe we should also might reconsider this, too for 4.0. I have to revisit the current external configuration that we allow and the files involved to come to a more streamlined directory layout.
• Classpath based for e.g more persistent extensions points. That's how we allow for custom enricher and generator, too. The dependencies should be added on the plugin level. Here I would put it again below META-INF/fabric8

[lordofthejars]

Ok then for now just classpath in META-INF/fabric8.

Now checking how to make to read custom ones from Maven configuration tag

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!