[content] Revisit static html serving options

[kptdobe]

#2689 is going to introduce aem content clone which downloads the content locally in the ./content folder (default naming convention) and of course, the server serves the content from this folder with priority.

At the same time, #2697 introduced a new parameter --html-mount which works with the already existing --html-folder parameter:

• --html-folder option enables serving HTML files without extensions, useful for previewing content changes when you don't have access to the authoring system.
• use --html-mount to control the URL path where files are served. Without it, files are served at /FOLDER/*.

We now have 2 concepts doing something similar and potentially conflicting.

My proposal:

• get rid of --html-folder and use ./content as convention and default value
• if there is a real need, rename --html-mount to --content-mount that would define a different root path (default is /). I do not see a scenario where a different root path might be needed (urls not aligned with content structure ?)

cc @alexcarol @tripodsan @davidnuescheler

[tripodsan]

I do not see a scenario where a different root path might be needed
I thought that everything below the html-mount is served by the server; but I checked again, and I think there is still a fallback to the proxy if not found in the FS. so yes, I'm not sure why this is needed.

maybe @alexcarol you can explain the use case again?

[alexcarol]

The main goal is to simplify how we're using experience catalyst at the moment, but IMO this also simplifies the developer experience. If I want to test local changes to an "index.html.plain" (or a set of files), it's simplest to consider content/ the html root, so that whatever is served at localhost:/ is what's in there, and we don't need to add a prefix artificially.

If you ask me, I'd rather introduce a breaking change and make the "default" html-mount whatever "html-folder" we're passing. Though being able to set a custom html-mount already allows for anything we need.

If we don't have that we could also at setting a default for "html-folder and html-mount" based on a config file that could be configured by "aem content clone" (I feel like we had a ".helix.json" or similar format for either the importer or the CLI, but can't find a mention anywhere), this way we can seamlessly use it with just "aem up".

[alexcarol]

We now have 2 concepts doing something similar and potentially conflicting.

My proposal:

• get rid of --html-folder and use ./content as convention and default value
• if there is a real need, rename --html-mount to --content-mount that would define a different root path (default is /). I do not see a scenario where a different root path might be needed (urls not aligned with content structure ?)

cc @alexcarol @tripodsan @davidnuescheler

In the comment above I mentioned options both introducing breaking changes (updating the defaults), but also to keep backwards compatibility if we want to (i'm not sure many are using this feature though, do we have instrumentation or any way to find out?).

I think "./content" should be fine as a default, but it'd be good to have a way to ensure users who might have a "content" folder in the room have an "out", so we could change the default to it while still allowing users to override it if they need to.

On the content root, I agree that "/" should be the default, not quite sure what's the difference between --html-mount or --content-mount as you describe it, is it just the naming? or do you see it doing anything different? From what I see in the docs, the "feature" is that you can override "drafts" without overriding everything else, but personally I do not find that valuable, so we'd have to ask whoever introduced and documented the original feature that way.

[kptdobe]

The aem cli is properly versioned, it should not be a problem to break backward compatibility. And a good way to learn from the people using the feature once it is gone and they upgrade their cli.
The existing content folder is a pure hypothetical scenario. Let's see when this happens.
--content-mount was just a rename to match the content namespace. But we could even remove the feature and, again, wait for someone with a valid use case.

[trieloff]

If aem content clone proves to be viable, then removing --html-folder is the logical consequence to keep things simple. So, I'm +1 on this breaking change.