Re: mountByFS and Initial Content Loader
>> > 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 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 >> 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 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, i
Re: mountByFS and Initial Content Loader
On Wed, Jan 6, 2010 at 8:53 AM, Vidar Ramdal 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 > 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 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 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 - 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
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 cziege...@apache.org
mountByFS and Initial Content Loader
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 - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 21 531941, ext 2070