Hi, Am 10.04.2012 um 01:46 schrieb Mark Adamcin:
> Whatever direction this happens to go in, I don't think this should result > in changing the behavior for existing maven-sling-plugin configurations > that already use PUT. Instead, maybe there should just be a new config > parameter like <useMkcol>true</useMkcol> that defaults to false. This would > cover the most generic and widely applicable use case, which is: "I want to > create a bundle project that can deploy to any repository using jcrinstall > without requiring additional supporting content to have been created prior > to bundle activation". If users have more granular requirements like > requiring different intermediate nodetypes, then those problems have likely > already been solved with other deployment scripts or packaging formats. Instead of useMkcol we could also have a parameter <mkdirs> defaulting to false. If this is true and the PUT request fails with a 209 CONFLICT, the plugin would send a series of MKCOL requests to try to create the tree and the resend the PUT. Of course, depending on the WebDAV setup the intermediate nodes may be created with whatever node type is configured (IIRC Sling defaults to sling:Folder). Regards Felix > > Mark Adamcin > Acquity Group > > > > On Mon, Apr 9, 2012 at 4:05 PM, Justin Edelson > <[email protected]>wrote: > >> Craig, >> Feel free to submit an enhancement request, but personally I don't like >> either of these options. I'm pretty sure MKCOL will create nt:folder nodes >> and I usually prefer sling:Folder nodes for the second level under /apps. >> Conversely, the Sling POST servlet can't create intermediate folders under >> an nt:folder node (and I've typically seen /apps be an nt:folder) because >> nt:folder doesn't define a default child node type. >> >> While I agree that the current behavior is annoying at times, I don't want >> to introduce an element of surprise. >> >> Justin >> >> On Fri, Apr 6, 2012 at 1:36 PM, Craig S. Dickson <[email protected] >>> wrote: >> >>> I agree with Mark and Carsten. I think from a Maven plugin perspective, >>> the user should be able to "upload" a file, to just about any path they >>> like. The person writing the Maven pom.xml shouldn't need to worry about >>> whether the plugin is using WebDav or a Sling post or any other mechanism >>> and the specifics of how that mechanism does or doesn't work. >>> >>> Anyone have a strong feeling about either Mark's suggestion of doing >> MKCOL >>> requests at each level to make sure the path exists, or alternatively >>> Carsten's suggestion of using the Sling POST servlet instead of WebDAV? >>> >>> I think this is worth logging as an enhancement request, does anyone >>> object? >>> >>> Cheers >>> >>> >>> >>> On Apr 5, 2012, at 8:14 AM, Mark Adamcin wrote: >>> >>>> Couldn't the plugin be modified to add an option to use MKCOL requests >> at >>>> every level of the path prior to executing the PUT request? >>>> >>>> Mark Adamcin >>>> Acquity Group >>>> On Apr 5, 2012 4:01 AM, "Carsten Ziegeler" <[email protected]> >> wrote: >>>> >>>>> Maybe we could do a POST and let the Post-Servlet handle this? This >>>>> would be independent from WebDav then. >>>>> >>>>> Carsten >>>>> >>>>> 2012/4/5 Bertrand Delacretaz <[email protected]>: >>>>>>> On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson < >>>>> [email protected]>wrote: >>>>>>>> ...Is PUT'ing to a >>>>>>>> non-existent path not considered semantically correct from a REST >>>>>>>> standpoint? Or, is this just a bug or missing feature?... >>>>>> >>>>>> PUT is handled by Sling's WebDAV servlet, and >>>>>> http://www.webdav.org/specs/rfc2518.html says (about MKCOL): >>>>>> >>>>>> "When the MKCOL operation creates a new collection resource, all >>>>>> ancestors must already exist, or the method must fail with a 409 >>>>>> (Conflict) status code. For example, if a request to create >> collection >>>>>> /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/ exists, the request >>>>>> must fail." >>>>>> >>>>>> The PUT section of that spec is a bit less understandable IMO: >>>>>> >>>>>> "A PUT that would result in the creation of a resource without an >>>>>> appropriately scoped parent collection must fail with a 409 >>>>>> (Conflict)." >>>>>> >>>>>> but between the two it seems that 409 is correct when PUTting to a >>>>>> path that doesn't exist. >>>>>> >>>>>> -Bertrand >>>>> >>>>> >>>>> >>>>> -- >>>>> Carsten Ziegeler >>>>> [email protected] >>>>> >>> >>> >>
