Support for KnotX in GAP environment plugin

[mierzwid]

@Skejven FYI

gradle-aem-multi setups KnotX service side by side with dispatcher

• it is described in docker-compose.yml - additional KnotX container
• KnotX is behind Apache and only page requests get forwarded to it
• there is example content added to multi project thats allows additional rendering to be made by KnotX
• data source for KnotX will be static files configured and mounted
• KnotX configuration files would be bind-mounted

GAP support:

• GAP should be able to perform health checks on KnotX endpoint 8092
• GAP creates all needed logs and

[pun-ky]

Above is good but one thing missing in my opinion. There need to be set up some custom knotx module in directory knotx/extension/build.gradle (beside of aem/ branch) that will have set up building jar artifact and deployment to the knotx (probably just volume and copying pasting jar to correct place will do the job, vertx is detecting changes / reloads by itself)

[pun-ky]

design results (consulted with @Skejven )

1. knotx volume will point to unversioned directory / under .environment (not aem/gradle/environment as currently)
2. knotx configuration will be grabbed from downloaded distribution file knotx-stack.zip/knotx/conf then unpacked under .environment/knotx/conf then all files could be overridden by aem/gradle/environment/knotx/conf (kinda overlay)
3. on file changes under aem/gradle/environment/knotx/conf they will be copied to target location under volume so that Knotx will use changed file immediately

as a result, only project specific (example) knotx related files are versioned (less to maintain on GAP side), still it will be easy to get all updates from knotx side by bumping knotx-stack.zip version

[pun-ky]

similar design could be applied to built custom Knotx modules however then probably restarting Knotx container will be required (to reflect classpath changes)

[malaskowski]

Another solution for the classpath changes would be approach similar to one from the Knot.x Starter Kit, where custom Docker image is build every time dependencies/modules change.
Additionally this approach can be also transferred to prepare production-ready artifacts (Docker way).