You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by "Craig S. Dickson" <cr...@craigsdickson.com> on 2012/04/04 23:16:35 UTC
Issue using PUT with maven-sling-plugin and non-existent path
Hi,
I have the following configuration for the maven-sling-plugin in my project - notice I have the usePut configuration parameter set to true as I want to upload the bundle to a specific location in JCR tree.
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>maven-sling-plugin</artifactId>
<executions>
<execution>
<id>install-bundle</id>
<goals>
<goal>install</goal>
</goals>
<configuration>
<slingUrl>http://${cq.host}:${cq.port}</slingUrl>
<slingUrlSuffix>/apps/cqblueprints/examples/apachecxf/install</slingUrlSuffix>
<user>${cq.user}</user>
<password>${cq.password}</password>
<usePut>true</usePut>
<failOnError>true</failOnError>
</configuration>
</execution>
</executions>
</plugin>
This works as expected if the path that the slingUrlSuffix points to already exists in the JCR tree.
However if the path does not exist, the Maven build errors out with a message like:
[ERROR] Failed to execute goal org.apache.sling:maven-sling-plugin:2.1.0:install (install-bundle) on project cqblueprints-examples-apachecxf-service: Installation on http://localhost:4502/apps/cqblueprints/examples/apachecxf/install failed, cause: Installation failed, cause: Conflict -> [Help 1]
I am wondering if this is the correct/desired behavior? 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?
Thanks
==========================
Craig S. Dickson
Independent Consultant
http://craigsdickson.com
http://www.linkedin.com/in/craigsdickson
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by Carsten Ziegeler <cz...@apache.org>.
I think usePut could do a Sling-POST.
Carsten
2012/4/18 Felix Meschberger <fm...@adobe.com>:
> Hi,
>
> Am 17.04.2012 um 19:06 schrieb Carsten Ziegeler:
>
>> 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 :)
>
> So usePut would do a Sling-POST ? Or introduce another configuration element ?
>
> Currently the default is to do a POST against the Web Console. And I think this is good and makes sense (even though this functionality maybe belongs to the Felix project)
>
> Regards
> Felix
>
>>
>> Carsten
>>
>> 2012/4/17 Felix Meschberger <fm...@adobe.com>:
>>> 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 <ju...@justinedelson.com>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 <craig@craigsdickson.com
>>>>>> 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" <cz...@apache.org>
>>>>> 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 <bd...@apache.org>:
>>>>>>>>>> On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson <
>>>>>>>> craig@craigsdickson.com>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
>>>>>>>> cziegeler@apache.org
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 17.04.2012 um 19:06 schrieb Carsten Ziegeler:
> 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 :)
So usePut would do a Sling-POST ? Or introduce another configuration element ?
Currently the default is to do a POST against the Web Console. And I think this is good and makes sense (even though this functionality maybe belongs to the Felix project)
Regards
Felix
>
> Carsten
>
> 2012/4/17 Felix Meschberger <fm...@adobe.com>:
>> 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 <ju...@justinedelson.com>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 <craig@craigsdickson.com
>>>>> 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" <cz...@apache.org>
>>>> 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 <bd...@apache.org>:
>>>>>>>>> On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson <
>>>>>>> craig@craigsdickson.com>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
>>>>>>> cziegeler@apache.org
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <fm...@adobe.com>:
> 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 <ju...@justinedelson.com>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 <craig@craigsdickson.com
>>>> 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" <cz...@apache.org>
>>> 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 <bd...@apache.org>:
>>>>>>>> On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson <
>>>>>> craig@craigsdickson.com>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
>>>>>> cziegeler@apache.org
>>>>>>
>>>>
>>>>
>>>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by Felix Meschberger <fm...@adobe.com>.
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 <ju...@justinedelson.com>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 <craig@craigsdickson.com
>>> 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" <cz...@apache.org>
>> 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 <bd...@apache.org>:
>>>>>>> On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson <
>>>>> craig@craigsdickson.com>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
>>>>> cziegeler@apache.org
>>>>>
>>>
>>>
>>
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Apr 10, 2012 at 1:46 AM, Mark Adamcin <ad...@gmail.com> wrote:
> ...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"...
I'd rather suggest a parameter that's the node type to use to create
intermediate folders in this case (empty means don't create them, as
now), and let the plugin work out how to create them.
-Bertrand
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by Mark Adamcin <ad...@gmail.com>.
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 <ju...@justinedelson.com>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 <craig@craigsdickson.com
> >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" <cz...@apache.org>
> 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 <bd...@apache.org>:
> > >>>> On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson <
> > >> craig@craigsdickson.com>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
> > >> cziegeler@apache.org
> > >>
> >
> >
>
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by Justin Edelson <ju...@justinedelson.com>.
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 <cr...@craigsdickson.com>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" <cz...@apache.org> 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 <bd...@apache.org>:
> >>>> On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson <
> >> craig@craigsdickson.com>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
> >> cziegeler@apache.org
> >>
>
>
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by "Craig S. Dickson" <cr...@craigsdickson.com>.
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" <cz...@apache.org> 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 <bd...@apache.org>:
>>>> On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson <
>> craig@craigsdickson.com>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
>> cziegeler@apache.org
>>
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by Mark Adamcin <ad...@gmail.com>.
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" <cz...@apache.org> 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 <bd...@apache.org>:
> >> On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson <
> craig@craigsdickson.com>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
> cziegeler@apache.org
>
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <bd...@apache.org>:
>> On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson <cr...@craigsdickson.com>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
cziegeler@apache.org
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by Bertrand Delacretaz <bd...@apache.org>.
> On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson <cr...@craigsdickson.com>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
Re: Issue using PUT with maven-sling-plugin and non-existent path
Posted by Justin Edelson <ju...@justinedelson.com>.
Craig-
I believe this is the defined behavior for WebDAV, but I honestly have
never looked it up.
Regards,
Justin
On Wed, Apr 4, 2012 at 5:16 PM, Craig S. Dickson <cr...@craigsdickson.com>wrote:
> Hi,
>
> I have the following configuration for the maven-sling-plugin in my
> project - notice I have the usePut configuration parameter set to true as I
> want to upload the bundle to a specific location in JCR tree.
>
> <plugin>
> <groupId>org.apache.sling</groupId>
> <artifactId>maven-sling-plugin</artifactId>
> <executions>
> <execution>
> <id>install-bundle</id>
> <goals>
> <goal>install</goal>
> </goals>
> <configuration>
> <slingUrl>
> http://${cq.host}:${cq.port}</slingUrl>
>
> <slingUrlSuffix>/apps/cqblueprints/examples/apachecxf/install</slingUrlSuffix>
> <user>${cq.user}</user>
> <password>${cq.password}</password>
> <usePut>true</usePut>
> <failOnError>true</failOnError>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> This works as expected if the path that the slingUrlSuffix points to
> already exists in the JCR tree.
>
> However if the path does not exist, the Maven build errors out with a
> message like:
>
>
> [ERROR] Failed to execute goal
> org.apache.sling:maven-sling-plugin:2.1.0:install (install-bundle) on
> project cqblueprints-examples-apachecxf-service: Installation on
> http://localhost:4502/apps/cqblueprints/examples/apachecxf/install failed,
> cause: Installation failed, cause: Conflict -> [Help 1]
>
>
> I am wondering if this is the correct/desired behavior? 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?
>
> Thanks
>
>
>
> ==========================
> Craig S. Dickson
> Independent Consultant
> http://craigsdickson.com
> http://www.linkedin.com/in/craigsdickson
>
>