> --------------------------------------------- > 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
