The typedef Matthew is talking about are actually type defined in the ivy settings, not a ant task/datatype. It is mostly used to define new resolvers, possible new conflict resolver or other type of object that you can use to configure your ivy engine
That's true that we might have a similar issues than ant if we start to have plenty of ivy plugins. But I think we are far from it. So I don't usage of namespaces are required for the moment. What I'm wondering is how you can read from java the different ressources all named META-INF/ivy-typedefs.properties, and how will you define the classpath in which to search. Gilles 2007/10/17, Peter Reilly <[EMAIL PROTECTED]>: > > 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/ > > > -- Gilles SCOKART
