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 > > > 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/
