Le 11 nov. 2009 à 16:21, Jon Schneider a écrit :
> 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?
Nothing to say special apart that it sounds good :)
I am just not sure about how to declare it in the ivysettings. Maybe we could
declare them just like the caches:
<resolvers>
<filesystem name="1" index="index1">
<ivy pattern="${ivy.settings.dir}/[organisation]/[module]/ivy-[revision].xml"/>
<artifact
pattern="${ivy.settings.dir}/[organisation]/[module]/[type]/[artifact]-[revision].[ext]"/>
</filesystem>
</resolvers>
<indexes>
<index name="index1" dir="${ivy.settings.dir}/index" />
</indexes>
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
