ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: auto download of antlibs
Date Mon, 07 May 2007 14:04:20 GMT
On 5/7/07, Steve Loughran <stevel@apache.org> wrote:
> Xavier Hanin wrote:
> > On 5/4/07, Jan.Materne@rzf.fin-nrw.de <Jan.Materne@rzf.fin-nrw.de> wrote:
> >> >> > we'd need a metadata tree mapping antlibs to well known packages,
> >> >> > but that is not too hard. JSON, perhaps.
> >> >>
> >> >> Not sure.  Who'd maintain it?
> >> >
> >> >It should be some xml format.
> >> >I think that it should be on the ant site
> >> >and ant committers would be the updaters of it.
> >> >- this would be similar to the
> >> >related projects page - http://ant.apache.org/projects.html
> >> >but have a separate url for each antlib.
> >> >? somthing like: http://ant.apache.org/antlibdefintions/<package>.xml
> >> >for example:
> >> >http://ant.apache.org/antlibdefintions/net.sf.antcontrib.xml
> >> >
> >> >of course this raises the issues of version. One may not want
> >> >the lastest
> >> >version of a particular antlib.
> >>
> >>
> >> There is a solution for versioning issues ... or doesnt solve a
> >> Maven-repo
> >> versioning of multiple formats?
> > mm, the problem is not to store multiple versions on the repo, but to
> > know which one to pick from the antlib URI. As far as I understand
> > Steve proposal, the idea would be to introduce automatic download
> > based on the current format of antlib declaration, which only contains
> > a package, and no version information.
> >
>
> You'd have to include a version. One thing you could do is
> lib:xmlns="antlib://org/example/something#2.13" ...but that would place
> the version into the namespace, which is too early to read in/expand ant
> properties, and you'd have to update the xmlns declaration everywhere
> you used it...that's a no-no in a big project.
Indeed, good point.

>
> there's also the issue of setting up your ivy conf before the build. Now
> unless we want to be maven-style and look for properties in undocumented
> propertlies like ant.antlib.org.example.something.version and secretly
> extract the version info from there, we need an explicit declaration of
> versions. Also there's the security issue.
Good point too.

>
> I've been thinking more what we could do with tasks rather than fully
> automated download.
>
> As a first pass, you could combine an ivy download with a typedef,
> hooking in to a named ivy conf:
>
> <antlib uri="org.example.something" conf="example" />
And wher is the version information? And how do we map this package
name to an organization/module name couple? What do you think of
providing all information:
<antlib uri="org.example.something"
     org="org.example"
     module="example"
     rev="1.3"
     conf="example" />
>
> The trick here would be to make it a no-op if there was already an
> antlib defined into the namespace.
Yes, would be a nice trick.

>
> [speaking of which, is there a way of enumerating all currently
> declaraed antlibs?]
>
>
>
> I'm also thinking of an <ivy:ivypath> resource that let's you declare a
> path inline
>
>   <ivy:ivypath conf="example">
Is it a resource or a resource collection? I'm not familiar with the
Resource API yet...
Moreover, where do the module information (org/module/rev) come from?
Shouldn't we provide them? As a side note, it's very similar to the
current ivy:cachepath task. The main difference is that ivy:cachepath
is a task, not a resource. But to be a resource I think we'd need some
kind of lifecycle management for resources.

Xavier
>
> -steve
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message