You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Mark Adamcin (Jira)" <ji...@apache.org> on 2020/10/14 00:34:00 UTC
[jira] [Updated] (SLING-9820) sling-maven-plugin should provide
"install" goals that support uploading content-packages over
WebDAV/SlingPostServlet
[ https://issues.apache.org/jira/browse/SLING-9820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Adamcin updated SLING-9820:
--------------------------------
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 regularly enforce an "embedded" approach to nesting the 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 their local machines remains consistent with the mechanics that will play out in CI pipelines, the sling-maven-plugin should replace the use of Adobe's content-package-maven-plugin for any content-package module that is ultimately embedded in a container package.
For example, if a {{ui.apps}} package will be installed in production by the Sling JCR Installer after the zip file is imported to the {{/apps/myapp-packages/application/install}} 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, so long as the bundle is installed using the WebDAV or SlingPostServlet deploymentMethod. Then, when the developer does a full build and selects the {{all}} package for local deployment, the installation mechanics of the {{ui.apps}} package will remain the same.
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.
The specific changes would probably need to be:
# Provide three new goals following one of these naming conventions:
## {{install-content-package}}, {{install-content-package-file}}, and {{uninstall-content-package}}.
## {{upload-content-package}}, {{upload-content-package-file}}, and {{remove-content-package-file.}}
# New goals will need to avoid filtering out non-bundles based on a lack of Bundle-SymbolicName.
# New goals should use a unique {{contentPackageFileName}} configuration parameter that defaults to {{${project.build.directory}/${project.build.finalName}.zip.}}
was:
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 regularly enforce an "embedded" approach to nesting the 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 their local machines remains consistent with the mechanics that will play out in CI pipelines, the sling-maven-plugin should replace the use of Adobe's content-package-maven-plugin for any content-package module that is ultimately embedded in a container package.
For example, if a {{ui.apps}} package will be installed in production by the Sling JCR Installer after the zip file is imported to the {{/apps/myapp-packages/application/install}} 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, so long as the bundle is installed using the WebDAV or SlingPostServlet deploymentMethod. Then, when the developer does a full build and selects the {{all}} package for local deployment, the installation mechanics of the {{ui.apps}} package will remain the same.
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.
The specific changes would probably need to be:
# Provide three new goals following one of these naming conventions:
## {{install-content-package}}, {{install-content-package-file}}, and {{uninstall-content-package}}.
## {{upload-content-package}}, {{upload-content-package-file}}, and {{remove-content-package-file.}}
# New goals will need to avoid filtering out non-bundles based on a lack of Bundle-SymbolicName.
# New goals should use a unique {{contentPackageFileName}} configuration parameter that defaults to {{${project.build.directory}/${project.build.finalName}.zip{{.}}}}{{}}
> sling-maven-plugin should provide "install" goals that support uploading content-packages over WebDAV/SlingPostServlet
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-9820
> URL: https://issues.apache.org/jira/browse/SLING-9820
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
> Affects Versions: Sling Maven Plugin 2.4.2
> Reporter: Mark Adamcin
> Priority: Major
>
> 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 regularly enforce an "embedded" approach to nesting the 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 their local machines remains consistent with the mechanics that will play out in CI pipelines, the sling-maven-plugin should replace the use of Adobe's content-package-maven-plugin for any content-package module that is ultimately embedded in a container package.
> For example, if a {{ui.apps}} package will be installed in production by the Sling JCR Installer after the zip file is imported to the {{/apps/myapp-packages/application/install}} 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, so long as the bundle is installed using the WebDAV or SlingPostServlet deploymentMethod. Then, when the developer does a full build and selects the {{all}} package for local deployment, the installation mechanics of the {{ui.apps}} package will remain the same.
> 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.
> The specific changes would probably need to be:
> # Provide three new goals following one of these naming conventions:
> ## {{install-content-package}}, {{install-content-package-file}}, and {{uninstall-content-package}}.
> ## {{upload-content-package}}, {{upload-content-package-file}}, and {{remove-content-package-file.}}
> # New goals will need to avoid filtering out non-bundles based on a lack of Bundle-SymbolicName.
> # New goals should use a unique {{contentPackageFileName}} configuration parameter that defaults to {{${project.build.directory}/${project.build.finalName}.zip.}}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)