ah, ok - this sounds like fsresource 1.2.2 (all the new stuff was added in 2.x). in this case it might make sense to create a new bundle without the existing one, or maintain the 1.x branch in parallel to 2.x or fork it to a new bundle.
stefan >-----Original Message----- >From: Carsten Ziegeler [mailto:cziege...@apache.org] >Sent: Monday, November 12, 2018 11:51 AM >To: dev@sling.apache.org; Stefan Seifert >Subject: Re: [RT] Simple File System Resource Provider > >It's only 1 - 2 from your list is taking a structured json and creates >resources out of the structure (if I'm not mistaken) which is something >I don't need. > >With the approach I hope there is no need for b) (caching) as the >mapping is 1:1 (more or less). As there is no need for cachign I don't >think a) is needed either. > >Regards >Carsten > >Am 12.11.2018 um 11:23 schrieb Stefan Seifert: >> so from my list below your use case is 1. + 2. + a) + probably b) and >leaving out the other parts? >> or something different from what is implemented currently? >> >> stefan >> >>> -----Original Message----- >>> From: Carsten Ziegeler [mailto:cziege...@apache.org] >>> Sent: Monday, November 12, 2018 11:20 AM >>> To: dev@sling.apache.org; Stefan Seifert >>> Subject: Re: [RT] Simple File System Resource Provider >>> >>> Hi, >>> >>> I would be totally happy if we can factor out the extensions, I'm >>> wondering however if this is worth the effort. >>> >>> In my use case, I would like to have a simple mapping to directories and >>> files, supporting json and binary files. So a resource maps to a json >>> file 1:1 regardless of the structure of the json file and a such a >>> resource can have an additional binary. >>> >>> I understand the need for the support of all the other features we have >>> today, but they are not needed for other use cases. >>> >>> Regards >>> Carsten >>> >>> Am 12.11.2018 um 11:06 schrieb Stefan Seifert: >>>> 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 >>>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org >> > >-- >Carsten Ziegeler >Adobe Research Switzerland >cziege...@apache.org
