WFCORE-4868 Introduce aliases for standard configuration files

[michpetrov]

Issue: EAP7-1700 / WFCORE-4868

[ehsavoie]

It is not clear to me where this aliases list live. i would love to make it editable so I could add my own aliases :) Also does it only concerns sandlone configuration files ? I think this should me expressed as a non requirement

[yersan]

It is not clear to me where this aliases list live.

So far it is only available for the configuration files we provide, so it is hardcoded in the code, maybe they could be extracted in an automatic and predictable way, but that is not available for the first cut yet.

i would love to make it editable so I could add my own aliases :) Also does it only concerns sandlone configuration files ?

That could be an evolution of this one. Right now is only prepared to supply aliases of the configuration files we provide by default. Those are the standalone variants.

[michpetrov]

Updated.

Just to clarify and perhaps I need to make the distinction clearer. I want this to work for the file suffixes, and a set of strings that are meant for the files we distribute.

I.e. "standalone-load-balancer.xml" can be referenced by "lb" (which will be hardcoded, and we could make this extensible in the future) but it could also be referenced by "load-balancer" (which is not hardcoded).

[yersan]

Updated.

Just to clarify and perhaps I need to make the distinction clearer. I want this to work for the file suffixes, and a set of strings that are meant for the files we distribute.

I.e. "standalone-load-balancer.xml" can be referenced by "lb" (which will be hardcoded, and we could make this extensible in the future) but it could also be referenced by "load-balancer" (which is not hardcoded).

@michpetrov You are proposing to also enable other aliases besides the ones that can be applied to the files we distribute. So if the user has standalone-custom.xml they can reference it using just -c custom. That's more versatile, but I don't see it too useful at all, instead of creating standalone-custom.xml you could create custom.xml, even more, if you plan to restrict all to standalone as the base name. Creating the shorter file seems simpler and avoids any weird behavior when you have standalone-custom.xml and custom.xml both on your configuration file. In such a case, if you use -c custom it is a bit confusing the expected logic about which file will be finally picked up. I would rather go with the simplest option which would be to translate with aliases the files we distribute only. In the future, if the need arises, we can think of how to allow the users to create custom aliases. I have no strong opinion on that, though, but I am more inclined to treat only the files we distribute.

If we go as it is not, could you also clarify this case in the proposal and define what would be the final logic applied?

[ehsavoie]

@michpetrov I think we should keep to a limited hard coded list of aliases. We can put in nice to have in the future requirements something to make that list dynamic or editable.
Adding the prefix 'standalone-' to find a file seems to leave us in the middle of the ford and makes evolutions complex. I'd rather stick with something simple first and see if the need for something dynamic arises.

[darranl]

FYI if we are targeting community the "Nice-to-have" requirements should be converted to non-requirements or moved to a future-work section

[yersan]

Adding the prefix 'standalone-' to find a file seems to leave us in the middle of the ford and makes evolutions complex. I'd rather stick with something simple first and see if the need for something dynamic arises

Yes, I do agree. Also, this is more a feature for developers than users, so focusing on files we distribute and providing an alias as a replacement to go faster when you need to use them too often, makes sense to me.

Enabling it now for users to create custom aliases for their custom files, does not sound as clear when you make a balance between it and the required logic/rules added to pick up the correct file, a logic that should remain the same for the future.

[bstansberry]

Thanks @michpetrov, @yersan and @ehsavoie!