ysb33r / groovy-vfs

A DSL for Groovy on top of Apache VFS2
Other
63 stars 10 forks source link

WebDavs Support #60

Open madmas opened 9 years ago

madmas commented 9 years ago

Hi, I tried to use the gradle vfs plugin to do a upload to a owncloud folder via WebDav(s).

I found that webdav is already included in the ProviderSepcification and depends on jackrabbit, so i included JackRabbit to the buildscript dependencies: classpath 'org.apache.jackrabbit:jackrabbit-webdav:2.11.1'

then I created an task to do the upload:

task uploadDistZip << {
  // build/distributions/gradleVfsSample.zip
  vfs {
    cp new File("${buildDir}/distributions/gradleVfsSample.zip"), "webdavs://user:pass@myhost/owncloud/remote.php/webdav/Upload/gradleVfsSample.zip"
  }
}

But that way is does not work, as it does not recognise the webdavs. So I edited the ProviderSpecification and added webdavs to the schemes for the WebdavFileProvider.

But unfortunately, --debug shows that while picking up the right mechanism and authenticating with the credentials, it falls back to http at some point: 15:54:54.434 [DEBUG] [org.apache.commons.httpclient.MultiThreadedHttpConnectionManager] Getting free connection, hostConfig=HostConfiguration[host=http://myhost]

I also looked if there is a WebdavsFileProvider but in commons.vfs2 there is none :-( Has someone experience using vfs with webdavs ? Any hints where I could dig further?

thanks a lot Markus

ysb33r commented 9 years ago

It should work. I'll try to build a test case for it.

ysb33r commented 9 years ago

@madmas For may own sanity can you check the following,

            new Provider(
                    className : 'org.apache.commons.vfs2.provider.webdav.WebdavFileProvider',
                    schemes : [ 'webdav'],
                    dependsOnClasses : [
                        'org.apache.commons.httpclient.HttpClient',
                        'org.apache.jackrabbit.webdav.client.methods.DavMethod'
                    ]
            ),

That expects both the http and webdav enablers to be present i.e. you also need to have commons-httpclient:commons-httpclient:3.1 in the classpath.

Also did you use webdav:// or webdavs:// ? (The former is the correct one according to the ProviderSpecification)

ysb33r commented 9 years ago

I have managed to get some webdav-based unit tests to work on a branch. It seems that for a start that the Apache VFS webdav provider needs to have a JackRabbit < 2.0.

@madmas Can you try to use 1.6.5 of Jackrabbit to see if it works for you?

(In the mean time I;ll work on getting the unit tests all to pass against webdav).

madmas commented 9 years ago

sorry for the delay, I'm in a timeshifted environment ATM ;-)) So, to answer your first post, here ist the build.gradle and the log with webdav and log with webdavs, so I tried both.

As you can see from the buildfile, I used Jackrabbit 2.11.1. Retrying with 1.6.5 results in this log. To me, it looks like it gets confused with the http / https as it authenticates against https adress but tries to upload via http then :-(

ysb33r commented 9 years ago

09:34:52.381 [DEBUG] [httpclient.wire.content] << "

The document has moved here.

[\n]" 09:34:52.381 [DEBUG] [httpclient.wire.content] << "
[\n]"

I wonder whether you need to add ?vfs.webdav.followRedirect=1 into your URL

9:34:52.393 [ERROR] [org.gradle.BuildExceptionReporter] > Could not determine the type of file "webdav://markus:***@myhost/owncloud/remote.php/webdav/UploadExperiment".

This is indicative that someone else is going wrong underneath. I think the message is a bit of a misnomer as the webdav provider should be able to distinguish between files and fodlers (https://wiki.apache.org/commons/VfsCapabilitiesMatrix). We might be seeing this because of the redirect.

madmas commented 9 years ago

By adding the query string I get 'followRedirect' is not a valid property for 'webdav'

Also, adding a config block like

vfs {
  options {
    webdav {
      followRedirect 1
    }
  }
}

does not seem to have any effect.

About the file type: I tried both specifying the folder and the filename, which resulted in the same error message.