mountByFS and Initial Content Loader

[Vidar Ramdal <vi...@idium.no>]

The maven-sling-plugin has the very useful feature mountByFS, which
automatically sets up FsResourceProviders for the initial-content in
the bundle.
This is great for development, as you can work directly on the files
in the bundle, without having to re-deploy the bundle for each change.

However, the mountByFS feature relies on the Sling-Initial-Content
header to decide which paths should be mapped. This crashes with the
Sling Content Loader bundle, which also looks for that header. So, if
the Content Loader bundle is active when you deploy a bundle with
mountByFS, you'll end up with both FsResourceProviders AND initial
content in the repository. This defies the purpose of mountByFS, and
usually also leads to some unexpected behavior in resource resolution.

So how about letting maven-sling-plugin support another config element
in addition to Sling-Initial-Content, say, Sling-Mount-File-Resources.
That way, the Content Loader bundle should not interfere when the
mountByFS bundle is deployed.

WDYT?

-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: mountByFS and Initial Content Loader

[Vidar Ramdal <vi...@idium.no>]

>> > Vidar Ramdal wrote:
>> >> However, the mountByFS feature relies on the Sling-Initial-Content
>> >> header to decide which paths should be mapped. This crashes with the
>> >> Sling Content Loader bundle, which also looks for that header. So, if
>> >> the Content Loader bundle is active when you deploy a bundle with
>> >> mountByFS, you'll end up with both FsResourceProviders AND initial
>> >> content in the repository. This defies the purpose of mountByFS, and
>> >> usually also leads to some unexpected behavior in resource resolution.

On Wed, Jan 6, 2010 at 4:36 PM, Justin Edelson <ju...@gmail.com> wrote:
> Could you explain what "unexpected behavior" you're referring to? The
> FsResourceProvider overrides content in the repository, which I think is the
> expected behavior.

Yes, that is the behavior I expect - sorry for being vague. When
trying to reproduce any problems right now, of course everything
works, so this is just from the top of my head:
The bundle I'm usually deploying this way includes a whole lot of ESP
scripts, and I have had situations where I change the script file, but
the old script is being run by Sling. I just assumed that it was the
script file in the repository that was being run despite the presence
of the FsResourceProvider, but it could of course be a completely
different issue.

> On Wed, Jan 6, 2010 at 2:29 PM, Carsten Ziegeler <cz...@apache.org>
>> wrote:
>> > [...]
>> > My usual development environment uses this feature together with initial
>> > content headers and so far I never experienced a problem - it is true
>> > that the content is also installed into the repository but the resources
>> > mounted through the fs provider take precedence - at least they do it in
>> > my case :)
>>
> Me too.

Is this behavior guaranteed? I mean, will the FsResourceProvier always
take precedence over the JcrResourceProvider?

>> >> So how about letting maven-sling-plugin support another config element
>> >> in addition to Sling-Initial-Content, say, Sling-Mount-File-Resources.
>> >> That way, the Content Loader bundle should not interfere when the
>> >> mountByFS bundle is deployed.

> Sorry, but what's the point of this? If you just want to use
> FsResourceProvider(s), do that, but then don't create a bundle because the
> bundle isn't usable in that installing it into the OSGi container won't add
> the content.

You might have bundles that contain both java classes and file
resources, where you'd want to map the files as an FsResource.

> So I think this addition would have a strong likelihood of creating confusion. Imagine this scenario:
>
> 1) I start development on a content bundle. 2) I read the plugin docs and
> see that I can add a Sling-Mount-File-Resources header for "rapid
> development" (and, hey, who doesn't love rapid development) 3) I run mvn
> sling:install (or have sling:install bound to the install phase) 4) Develop,
> test, repeat, etc. 5) I'm ready to deploy my content bundle to production, I
> use the Felix console to install the bundle. 6) My content doesn't show
> up... FAIL
> You could also replace #5 with "I distribute my content bundle to a
> co-worker and they install it into their local instance" or "I deploy my
> bundle to an OBR repository and install it from there"

Those are valid points, indeed, which I didn't think about. In my
case, I'd use Sling-Mount-File-Resources only with a 'dev' build
profile, but there's no guarantee that others will.

>>> Now, I think we should a) add the additional config element and b) see
>>> which problems you have when the initial content header is used. Maybe
>>> we can fix them as well.

