[
https://issues.apache.org/jira/browse/SLING-9820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213510#comment-17213510
]
Mark Adamcin commented on SLING-9820:
-------------------------------------
[~kwin] any comments on this before put a patch together?
> 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)
