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 <[email protected]>
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]
