>> > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 21 531941, ext 2070
