lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <>
Subject Re: Facet examples javadoc missing in 4.0?
Date Sat, 24 Nov 2012 18:35:43 GMT
You're probably right. The thing is, some facet tests rely on the data that
exists in the facet examples. The reason is that the examples already
contain some large number of documents and facets, so it was easy to test
certain features (I think TotalFacetCounts) with large set of documents,
without duplicating the information.

Is it necessary, probably not, but that's the current state of affairs. I
tend to agree that facet examples should be under demo/. It's just that I'm
not willing to lose facet (core) tests, or otherwise, the facet tests would
need to depend on demo  ... is it bad?

Really, currently the facet examples build are half broken. The
facet/build.xml takes care to generate the facet-examples.jar, compile them
and test them. The only piece that was removed, from what I can tell by
accident, are the javadocs ...

You know that I always prefer to get to a consensus before opening an
issue, but I want to get this fixed. It was my mistake that I didn't notice
that when inspecting the 4.0 artifacts .. a mistake which probably
demonstrates why it would be better if it were under demo/. But it doesn't
mean that until we resolve LUCENE-3998 (if we resolve it), the examples
javadocs should be missing from the build.


On Sat, Nov 24, 2012 at 8:26 PM, Robert Muir <> wrote:

> On Sat, Nov 24, 2012 at 9:18 AM, Shai Erera <> wrote:
>> We tried that in LUCENE-3998 without success. The problem are facet tests
>> which depend on data that exists in the example package. I don't want to
>> disable tests just for the sake of separation, nor move to the examples
>> package tests that should reside in the module itself.
> I don't get this: the demo module does have tests already.
> If the demo module includes faceting examples, why wouldnt we move the
> tests there as well?
> In other words, we should have a clean separation of unit testing the code
> versus testing the examples.

View raw message