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 <cziege...@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
