You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-dev@incubator.apache.org by Gilles Scokart <gs...@gmail.com> on 2007/10/17 10:09:25 UTC
Ivy extensions and typedef [Was Re: SvnResolver anyone?]
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 <pe...@gmail.com>:
>
> On 10/17/07, Xavier Hanin <xa...@gmail.com> wrote:
> > On 10/17/07, Matthew Inger <ma...@yahoo.com> 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
> >
> > ----
> > > mattinger@yahoo.com
> > > "Once you start down the dark path, forever will it
> > > dominate your destiny. Consume you it will " - Yoda
> > >
> > > ----- Original Message ----
> > > From: Adrian Woodhead <ad...@last.fm>
> > > To: ivy-dev@incubator.apache.org
> > > 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