IVY-1143 created for this thread and linked to IVYDE-134. A rough patch is attached.
Jon On Tue, Nov 24, 2009 at 7:32 AM, Jon Schneider <jschnei...@apache.org>wrote: > > --------------------------------------------- > > > So Solr might be the easiest way of achieving an Ivy indexer. > >> Probably. As a side note, while thinking of installing a server side >> component to provide search, I started to wonder why not use a >> repository manager in that case. During devoxx I discussed with people >> from artifactory, and their latest version is now supporting Ivy (may >> still be limited, but they are working on improving that). They also >> provide a REST api for their search feature, so maybe it would be >> interesting and easy to use their software. But if we don't want to be >> dependent on their API, maybe we can try to define some sort of >> "standard" REST api to access a repository search feature. This is >> something they are ok to discuss. Then any repository manager >> implementing this api could be used. >> >> Note that compared to using artifactory, using solr still has the >> advantage of being probably usable with any kind of Ivy repo, not just >> artifactory, which has probably some limitations (because it has not >> been designed as an Ivy repo manager, I suppose it has some proxying >> and layout limitations). >> > --------------------------------------------- > > I think the Solr implementation could serve as a sort of "Reference > Implementation" that we provide. If Artifactory then also provides an > interface, all the better! Undoubtedly, it would help the folks at > Artifactory if they had a reference implementation to base their product on. > > --------------------------------------------- > >> > >> > I have to admit I am not a big fan of having to deploy a webapp next to >> a dumb simple repo. On the other hand managing an index on the client side >> depends enormously of the kind of repository (at work we have an ivy repo in >> svn accessible form both http and checkouted), it would consume more >> bandwidth, some publication locking would probably be in place, etc... >> >> I agree that having to deploy a webapp is an additional burden in the >> build ecosystem setup. But now people are used to install a CI server, >> a SCM server, and so on. So I don't think it should stop us, because I >> think dealing with that from the client side only will have some >> serious limitations. >> > --------------------------------------------- > > I think it is important to lure people in with the prospect of no > additional webapps by allowing them to read an index on a remote filesystem > directly, then allowing them to gradually come to terms with the fact that > it it is more performant to allow a server to serve up the index and add > complexity to their build ecosystem on their own timeline. > > --------------------------------------------- > > Alternatively we could define a java interface to access a search > > service (there's already one, but it is very limited), and have > > different implementations: based ona local index as initially > > suggested, using solr, artifactory, or any other. Then we are open to > > the future. > --------------------------------------------- > > I must be missing something... what java interface accesses a search > feature currently? > > --------------------------------------------- > > I think the transaction would be supported at the Lucene index level. > --------------------------------------------- > > More specifically, the transaction is already at the publish level for the > general use case since an index writer is opened for each publish and closed > at the end of the publish, effectively committing the transaction. > > On a somewhat related point, are we still considering Solr or other repo > managers for the additional duty of handling the indexing? Is there a use > case where guaranteeing indexing concurrency apart from a simple lock > strategy (block until the index lock is closed or a timeout is reached) is > important? > > Jon >
