Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
  b=oID/DGZ9uIFy3PBy45RktXtsHv6/Nm3lSIewV/CnKREb22t6c5H6o01hW8j3eGV5RavHrNdZe3WfzgA5USWICtkbOsi/2luX99DS6zEYJWM0Ev3QjQkl1ZLlHqrL6BnjC7oxrQmqUz41f1uLswOc/dNF5/f9yFc25uAyCR00/TQ=;
Date: Thu, 15 Nov 2007 09:58:34 -0800 (PST)
From: "Ivan \"Rambius\" Ivanov" <rambiusparkisanius@yahoo.com>
Subject: ivy 2.0 + common-vfs + webdav
To: ivy-user@incubator.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <490630.98277.qm@web52910.mail.re2.yahoo.com>

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