> On Wed, Jan 6, 2010 at 8:53 AM, Vidar Ramdal <vi...@idium.no> wrote:
>> Great. As I said, I'll gather some more details on b). Nonetheless, I
>> too believe it would be useful to have a method of just installing
>> FsResourceProviders without loading the content, if only to reduce the
>> time it takes to deploy. So a) =>
>> https://issues.apache.org/jira/browse/SLING-1271
>
> Is this performance issue real? AFAICT, Loading of content into the
> repository is asynchronous (if not, that's a separate problem which should
> be dealt with).

I didn't mean performance of the content loader, just the copying of
resources during the maven build.

> What may make sense is to create a Maven goal which doesn't require a
> project or interact with the lifecycle to easily create new
> FsResourceProviders. Something like:
>
> $ mvn sling:add-fs-provider -Dsrc=. -Ddest=/libs/testcontent
>
> (which would create a new FsResourceProvider mapping /libs/testcontent to
> the current directory).

That could work, but I'd prefer getting those parameters from the pom.
If you have to run a mvn sling:add-fs-provider for each provider, you
could just as well use curl.

I see now that SLING-1271 may introduce problems I didn't think about
(especially the deploy-via-web-console/OBR scenario), and I could just
implement the behavior I want in my own maven plugin, instead of
modifying maven-sling-plugin.
So, if there's no other strong points in favor of
Sling-Mount-File-Resources right now, I'll put SLING-1271 on hold.
I'll look more into the content loader issue when I get time (which I
don't have right now).

-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: mountByFS and Initial Content Loader

[Justin Edelson <ju...@gmail.com>]

On Wed, Jan 6, 2010 at 8:53 AM, Vidar Ramdal <vi...@idium.no> wrote:

> > Vidar Ramdal wrote:
> >> However, the mountByFS feature relies on the Sling-Initial-Content
> >> header to decide which paths should be mapped. This crashes with the
> >> Sling Content Loader bundle, which also looks for that header. So, if
> >> the Content Loader bundle is active when you deploy a bundle with
> >> mountByFS, you'll end up with both FsResourceProviders AND initial
> >> content in the repository. This defies the purpose of mountByFS, and
> >> usually also leads to some unexpected behavior in resource resolution.
>
Could you explain what "unexpected behavior" you're referring to? The
FsResourceProvider overrides content in the repository, which I think is the
expected behavior.

On Wed, Jan 6, 2010 at 2:29 PM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > [...]
> > My usual development environment uses this feature together with initial
> > content headers and so far I never experienced a problem - it is true
> > that the content is also installed into the repository but the resources
> > mounted through the fs provider take precedence - at least they do it in
> > my case :)
>
Me too.


> That's useful information. I just took for granted that mountByFS and
> the content loader combination was not particularly common. I'll keep
> an eye open next time I deploy, to try to see exactly what fails.
>
> >> So how about letting maven-sling-plugin support another config element
> >> in addition to Sling-Initial-Content, say, Sling-Mount-File-Resources.
> >> That way, the Content Loader bundle should not interfere when the
> >> mountByFS bundle is deployed.
>

Sorry, but what's the point of this? If you just want to use
FsResourceProvider(s), do that, but then don't create a bundle because the
bundle isn't usable in that installing it into the OSGi container won't add
the content. So I think this addition would have a strong likelihood of
creating confusion. Imagine this scenario:

1) I start development on a content bundle. 2) I read the plugin docs and
see that I can add a Sling-Mount-File-Resources header for "rapid
development" (and, hey, who doesn't love rapid development) 3) I run mvn
sling:install (or have sling:install bound to the install phase) 4) Develop,
test, repeat, etc. 5) I'm ready to deploy my content bundle to production, I
use the Felix console to install the bundle. 6) My content doesn't show
up... FAIL

You could also replace #5 with "I distribute my content bundle to a
co-worker and they install it into their local instance" or "I deploy my
bundle to an OBR repository and install it from there"

> Now, I think we should a) add the additional config element and b) see
> > which problems you have when the initial content header is used. Maybe
> > we can fix them as well.
>
> Great. As I said, I'll gather some more details on b). Nonetheless, I
> too believe it would be useful to have a method of just installing
> FsResourceProviders without loading the content, if only to reduce the
> time it takes to deploy. So a) =>
> https://issues.apache.org/jira/browse/SLING-1271

