[
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 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.}}
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 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{{.}}}}{{}}
> 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)
