Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
Sling Maven Plugin 2.4.2
-
None
Description
With more recent versions of filevault-package-maven-plugin and filevault-validation introducing a distinction between container and application content-package artifacts, validation rules will sometimes enforce an "embedded" approach to nesting application package artifacts as JCR content within the container package artifact, relying on the Sling JCR Installer facility to perform install rather than a package manager servlet when deployed to a live environment like AEM.
To ensure that the installation mechanics experienced by developers iterating on these "embedded" packages on their local machines remains consistent with the mechanics that will play out in CI pipelines where the same embedded artifacts will be extracted by the JCR Installer, it should be possible to use the sling-maven-plugin in place of Adobe's content-package-maven-plugin for any content-package module that is ultimately embedded at a path that is not always actively watched by the JCR Installer, such as when the embedded package is only intended to be installed on publish servers, or only in the staging environment.
For example, if a ui.apps.author package will be installed in production by the Sling JCR Installer after the zip file is imported to the /apps/myapp-packages/application/install.author/ path by an all package, then it makes sense that when a developer is making incremental changes to HTL files on their local machine, and uploading the package to an AEM server running locally, the package upload should use the same deployment channel that is used for uploading an OSGi bundle to the same parent JCR path. Then, when the developer does a full build and selects the all package for local deployment, the installation mechanics of the ui.apps.author package will remain the same.
More importantly, if the developer switches to testing their functionality against a local publisher, and runs maven with with the ui.apps.author module selected along with other common artifacts, having the ability to setup the maven profile for that particular module to use a SlingPostServlet request to upload to the same /apps/myapp-packages/application/install.author/ path will result in the package being correctly uploaded, but not actually extracted. Whereas if the ui.apps.author module is setup to use the content-package-maven-plugin for upload, the developer risks unintentionally extracting the package to their publish repository along with the common packages they were intending to extract.
To be clear, this feature request does not envision supporting upload to any formal, server-side FileVault or CRX package manager HTTP APIs in any way that would replace the use of content-package-maven-plugin for that purpose, as hinted in SLING-6081, and instead is limited in scope to covering the edge cases that might arise with using embedded elements to nest content-packages at JCR paths.
The specific changes would probably need to be:
- Provide a new goal for uploading a content-package artifact following one of these naming conventions:
- install-content-package (nominally aligns with existing install goal for bundles, but might be confusing in effect since WebConsole install is not possible)
- upload-content-package
- jcr-install (perhaps this goal shouldn't be specific to uploading content-package artifacts, in case other OSGi Installer Resource Transformers may be in use)
- New goal will need to avoid filtering out non-bundles based on a lack of Bundle-SymbolicName, or it should actively filter out bundle artifacts in the same way, printing a one-line recommendation to the existing install goal be used for bundle artifacts instead.
- New goal should either use the current project artifact filename or use a unique targetFileName configuration parameter that defaults to ${project.build.directory}/${project.build.finalName}.zip.
