ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: ivy 2.0 + common-vfs + webdav
Date Tue, 20 Nov 2007 06:21:36 GMT
As a follow up to this thread, looking at this other thread may also be
interesting:
http://www.nabble.com/-VFS--RE%3A--GUMP%40vmgump-%3A-Project-ivy-%28in-module-ivy%29-failed-tf3950795.html#a11221003

As you see work has already been done to identify the problem and discuss
with commons vfs team.

Maybe we should add something to our release notes and vfs resolver to make
sure people using commons-vfs and webdav can find an easier path to get it
working with Ivy 2.0.

Xavier

On Nov 16, 2007 6:10 PM, Xavier Hanin <xavier.hanin@gmail.com> wrote:

> 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 <rambiusparkisanius@yahoo.com>
> 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/




-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message