Thanks for your very detailed analysis and report about the problems with Ivy 2 and webdav, this will obviously help to get this working for Ivy 2. I won't be able to work on that myself though, at least not in the coming weeks, I'm very busy ATM.
IMO the biggest issue is the httpclient version. I don't think downgrading Ivy to httpclient 2 would make much sense, but it seems that commons vfs developers are very busy, so upgrading to httpclient 3 is maybe not in their priority. Maybe this is something where one should help, not sure if they would be ok to make this upgrade though... Xavier On Nov 15, 2007 6:58 PM, Ivan Rambius Ivanov <[EMAIL PROTECTED]> wrote: > Hello, > > I am using Ivy with a webdav repository to manage the > dependencies of some J2EE projects and I am upgrading > from Ivy 1.4.1 to Ivy 2.0. I would like to discuss a > couple of issues I bumped into. > > First, Jakarta Slide project [0] was retired a month > ago and has been replaced by Apache Jackrabbit. This > has nothing to do with ivy since its webdav support is > provided by VFS. It is more a VFS problem, because VFS > depends on Slide. I do not know if commons-vfs > developers will use Jackrabbit, but if so it will > reflect on Ivy as well. > > Second, commons-vsf has been split into > commons-vfs.jar and commons-vfs-sandbox.jar. The > webdav support is provided by commons-vfs-sandbox.jar, > see [1]: "Due to some technical reasons we had to move > the webdav and jcifs (smb) filesystem to the sandbox. > So if you need one of these filesystems you have to > build VFS manually." > > Ivy does not come with commons-vfs-sandbox.jar and I > believe it should in order to prevent its users from > the hassle of building commons-vfs themselves. I > myself built it from commons-vfs 1.0 source. I > submitted the following issue about this: > http://issues.apache.org/jira/browse/IVY-643 > > Third, ivy reads its vfs providers from > org\apache\ivy\plugins\repository\vfs\ivy_vfs.xml and > the webdav provider is not listed there. I have two > ideas about this: either delegate the setup of the vfs > providers to common-vfs or extend ivy to accept a > custom vfs-provider.xml file. For now I just copied > the definition of all providers coming with > commons-vfs to > org\apache\ivy\plugins\repository\vfs\ivy_vfs.xml and > rebuilt ivy. > > Fourth, commons-vfs 1.0 depends on commons-httpclient > 2.0 [2] and ivy is shipped with commons-httpclient > 3.0. When I use commons-vfs 1.0 with > commons-httpclient 3.0 I get an AbstractMethodError: > java.lang.AbstractMethodError > at > org.apache.commons.httpclient.HttpClient.setHttpConnectionManager( > HttpClient.java:472) > at > > org.apache.commons.vfs.provider.webdav.WebdavClientFactory.createConnection > (WebdavClientFactory.java:107) > at > > org.apache.commons.vfs.provider.webdav.WebdavFileProvider.doCreateFileSystem > (WebdavFileProvider.java:86) > at > org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile( > AbstractOriginatingFileProvider.java:81) > at > org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile( > AbstractOriginatingFileProvider.java:62) > at > org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile( > DefaultFileSystemManager.java:641) > at > org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile( > DefaultFileSystemManager.java:602) > at > org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile( > DefaultFileSystemManager.java:570) > at > org.apache.ivy.plugins.repository.vfs.VfsResource.init(VfsResource.java > :64) > at > org.apache.ivy.plugins.repository.vfs.VfsResource.physicallyExists( > VfsResource.java:181) > at > org.apache.ivy.plugins.repository.vfs.VfsRepository.put(VfsRepository.java > :204) > at > org.apache.ivy.plugins.repository.AbstractRepository.put( > AbstractRepository.java:130) > at > org.apache.ivy.plugins.resolver.RepositoryResolver.put( > RepositoryResolver.java:174) > at > org.apache.ivy.plugins.resolver.RepositoryResolver.publish( > RepositoryResolver.java:168) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:221) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:188) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:152) > at org.apache.ivy.Ivy.publish(Ivy.java:320) > at > org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:299) > at > org.apache.ivy.ant.IvyTask.execute(IvyTask.java:281) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) > at org.apache.tools.ant.Task.perform(Task.java:364) > at > org.apache.tools.ant.Target.execute(Target.java:341) > at > org.apache.tools.ant.Target.performTasks(Target.java:369) > at > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) > at > org.apache.tools.ant.Project.executeTarget(Project.java:1185) > at > org.apache.tools.ant.helper.DefaultExecutor.executeTargets( > DefaultExecutor.java:40) > at > org.apache.tools.ant.Project.executeTargets(Project.java:1068) > at org.apache.tools.ant.Main.runBuild(Main.java:668) > at org.apache.tools.ant.Main.startAnt(Main.java:187) > at > org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) > at > org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) > > I then tried to compile commons-vfs with > commons-httpclient 3.0 and it gives me the following > error: > [javac] > > C:\install\apache\commons\vfs\vfs-trunk\core\src\main\java\org\apache\commons\vfs\provider\http\ThreadLocalHttpConnectionManager.java:25: > org.apache.commons.vfs.provider.http.ThreadLocalHttpConnectionManager > is not abstract and does not override abstract method > setParams(org.apache.commons.httpclient.params.HttpConnectionManagerParams > ) > in org.apache.commons.httpclient.HttpConnectionManager > [javac] public class > ThreadLocalHttpConnectionManager implements > HttpConnectionManager > > So commons-vfs 1.0 does not work with > commons-httpclient 3.0+. I thought of submitting a bug > in commons-vfs jira, but the vfs docs say explicitly > it uses httpclient 2.0 (not 2.0+ for example). I am > using commons-httpclient-2.0-final.jar successfully. > Still, what is the best way to proceed - downgrade > ivy's httpclient to 2.0+ or ask commons-vfs to use > httpclient 3.0+? > > To sum up: the following set of versions provides the > webdav support for me: ivy 2.0.0-alpha2 with hijacked > ivy-vfs.xml for the webdav vfs provider, commons-vfs > 1.0 and commons-httpclient-2.0-final. The other jars > are the same as shipped by ivy. > > Finally, let me explain why I need webdav for my ivy > repository. WebDAV has the ability to assign custom > properties to files and directories. Our J2EE > application is built by CruiseControl and then > deployed by CruiseControl with automated scripts to a > couple of J2EE environments. At the end of each > deployment we assign properties to the artifacts with > the date of the deployment, who did it and to which > environment. Thus we can easily keep track of what is > deployed where. > > Regards > Rambius > > [0] http://jakarta.apache.org/slide/ > [1] http://commons.apache.org/vfs/index.html > [2] http://commons.apache.org/vfs/download.html > > > > Tangra Mega Rock: http://www.radiotangra.com/ > > > > > ____________________________________________________________________________________ > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
