[
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)
