[
https://issues.apache.org/jira/browse/LUCENE-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858889#action_12858889
]
Shai Erera commented on LUCENE-2405:
------------------------------------
Perhaps I'm missing something, but one can still write an EnwikiDocMaker which
consumes EnwikiContentSource and sets whatever properties the latter outputs?
The whole idea behind the refactoring was to allow such combinations - you
should be able to construct the documents however you want, without depending
too much on the content source. If you know a certain CS outputs some things
you want to refer to directly, write a dedicated DocMaker. Although perhaps we
can allow DocMaker itself be more properties-aware?
I've done what I did in 1595 because of exactly that purpose - I create docs on
a special way, adding all sorts of things like facets and sorting over date
etc. But I don't want to duplicate that code so that it can work on multiple
content sources ...
> Benchmark DocMaker no longer allows "off prescription" usage
> ------------------------------------------------------------
>
> Key: LUCENE-2405
> URL: https://issues.apache.org/jira/browse/LUCENE-2405
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/benchmark
> Reporter: Grant Ingersoll
>
> The EnwikiDocMaker was a pretty handy tool for indexing wikipedia for demos.
> Since LUCENE-1595, it is now much harder to create Lucene documents
> programmatically using the EnwikiContentSource and DocMaker b/c the DocMaker
> doesn't allow one to programmatically set the properties and ContentSource.
> Perhaps, we should refactor the Enwiki stuff a little bit out to the
> Wikipedia package.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
