On 10/17/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: > On 10/17/07, Matthew Inger <[EMAIL PROTECTED]> wrote: > > > > Remember, things like resolvers are pluggable via the <typedef> element. > > What i'd like to see though is for the ivy engine to use more pluggable > > configuration elements, rather than forcing a <typedef>. > > > > For example, one could create a jar file with the resolver classes > > and a jar entry: > > > > META-INF/ivy-typedefs.properties > > svn=org.myorg.ivy.resolver.SvnResolver
The problem with this is that the names defined in the ivy-typedefs.properties gets placed in an undefined xml namespace - I persume into the ant xml namespace or since ivy is doing this in the ivy namespace. This issue (namepace for tasks/types) has been discussed for ant a long time ago and the choice was made to use xml namespacing. What is needed is for the automatic definitions to be picked up a little easier. At the moment there are two ways: 1) place the antlib jar in $ANT_HOME/lib or in ~/.ant/lib 2) Use typedef with the correct uri. Both of these have drawbacks. The first option ensures that one has build environment leakages - all the builds in a system has to use the exact same version of for example ant-contrib. The second option is tenious and easy to get wrong, especially in a multi-subproject build system. a patch allow the lines of http://issues.apache.org/bugzilla/show_bug.cgi?id=40522 will go some way towards making life a little easier. lib: jdepend.jar ant-contrib.jar ivy.jar ivy-resolve.jar svnkit.jar <project ... xmlns:ac="antlib:net.sf.antcontrib" xmlns:ivy="" xmlns:svnresolve="antlib:svnresolve"> <classloader> <classpath> <fileset dir="lib" includes="*.jar"/> </classpath> </classloader> <jdepend> .. </jdepend> <ac:for ... <ac:for <ivy:configure ..> <classloader> <classpath> <ivy:classpath ../> </classpath> </classloader> Peter > > > > > > and have ivy load this resource at startup time, and make all the typedefs > > available. Then, including additional resolvers and latest/conflict > > resolution > > strategies would be simply a matter of dropping in the .jar file > > containing > > the class (and of course, any supporting jar files). > > > You can open a jira issue with this suggestion Matt. I like the usage > simplicity behind such an improvement, and if we support it also for jars > provided via the ivy classpath settings, it will work in IvyDE too. > > Xavier > > ---- > > [EMAIL PROTECTED] > > "Once you start down the dark path, forever will it > > dominate your destiny. Consume you it will " - Yoda > > > > ----- Original Message ---- > > From: Adrian Woodhead <[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Tuesday, October 16, 2007 1:59:00 PM > > Subject: Re: SvnResolver anyone? > > > > > > Thanks for your reply, Xavier, comments below: > > > > Xavier Hanin wrote: > > > It could be interesting to have one more resolver but first a > > question: do > > > you use a svn client library (like SVNKit) or the svn command line, > > or > > > subversion java binding? Depending on SVNKit is incompatible with the > > > allowed licenses at the ASF for instance. > > > > > I am using the SVNKit Java library. I thought from their licensing > > description that it would be compatible with ASF as their library is > > allowed to be used as long as the project using it is open source, > > which > > Ivy is. However, would an incompatibility arise if you shipped Ivy with > > > > it, in that people using it would then have to provide the code for > > their project, which isn't a requirement of the ASF license? I'm not a > > licensing expert so I'm assuming someone on this list knows more... So > > if you say this is incompatible with ASF then I guess all discussion of > > > > me submitting patches etc. ends here? > > > > > Then there is the problem of maintenance... to maintain the code you > > need > > > commit rights, and we can't grant commit rights on the basis of only > > one > > > contribution. So you'd need to provide patches to maintain the > > code... > > > Moreover, if you finally give up on maintaining the code, we (Ivy > > team) > > > would have to maintain it. So we'd need to see how the code looks > > like, how > > > is it tested and documented. > > > > > Understood. > > > What I can recommend since you have the approval of your technical > > director > > > is to open a JIRA issue and attach a patch to our code base with your > > svn > > > resolver implementation. Please remember to check the box about > > transfering > > > rights to the ASF, so that we can apply the patch if we agree on > > that. Then > > > even if we do not include your patch, any user in the community would > > be > > > able to use it (as long as you use the ASL), so it isn't lost. > > OK, would you still want me to do this if I use SVNKit? > > > Another > > > option would be to contribute it to ivytools where there is the first > > > version of a svn resolver. The problem is that ivytools is not > > maintained > > > anymore, and thus I doubt it would gain much momentum over there. > > > > > True. I could try contact the people behind ivytools and see if there > > is > > anyone there willing to get it going again for Ivy 2.0. Another option > > I > > guess would be releasing it somewhere else separately..... > > > > Adrian > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > Pinpoint customers who are looking for what you sell. > > http://searchmarketing.yahoo.com/ > > > > > > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ >
