[
https://issues.apache.org/jira/browse/SLING-9820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214103#comment-17214103
]
Mark Adamcin commented on SLING-9820:
-------------------------------------
{quote}One remark about:
{quote}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
{quote}
You can still use subpackages (below {{/etc/packages}}) in containers,
therefore relying on the JCR Installer (with embedded packages) is not a must.
{quote}
Agreed. I've adjusted the language in the description to communicate that the
feature would be useful for projects deploying embedded packages subject to JCR
installer edge cases, and not to suggest that most projects would need to
switch from the content-package-maven-plugin in more general cases.
{quote}Also I don't follow the argument for
{quote}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.
{quote}
With AEMaaCS the build/deployment is fundamentally different due to the use of
the Feature Model and Composite Node Store. With AEM Classic deploying the
outermost container with package manager (i.e. content-package-maven-plugin)
has the advantage that this is synchronous (to a certain extend), i.e. you see
issues with the packages earlier/better, also this is the mechanism used by
Cloud Manager with AMS instances.
{quote}
I don't think I worded this statement very well. I think we are on the same
page here, but to clarify, the outermost container package modules should
continue to use {{content-package-maven-plugin}}, which is consistent with
cloud manager deployments. The proposed feature for the sling-maven-plugin
would only be used for local maven executions for iterative, individual
deployment of embedded package artifacts when upload of the outermost container
package is skipped.
> 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 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 their local machines remains consistent with the mechanics that will play
> out in CI pipelines, 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 in a container package at a path that is not
> always actively watched by the JCR Intaller, 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.3.4#803005)
