[
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 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.}}
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 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.}}
> 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 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.3.4#803005)
