I initially worked on a version as described previously (requiring
additional dependencies to be installed and requiring to change the
factory ids of configurations). Although I finished that work, I am not
really happy with it :)
I started a new approach which creates two bundles, the main bundle as
before - no changes (except for the internal refactoring of code). The
second bundle with the classifier "simple" contains the same code, but
has less dependencies and just supports the "file and folders" use case.
With that we do not need a breaking change for our users, but also have
a simple provider based on the exact same code base.
PR is here:
https://github.com/apache/sling-org-apache-sling-fsresource/pull/4
The PR looks large, but is in the end just moving code around and
simplifying a little bit.
Feedback and testing more than welcome.
Regards
Carsten
On 12.11.2024 11:38, Stefan Seifert wrote:
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]
--
Carsten Ziegeler
Adobe
[email protected]
