ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Scokart <>
Subject Re: Ivy Indexer
Date Fri, 13 Nov 2009 09:24:56 GMT
Seems nice.  But I'm not sure I understand what it will be used for.
What would be the user interface to read the index ?

Gilles Scokart

2009/11/11 Jon Schneider <>

> I've been thinking about IVYDE-134 (Quick Search feature for dependencies
> in
> repositories) and related IVY-866. If we add support for the Nexus Indexer
> (which would be nice in its own right), we would still be lacking this
> feature for Ivy repositories. Also, what about ivysettings whose default
> resolver is a chain resolver of a Maven repository and an Ivy repository?
> In
> this case, without some all-encompassing index, the quick search feature
> would find Java types in only the Maven repository within the chain
> resolver, which I think would be counterintuitive to a user.
> My first thought was to build an extension to Nexus or Archiva for Ivy, but
> somehow I just really dislike the idea of making an otherwise stateless
> repository stateful (or should I say, having a manager, however thin,
> continuously running to proxy modifications to the repository). Also, these
> two products are so Maven-centric (due to their intended use) that any
> extension would amount to an abuse of their intended use.
> So my compromising proposal is centered around a Lucene index that should
> be
> modified (1) whenever a deliver/publish/install task is ran. Also, since
> nothing stops a repository administrator from manually
> deleting/adding/updating files in the repository, we should provide (2) a
> new <ivy:index> task.
> (1) is accomplished through a new resolver type extending from
> ChainResolver
> that proxies publishing to its delegate resolvers, indexing the published
> artifacts in the process. As an example, adding this proxy would look like
> this in ivysettings.xml:
> <resolvers>
> <indexed name="indexable" index="${ivy.settings.dir}/index">
> <filesystem name="1">
> <ivy
> pattern="${ivy.settings.dir}/[organisation]/[module]/ivy-[revision].xml"/>
> <artifact
> pattern="${ivy.settings.dir}/[organisation]/[module]/[type]/[artifact]-[revision].[ext]"/>
> </filesystem>
> <!-- other resolvers here... -->
> </indexed>
> </resolvers>
> (2) allows a repository administrator to force clean the index via an Ant
> task when it is known to be stale. It also provides an alternative to using
> the proxy mechanism described in (1); the index task could be run
> periodically (e.g. nightly) as a task on a continuous integration tool.
> The index task itself explores the repository, opening jars and listing the
> fully qualified types found in each jar in the index and associating these
> types with a particular ModuleRevisionId. With the code I have written so
> far, I have been able to index up to 10,000 jars in less than 10 seconds
> when the index task is running against a repository on the same machine
> (indexing a repository through a network path slows down considerably).
> IvyDE can then search for types against the optimized Lucene index, making
> it very fast.
> Thoughts on this approach?
> Jon

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message