yes, the current implementation of the fsresource provider is no longer any simple.
it currently supports three (configurable) modes: 1. simple mapping of folders and binary files from filesystem (this was the starting point of fsresource) 2. reading structured resource data from JSON files and folders in the same way it is done by the content loader 3. reading structured resource data from FileVault XML files as it's stored in content packages and features: a) sending resource events if any of these files are changed in runtime b) implement some caching to speed things up c) support not only the Sling Resource API, but also simulate an underlying JCR API for code that runs on top which is still using the JCR API for cases where also the Sling Resource API would suffice but cannot be changed because it's part of a product... so the use case ranges from simple mapping of a bunch of static files to full-blown emulation of a JCR repository out of a complex project structure in the filesystem e.g. for usage in a development environemnt (see [0]). --- removing the embedded json libraries should be simple, it was only for convenience when the fsresource bundle is to deployed afterwards to an existing instance. but the dependencies to all those JCR-related bundles remains as long as all three modes and features need to be supported. i'm not sure if implementing a new fsresource provider e.g. only for 1.+2. from scratch would be the best way. there is a lot of special logic for edge cases esp. in 2. to make sure it behaves the same as the content loader which we have then to duplicate another time. it should be possible to split the existing fsresource into a core and extension bundle as it's somewhat separated already due to the different supported modes 1./2./3., and the virtual JCR API support could be made configurable as well. supporting Java 8 features for the filesystem changes detection would be a good thing; last time i was looking into it i failed to make good use of it due to strange implementation differences on windows and unix file systems (and those differences where covered by the JavaDocs). but maybe there is a way to do it right. stefan [0] https://adapt.to/2017/en/schedule/ease-development-with-apache-sling-file-system-resource-provider.html >-----Original Message----- >From: Carsten Ziegeler [mailto:cziege...@apache.org] >Sent: Sunday, November 11, 2018 10:56 AM >To: Sling Developers >Subject: [RT] Simple File System Resource Provider > >I've recently tried to run a minimal Sling without JCR. Obviously you >need at least one resource provider to have some content, so I picked >the easiest choice, the file system resource provider. > >However, it turned out that this is not the easiest choice for this >scenario as it has a lot of features, especially support for handling >content XML files and vault files, which again brings in the whole >dependency list to jcr related bundles. In my case I just want to stream >binaries and json files, so none of the above is needed. But still I >need to deploy all the bundles. In addition there are other things like >the json parsing library is embedded in the bundle etc. > >Now, I think we should really have a simple file system resource >provider which only does the basics and has not an endless list of >bundles. I see two ways to get there: make the current provider >extensible and provide all this extra cruft as extensions or write a new >simple provider. > >Thoughts? > >Regards >Carsten >-- >Carsten Ziegeler >Adobe Research Switzerland >cziege...@apache.org
