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
