archetype fails to run correctly when -DoptionDispatcherConfig=cloud is used on windows

[reusr1]

Expected Behaviour

archetype is able to create project with cloud ready dispatcher configuration

Actual Behaviour

fails to create the project

Reproduce Scenario (including but not limited to)

on a windows machine with the adobe corp maven repository configured run

mvn archetype:generate -DarchetypeGroupId=com.adobe.granite.archetypes -DarchetypeArtifactId=aem-project-archetype -DarchetypeVersion=22 -DoptionDispatcherConfig=cloud

note: same command works on linux

Platform and Version

windows 10, java8, apache maven 3.5

Logs taken while reproducing problem

[INFO] Parent element not overwritten in D:\aem\sdk\com.headwire.site.hw\it.tests\pom.xml
[INFO] Parent element not overwritten in D:\aem\sdk\com.headwire.site.hw\it.launcher\pom.xml
[INFO] Parent element not overwritten in D:\aem\sdk\com.headwire.site.hw\repository-structure\pom.xml
[INFO] Executing META-INF/archetype-post-generate.groovy post-generation script
Creating content skeleton...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 27.007 s
[INFO] Finished at: 2020-01-22T06:19:06-08:00
[INFO] Final Memory: 23M/311M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:3.1.2:generate (default-cli) on project standalone-pom: java.nio.file.FileSystemException: D:\aem\sdk\com.headwire.site.hw\dispatcher\src\conf.d\enabled_vhosts\default.vhost: A required privilege is not held by the client.

[joerghoh]

symlink issue?

[reusr1]

@joerghoh could very well be the case

[joerghoh]

I still wonder why we do have symlinks in such a case. It just makes the setup more complicated than it should be.
(For example I don't get why there is a directory "enabled_vhosts". Every vhost present in the config should be active, if you want to remove one, just remove it from the config. Git handles everything else.)

[msagolj]

hi @reusr1 , yes it looks like a symlink issue. I quickly tested and the command works for me but I have the rights to create symlink. If i remove the right i get the same error. See:

https://stackoverflow.com/questions/8228030/getting-filesystemexception-a-required-privilege-is-not-held-by-the-client-usi

With Windows you can add a user to the list of who may create symbolic links (without disabling UAC) using security policies. Run "secpol.msc" and change "Security Settings|Local Policies|User Rights Assignment|Create symbolic links"

[vladbailescu]

@joerghoh , as for why we have the symlinks, it's because the dispatcher needs them and the origins trace back to how Apache web server configurations are structured.

[reusr1]

@msagolj thank you - also seems to work if you run the project in an admin console - would probably be good to mention this in the README

[joerghoh]

@vladbailescu I don't think that the "dispatcher" needs them. The setup with the 2 directories available_vhosts with all configurations in there and and a separate directory enabled_vhosts (here you have lots of symlinks adressing files in available_vhosts) is dating back to times when config files were not versioned, and where enabling and disabling can be done quickly. And the files in the enabled_vhosts are only included from a different httpd configuration file.

But it's not a requirement enforced by either httpd or the dispatcher. You can include basically any directory you like.

[vladbailescu]

@joerghoh unless something changed since https://docs.adobe.com/content/help/en/experience-manager-cloud-service/implementing/dispatcher/overview.html was last updated, they are needed in the current setup and implementation. Agree that we could get rid of them in the dispatcher but I guess people got used to this structure (hence the reference to httpd) so it might cause some confusion.

[kwin]

You can easily set up HTTPD without the enabled vhosts symlink structure. I agree with @joerghoh it just makes things much more complicated. Reenabling and disabling vhosts is anyhow not a real use case without redeployment any longer....

[bstopp]

It should be noted that this should work fine if the Archetype is run using Windows Subsystem for Linux. (Git commit likely needs to be in this context as well.)

[vladbailescu]

Documented the workaround in 6ecbe45, to change the way the dispatcher configuration is structured, a request should be sent to the product team.