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

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.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 16 (9 by maintainers)

Commits related to this issue

Archetype fails to run correctly when -DoptionDispatcherConfig=cloud is used on windows #329 Documented workaround — committed to adobe/aem-project-archetype by vladbailescu 4 years ago

Most upvoted comments

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.)

joerghoh on Jan 22, 2020

@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.

joerghoh on Jan 22, 2020

command run as administor it will work.

ashkouja1 on Jul 15, 2022

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…

kwin on Jan 22, 2020

@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

reusr1 on Jan 22, 2020