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.
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] > > >> > > > > >
