i think a) is fine, if we make a new major version 3.x and document it properly.
the initial idea of embedding the additional bundles was to make it easier if you manually upload the fsresource bundle for development or debugging reason to an existing instance. but as we have a goal in the sling maven plugin that can take care of this (including uploading the dependency bundles) when mounting the folders, that's not a big issue to no longer embedding them. stefan > -----Original Message----- > From: Carsten Ziegeler <[email protected]> > Sent: Tuesday, November 12, 2024 7:40 AM > To: [email protected] > Subject: Re: [RT] Simple File System Resource Provider > > It seems we have already an abstraction which separates the different > modes of the fs provider. Unfortunately this abstraction had some holes. > Long story story, in [1] I refactored the code and removed the leakage, > and then added dynamic import packages for all packages which are not > needed for the simple mode (just mapping files and directories directly > to resources). > That seems to work. > > However, the current version of the fs provider bundle *embedds* the > content parser api and implementations which is something we probably > shouldn't have done in the first place. We should make this a real > dependency. > > I think we have three options here: > > a) Right now, the bundle uses a single factory configuration with a mode > property selecting between the three different implementations. By not > embedding and requiring additional bundles to be installed we have a > breaking change for the fs provider. Instead of having a single factory > configuration with a mode, we switch to three different factory > configurations. This gives a clear cut, especially as some of the > configuration properties only make sense for a particular mode. Updating > to the latest version then means, adjusting the factory pid of the > configuration and installing the additional bundles. > > b) The content parser bundles currently use (correctly) OSGi services > which makes it a little bit complicated to integrate into the fs > provider code base. We could update the content parser bundles and > provide in addition to the OSGi services a static method to generate the > parsers. > > c) We switch from using DS in the fs provider bundle and basically > implement the configuration and service ranking ourselves by using the > framework api. > > Now, clearly c) is not something we want to do. b) sounds wrong to me as > well. a) is simple but also a clear path forward. > > Thoughts? > > [1] > https://github.com/apache/sling-org-apache-sling- > fsresource/tree/dynamicdependencies > > Regards > Carsten > > On 06.11.2024 18:35, Carsten Ziegeler wrote: > > I'll look next if we can instead have a single code base with optional > > imports. While the code is currently rely complex, there is some > > potential to refactor this a little bit and separate things. > > > > Regards > > Carsten > > > > On 04.11.2024 08:48, Carsten Ziegeler wrote: > >> Right now I see no good, easy way to do this. > >> > >> The code is at https://github.com/apache/sling-org-apache-sling- > >> fsresource/tree/simple > >> > >> My idea was to release this version out of a branch with different > >> maven coordinates - not ideal, but creating a new repo just for this > >> does not make too much sense either. I don't expect that we will many > >> releases of this - it is simple and should stay simple. > >> > >> Regards > >> Carsten > >> > >> On 04.11.2024 03:42, Konrad Windszus wrote: > >>> Hi, > >>> As we discussed briefly during our Hackathon introducing another SPI > >>> for the resource deserialisation is too much overhead. > >>> IIUC still there is a big overlap between the source of the simple > >>> and regular file provider. > >>> > >>> If we can express the differences by only configuring the bnd-maven- > >>> plugin differently between those two IMHO it makes sense to share the > >>> same repo. > >>> The simple one should get an additional classifier (for deploying to > >>> Maven Central) as well as a different BSN (to make it easy to > >>> identity it and to also potentially allow to deploy both in parallel). > >>> However both should share the same version and should be released > >>> together if they live in one repo. > >>> > >>> Konrad > >>> > >>> > >>> > >>>> On 4. Nov 2024, at 11:43, Stefan Seifert <stefan.seifert@diva- > >>>> e.com.INVALID> wrote: > >>>> > >>>> i think it will be quite confusing for users to have to different > >>>> versions with same bundle name for those different use cases. in the > >>>> (although unlikely) case you want to use both on the same instance, > >>>> this also gets difficult with maintaining the OSGi configurations. > >>>> > >>>> maybe better making a separate git repo with separate bundle and > >>>> package name out of it? > >>>> > >>>> stefan > >>>> > >>>>> -----Original Message----- > >>>>> From: Carsten Ziegeler <[email protected]> > >>>>> Sent: Tuesday, October 29, 2024 5:02 AM > >>>>> To: [email protected] > >>>>> Subject: Re: [RT] Simple File System Resource Provider > >>>>> > >>>>> Found this old thread about a simple file system resource provider. > >>>>> > >>>>> Back then we identified that if makes sense to have two flavors of a > >>>>> file system based resource provider - a simple one just mapping > files > >>>>> directly to resources - and the current one which adds a lot of > >>>>> additional features on top. > >>>>> > >>>>> Though I created a simple version in the whiteboard some time ago I > >>>>> never looked at the 1.x branch of the existing one and whether it > >>>>> makes > >>>>> sense to merge these (if needed). > >>>>> > >>>>> Even if we have two flavors it still makes sense to create them > >>>>> from the > >>>>> same git repository (bundle) - just with different major versions. > >>>>> > >>>>> Regards > >>>>> Carsten > >>>>> > >>>>> On 12.11.2018 03:20, Carsten Ziegeler wrote: > >>>>>> Yes, I was thinking of using the 1.x branch, however that branch > >>>>>> is at > >>>>>> version 1.3.x which contains a lot of the unneeded (from my pov) as > >>>>> well. > >>>>>> > >>>>>> Maybe I just start a prototype in the whiteboard and then we can > >>>>>> figure > >>>>>> out what to do about it :) > >>>>>> > >>>>>> As a side note, the markdown resource provider in the whiteboard is > >>>>>> another file system based rp which is closer to my use case, > >>>>>> except that > >>>>>> it supports markdown files instead of json. > >>>>>> > >>>>>> Regards > >>>>>> Carsten > >>>>>> > >>>>>> Am 12.11.2018 um 12:03 schrieb Stefan Seifert: > >>>>>>> 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:[email protected]] > >>>>>>>> Sent: Monday, November 12, 2018 11:51 AM > >>>>>>>> To: [email protected]; 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:[email protected]] > >>>>>>>>>> Sent: Monday, November 12, 2018 11:20 AM > >>>>>>>>>> To: [email protected]; 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:[email protected]] > >>>>>>>>>>>> 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 > >>>>>>>>>>>> [email protected] > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Carsten Ziegeler > >>>>>>>>>> Adobe Research Switzerland > >>>>>>>>>> [email protected] > >>>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Carsten Ziegeler > >>>>>>>> Adobe Research Switzerland > >>>>>>>> [email protected] > >>>>>>> > >>>>>> > >>>>> > >>>>> -- > >>>>> Carsten Ziegeler > >>>>> Adobe > >>>>> [email protected] > >>>> > >>> > >> > > > > -- > Carsten Ziegeler > Adobe > [email protected]
