the slingpackager is meant to work against content management systems
built on sling. It currently supports package managers by
- Composum
- AEM
If there are other package managers in the future I'd love to add
support for them as well.
We interact with sling to install packages, not with jackrabbit. My
preference would still be to include this in sling :-) (who knows,
maybe some day sling decides not to run on jackrabbit anymore - the
sling packager could then be transformed to support the new
format/other endpoints)
Ruben
On Tue, Aug 27, 2019 at 2:32 AM, Konrad Windszus <konra...@gmx.de>
wrote:
I fully agree with that statement.
Actually there is already a task at FileVault to have an installation
endpoint (accompanied by a branch):
<https://issues.apache.org/jira/browse/JCRVLT-151>
<<https://issues.apache.org/jira/browse/JCRVLT-151>>
For all those reasons I would also rather like to see this addition
to Apache Jackrabbit.
Konrad
On 27. Aug 2019, at 11:25, Georg Henzler <ghenz...@apache.org
<mailto:ghenz...@apache.org>> wrote:
Hi,
I also have my doubts... reasoning to have it in Sling from [2]:
since the tool packages and deploys it is dependent
Jackrabbit-Vault for
the package format and on Apache Sling and Composum for the
upload/install/list/uninstall/delete endpoint. I'd honestly much
prefer
for it to be an Apache Sling module.
Composum [3] is included in the sling starter but not actually
maintained
as part of Sling. I'm not aware of any dependency the packager
would have
to Sling, so I think the Jackrabbit project would make a lot more
sense to
host the Packager tool. For instance, people not using Sling but
only
Jackrabbit could use it, also maybe at some point somebody will
eventually
create an Open Source Package Manager there (to provide the simple
endpoints
for upload/install/list/uninstall/delete without UI would be
actually really
easy, maybe it's a good time to do this now :)
-Georg
[3] <https://github.com/ist-dresden/composum>
