On Friday 13 November 2009 10:24:56 Gilles Scokart wrote:
> 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 ?
The use case is pretty simple: I work on a project with no dependency. Then I
know that there some cool stuff in commons-io, I want to use FileUtils for
instance. More than trying to find the exact organisation+module name
(commons-io/commons-io or apache/commons-io or org.apache.commons/commons-io
or org.apache.commons/io, etc....), I would open a search windows where I
put "FilesUtils" in a search field, and it would find the proper organisation
and module names. Then there would be a "add dependency" button which will
add it to the ivy.xml of the project.
Nicolas
>
>
> 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]-[r
> >evision].[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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
