[jira] [Updated] (SLING-9820) sling-maven-plugin should provide "install" goals that support uploading content-packages over WebDAV/SlingPostServlet

["Konrad Windszus (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-9820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Konrad Windszus updated SLING-9820:
-----------------------------------
    Fix Version/s: Sling Maven Plugin 2.5.2
                       (was: Sling Maven Plugin 2.5.0)

> 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
>             Fix For: Sling Maven Plugin 2.5.2
>
>          Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> 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.}}
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)