I would be very happy if we don't add a dependency on webdav - I still think we should rather use Sling stuff which is the post servlet :)
Carsten 2012/4/17 Felix Meschberger <[email protected]>: > 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] >>>>>> >>>> >>>> >>> > -- Carsten Ziegeler [email protected]
