ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Schneider <jschnei...@apache.org>
Subject Re: Ivy Indexer
Date Wed, 25 Nov 2009 18:34:50 GMT
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 <jschneider@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message