Is this performance issue real? AFAICT, Loading of content into the
repository is asynchronous (if not, that's a separate problem which should
be dealt with).

What may make sense is to create a Maven goal which doesn't require a
project or interact with the lifecycle to easily create new
FsResourceProviders. Something like:

$ mvn sling:add-fs-provider -Dsrc=. -Ddest=/libs/testcontent

(which would create a new FsResourceProvider mapping /libs/testcontent to
the current directory).

Justin

Re: mountByFS and Initial Content Loader

[Vidar Ramdal <vi...@idium.no>]

> Vidar Ramdal wrote:
>> The maven-sling-plugin has the very useful feature mountByFS, which
>> automatically sets up FsResourceProviders for the initial-content in
>> the bundle.
>> This is great for development, as you can work directly on the files
>> in the bundle, without having to re-deploy the bundle for each change.
>>
>> However, the mountByFS feature relies on the Sling-Initial-Content
>> header to decide which paths should be mapped. This crashes with the
>> Sling Content Loader bundle, which also looks for that header. So, if
>> the Content Loader bundle is active when you deploy a bundle with
>> mountByFS, you'll end up with both FsResourceProviders AND initial
>> content in the repository. This defies the purpose of mountByFS, and
>> usually also leads to some unexpected behavior in resource resolution.

On Wed, Jan 6, 2010 at 2:29 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> [...]
> My usual development environment uses this feature together with initial
> content headers and so far I never experienced a problem - it is true
> that the content is also installed into the repository but the resources
> mounted through the fs provider take precedence - at least they do it in
> my case :)

That's useful information. I just took for granted that mountByFS and
the content loader combination was not particularly common. I'll keep
an eye open next time I deploy, to try to see exactly what fails.

>> So how about letting maven-sling-plugin support another config element
>> in addition to Sling-Initial-Content, say, Sling-Mount-File-Resources.
>> That way, the Content Loader bundle should not interfere when the
>> mountByFS bundle is deployed.

> I'm not against adding an additonal configuration element for this
> purpose. I started with the initial content header as this was already
> available and used :)
>
> Now, I think we should a) add the additional config element and b) see
> which problems you have when the initial content header is used. Maybe
> we can fix them as well.

Great. As I said, I'll gather some more details on b). Nonetheless, I
too believe it would be useful to have a method of just installing
FsResourceProviders without loading the content, if only to reduce the
time it takes to deploy. So a) =>
https://issues.apache.org/jira/browse/SLING-1271


-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: mountByFS and Initial Content Loader

[Carsten Ziegeler <cz...@apache.org>]

Hi,

Vidar Ramdal wrote:
> The maven-sling-plugin has the very useful feature mountByFS, which
> automatically sets up FsResourceProviders for the initial-content in
> the bundle.
> This is great for development, as you can work directly on the files
> in the bundle, without having to re-deploy the bundle for each change.
> 
> However, the mountByFS feature relies on the Sling-Initial-Content
> header to decide which paths should be mapped. This crashes with the
> Sling Content Loader bundle, which also looks for that header. So, if
> the Content Loader bundle is active when you deploy a bundle with
> mountByFS, you'll end up with both FsResourceProviders AND initial
> content in the repository. This defies the purpose of mountByFS, and
> usually also leads to some unexpected behavior in resource resolution.
actually the initial idea of this feature was to reduce turnaround times
during development. Instead of copying changed scripts into the
repository (either by deploying the bundle and then using initial
content) or by using a copy through webdav, the scripts get directly
mounted into the resource tree.

My usual development environment uses this feature together with initial
content headers and so far I never experienced a problem - it is true
that the content is also installed into the repository but the resources
mounted through the fs provider take precedence - at least they do it in
my case :)

> 
> So how about letting maven-sling-plugin support another config element
> in addition to Sling-Initial-Content, say, Sling-Mount-File-Resources.
> That way, the Content Loader bundle should not interfere when the
> mountByFS bundle is deployed.
I'm not against adding an additonal configuration element for this
purpose. I started with the initial content header as this was already
available and used :)

Now, I think we should a) add the additional config element and b) see
which problems you have when the initial content header is used. Maybe
we can fix them as well.

Regards
Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org