Hi Julian,
Am 29.10.2020 um 15:44 schrieb Julian Sedding:
Carsten Ziegeler wrote on SLING-9862
I personally don't like the idea to have repoinit inside a bundle; so if we can
come to a solution where no new header is introduced that's probably better.
Today, you can install a feature, which references bundles, configurations
and repoinit - which I think is a much more flexible way than having everything
inside the code bundle. Users of your code might use different users, different
content paths (if configurable) etc.
Unfortunately I am in no position to use the feature model. I am
looking for solutions on how to better leverage repoinit on older
Sling deployments (namely AEM 6.5 on-prem), where the OSGi installer
is still the main means for deployment. Or am I missing something and
it is possible to use the feature model for this?
There is a plugin for the feature model:
https://github.com/apache/sling-org-apache-sling-installer-factory-feature/
It supports feature model files as well as feature archives and that of
course includes repoinit.
My goal is finding a way to maintain repoinit files in a Git
Repository and have them applied to the instance upon deployment via
content-packages. The existing "RepositoryInitializerFactory"
configuration does not quite cut it, as I outlined previously in this
thread (mainly the "scripts" configs are not maintainable due to
required escaping within config files and "references" to bundle
resources are not predictable, see SLING-9524).
I think a bundle developer knows best which permissions a service user
requires. Therefore I see some value in allowing the bundle to
transport such information. However, I acknowledge that embedding such
information in the bundle could take away flexibility for deployments
to customize the setup. And as you mention, it _is_ possible to use a
different name for a service-user.
An alternative could be a repoinit installer factory for the OSGi
Installer. This would allow repoinit files to be deployed via
content-package, e.g. in an /apps/myapp/config folder.
Also a combination of the two could be worthwhile: the bundle-header
approach could be opt-in and guarded by a configuration that allows
whitelisting bundle symbolic names for which embedded repoinit scripts
should be deployed. A warning could be printed for any bundle that
contains repoinit scripts but is not whitelisted. And finally, an
"ignore"-list of bundle symbolic names could allow suppressing the
warning. The logging would draw a deployer's attention to the fact
that a bundle embeds repoinit files and ideally prompt them to
whitelist it or to add it to the ignore list. Even in the case of the
ignore list, the deployer could extract the repoinit files and modify
them.
Any custom repoinit configurations could be deployed via OSGi installer.
I am not fixed on either solution, but I would like _a_ way forward.
I'd also be happy with "just" the repoinit installer factory.
This could be done with a feature model just containing repoinit.
Now, authoring repoinit in a feature model directly is not nice either,
but if you use a maven project to create the feature model, you can make
use of
https://issues.apache.org/jira/browse/SLING-9725
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
