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 <jkschnei...@gmail.com>
> 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
>
