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).
----
[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/
