Re: Build failed in Hudson: Lucene-trunk #902

2009-07-30 Thread Michael McCandless
On Thu, Jul 30, 2009 at 6:14 AM, Uwe Schindler wrote:

> I for got to mention:  only works for clover 2.x this is why I
> updated. The update was simple, I only had to change one line in
> common-build.xml and add the testsources tag with the current
> junit.include/exclude and ASCIIFoldingFilter exclusions.

Great.

> Addition of test-tag is more complicated, as the source directory names are
> not so simple to find and are not available at the time of setup-clover
> task.
>
> I will post a patch after the complete ant test has run here in complete
> (will take some time).

OK.

>> Can't we see coverage of core code, by both the current unit tests and
>> the back-compat unit tests?
>
> We would see, my intention is to only instrument the coe/contrib tests to
> find out places were the test does not cover all code, but a previous test
> from test-tag had done.

I see; that would be an interesting report.

> In ideal world all test of current trunk should test
> all code without the help of test-tag.

I'm not sure that's the ideal we should aim for.

EG, if we make some API change on trunk, marking the old API
deprecated, shouldn't we at that point move the existing tests over to
the new API, and then "rely" on the back-compat tests to invoke
("cover", as reported by Clover) the deprecated API?

Or, should we always leave some trunk tests using the deprecated APIs?

Mike

-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org



RE: Build failed in Hudson: Lucene-trunk #902

2009-07-30 Thread Uwe Schindler
> >> > I found out that clover-setup supports a special advanced tag
> >> > "":
> >> >  is an Ant fileset which should only be used if Clover's
> >> > default test detection is not adequate. Clover's default test
> detection
> >> > algorithm is used to distinguish test cases if this element is
> omitted.
> >>
> >> That sounds promising!
> >>
> >> Atlassian actually proactively contacted me about this build failure
> >> (how responsive is that!), offering to look into this "zero bytes
> >> source file issue", upgrade Apache's license to clover 2.0 and work
> >> out a patch for Lucene to switch to 2.0.  I'll open an issue once they
> >> send the patch over.
> >
> > I switched over to clover 2.4.3 here locally, changed common-build.xml
> and
> > now it seems to work.
> 
> Excellent.

I for got to mention:  only works for clover 2.x this is why I
updated. The update was simple, I only had to change one line in
common-build.xml and add the testsources tag with the current
junit.include/exclude and ASCIIFoldingFilter exclusions.

Addition of test-tag is more complicated, as the source directory names are
not so simple to find and are not available at the time of setup-clover
task.

I will post a patch after the complete ant test has run here in complete
(will take some time).

> >> > And it seems that clover uses the backwards tests and nothing else. I
> >> > install clover locally and try out. I will then open an issue.
> >>
> >> We should definitely fix that.  I think it's best to instrument both
> >> the trunk's tests and the back-compat tests if we can.
> >
> > Currently I only instument the contrib and core tests. If we also
> instrument
> > backwards tests, we may have code not instrumented by current tests,
> only
> > the backwards tests. In my opinion, you should see the coverage of
> current
> > tests to be sure, that current test cover all code.
> 
> Can't we see coverage of core code, by both the current unit tests and
> the back-compat unit tests?

We would see, my intention is to only instrument the coe/contrib tests to
find out places were the test does not cover all code, but a previous test
from test-tag had done. In ideal world all test of current trunk should test
all code without the help of test-tag.

Uwe


-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org



Re: Build failed in Hudson: Lucene-trunk #902

2009-07-30 Thread Michael McCandless
On Thu, Jul 30, 2009 at 5:53 AM, Uwe Schindler wrote:
>> > I found out that clover-setup supports a special advanced tag
>> > "":
>> >  is an Ant fileset which should only be used if Clover's
>> > default test detection is not adequate. Clover's default test detection
>> > algorithm is used to distinguish test cases if this element is omitted.
>>
>> That sounds promising!
>>
>> Atlassian actually proactively contacted me about this build failure
>> (how responsive is that!), offering to look into this "zero bytes
>> source file issue", upgrade Apache's license to clover 2.0 and work
>> out a patch for Lucene to switch to 2.0.  I'll open an issue once they
>> send the patch over.
>
> I switched over to clover 2.4.3 here locally, changed common-build.xml and
> now it seems to work.

Excellent.

>> > And it seems that clover uses the backwards tests and nothing else. I
>> > install clover locally and try out. I will then open an issue.
>>
>> We should definitely fix that.  I think it's best to instrument both
>> the trunk's tests and the back-compat tests if we can.
>
> Currently I only instument the contrib and core tests. If we also instrument
> backwards tests, we may have code not instrumented by current tests, only
> the backwards tests. In my opinion, you should see the coverage of current
> tests to be sure, that current test cover all code.

Can't we see coverage of core code, by both the current unit tests and
the back-compat unit tests?

Mike

-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org



RE: Build failed in Hudson: Lucene-trunk #902

2009-07-30 Thread Uwe Schindler
> > I found out that clover-setup supports a special advanced tag
> > "":
> >  is an Ant fileset which should only be used if Clover's
> > default test detection is not adequate. Clover's default test detection
> > algorithm is used to distinguish test cases if this element is omitted.
> 
> That sounds promising!
> 
> Atlassian actually proactively contacted me about this build failure
> (how responsive is that!), offering to look into this "zero bytes
> source file issue", upgrade Apache's license to clover 2.0 and work
> out a patch for Lucene to switch to 2.0.  I'll open an issue once they
> send the patch over.

I switched over to clover 2.4.3 here locally, changed common-build.xml and
now it seems to work.

> > And it seems that clover uses the backwards tests and nothing else. I
> > install clover locally and try out. I will then open an issue.
> 
> We should definitely fix that.  I think it's best to instrument both
> the trunk's tests and the back-compat tests if we can.

Currently I only instument the contrib and core tests. If we also instrument
backwards tests, we may have code not instrumented by current tests, only
the backwards tests. In my opinion, you should see the coverage of current
tests to be sure, that current test cover all code.

Uwe


-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org



Re: Build failed in Hudson: Lucene-trunk #902

2009-07-30 Thread Michael McCandless
On Thu, Jul 30, 2009 at 4:51 AM, Uwe Schindler wrote:
>> I'm guessing it was the empty source file I accidentally left in for
>> LUCENE-1754, that Hoss removed (thanks!). I think clover saw that as
>> an attempt to instrument a source in the empty-string package.
>>
>> I'm unfamiliar w/ how to configure clover, but I agree we should make
>> sure it's testing coverage for our "normal" unit tests.  Rather than
>> turn it off for test-tag, can we measure coverage of all tests
>> (test-tag, test-core, test-contrib)?
>>
>> Is there someone familiar w/ clover who can look into this?
>
> I found out that clover-setup supports a special advanced tag
> "":
>  is an Ant fileset which should only be used if Clover's
> default test detection is not adequate. Clover's default test detection
> algorithm is used to distinguish test cases if this element is omitted.

That sounds promising!

Atlassian actually proactively contacted me about this build failure
(how responsive is that!), offering to look into this "zero bytes
source file issue", upgrade Apache's license to clover 2.0 and work
out a patch for Lucene to switch to 2.0.  I'll open an issue once they
send the patch over.

> And it seems that clover uses the backwards tests and nothing else. I
> install clover locally and try out. I will then open an issue.

We should definitely fix that.  I think it's best to instrument both
the trunk's tests and the back-compat tests if we can.

Mike

-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org



RE: Build failed in Hudson: Lucene-trunk #902

2009-07-30 Thread Uwe Schindler
> I'm guessing it was the empty source file I accidentally left in for
> LUCENE-1754, that Hoss removed (thanks!). I think clover saw that as
> an attempt to instrument a source in the empty-string package.
> 
> I'm unfamiliar w/ how to configure clover, but I agree we should make
> sure it's testing coverage for our "normal" unit tests.  Rather than
> turn it off for test-tag, can we measure coverage of all tests
> (test-tag, test-core, test-contrib)?
> 
> Is there someone familiar w/ clover who can look into this?

I found out that clover-setup supports a special advanced tag
"":
 is an Ant fileset which should only be used if Clover's
default test detection is not adequate. Clover's default test detection
algorithm is used to distinguish test cases if this element is omitted.

And it seems that clover uses the backwards tests and nothing else. I
install clover locally and try out. I will then open an issue.

Uwe


> On Wed, Jul 29, 2009 at 3:10 AM, Uwe Schindler wrote:
> > This seems to be fixed now. But there is something completely wrong with
> > clover:
> >
> > If you look into the clover reports, there are a lot of classes having
> 0%
> > code coverage, but there are tests available (e.g. my new NumericRange
> > things). Also *all* contribs have 0%.
> >
> > After thinking a little bit about it, it seems, that the cloverage
> report is
> > build not from the normal test-run, but it is generated from the results
> of
> > the test-tag. This explains, why NumericRange and Spatial seem to have
> no
> > tests for clover.
> >
> > Does anybody know, how to fix this. Maybe the cloverage should be
> disabled
> > for the test run in test-tag? What can be changed in build.xml to do
> this?
> >
> > I have no clover installed locally, so I cannot try this out.
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >> -Original Message-
> >> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> >> Sent: Tuesday, July 28, 2009 12:13 PM
> >> To: java-dev@lucene.apache.org
> >> Subject: Re: Build failed in Hudson: Lucene-trunk #902
> >>
> >> Hmm... the build looks like it failed because of some odd clover
> >> licensing issue:
> >>
> >>    [clover] Sorry, you are not licensed to instrument files in the
> package
> >> ''.
> >>
> >> Anyone have any ideas?
> >>
> >> Mike
> >>
> >> On Mon, Jul 27, 2009 at 11:26 PM, Apache Hudson
> >> Server wrote:
> >> > See http://hudson.zones.apache.org/hudson/job/Lucene-
> trunk/902/changes
> >> >
> >> > Changes:
> >> >
> >> > [uschindler] LUCENE-1754: JavaDoc updates
> >> >
> >> > [mikemccand] LUCENE-1754: EMPTY_DOCIDSET subclasses DocIdSet directly
> >> >
> >> > [mikemccand] LUCENE-1754: just use EMPTY_DOCIDSET.iterator() instead
> of
> >> new EmptyDocIdSetIterator
> >> >
> >> > [mikemccand] LUCENE-1595: don't use SortField.AUTO; deprecate
> >> LineDocMaker & EnwikiDocMaker
> >> >
> >> > [mikemccand] LUCENE-1754: add EmptyDocIdSetIterator
> >> >
> >> > [mikemccand] LUCENE-1754: update back-compat test
> >> >
> >> > [mikemccand] LUCENE-1754: BooleanQuery detects up front if it won't
> >> match any docs and returns null from its scorer() instead of
> >> NonMatchingScorer
> >> >
> >> > --
> >> > [...truncated 21062 lines...]
> >> >  [javadoc] Note: Custom tags that were not seen: �...@todo,
> @uml.property
> >> >  [javadoc] 1 error
> >> >  [javadoc] 32 warnings
> >> >      [jar] Building jar:
> >> http://hudson.zones.apache.org/hudson/job/Lucene-
> >> trunk/ws/trunk/build/contrib/spatial/lucene-spatial-2009-07-28_02-04-
> 46-
> >> javadoc.jar
> >> >     [echo] Building spellchecker...
> >> >
> >> > javadocs:
> >> >  [javadoc] Generating Javadoc
> >> >  [javadoc] Javadoc execution
> >> >  [javadoc] Loading source files for package
> >> org.apache.lucene.search.spell...
> >> >  [javadoc] Constructing Javadoc information...
> >> >  [javadoc] javadoc: warning - Error reading file:
> >> http://hudson.zones.apache.org/hudson/job/Lucene-
> >> trunk/ws/trunk/build/doc

Re: Build failed in Hudson: Lucene-trunk #902

2009-07-29 Thread Michael McCandless
I'm guessing it was the empty source file I accidentally left in for
LUCENE-1754, that Hoss removed (thanks!). I think clover saw that as
an attempt to instrument a source in the empty-string package.

I'm unfamiliar w/ how to configure clover, but I agree we should make
sure it's testing coverage for our "normal" unit tests.  Rather than
turn it off for test-tag, can we measure coverage of all tests
(test-tag, test-core, test-contrib)?

Is there someone familiar w/ clover who can look into this?

Mike

On Wed, Jul 29, 2009 at 3:10 AM, Uwe Schindler wrote:
> This seems to be fixed now. But there is something completely wrong with
> clover:
>
> If you look into the clover reports, there are a lot of classes having 0%
> code coverage, but there are tests available (e.g. my new NumericRange
> things). Also *all* contribs have 0%.
>
> After thinking a little bit about it, it seems, that the cloverage report is
> build not from the normal test-run, but it is generated from the results of
> the test-tag. This explains, why NumericRange and Spatial seem to have no
> tests for clover.
>
> Does anybody know, how to fix this. Maybe the cloverage should be disabled
> for the test run in test-tag? What can be changed in build.xml to do this?
>
> I have no clover installed locally, so I cannot try this out.
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>> -Original Message-
>> From: Michael McCandless [mailto:luc...@mikemccandless.com]
>> Sent: Tuesday, July 28, 2009 12:13 PM
>> To: java-dev@lucene.apache.org
>> Subject: Re: Build failed in Hudson: Lucene-trunk #902
>>
>> Hmm... the build looks like it failed because of some odd clover
>> licensing issue:
>>
>>    [clover] Sorry, you are not licensed to instrument files in the package
>> ''.
>>
>> Anyone have any ideas?
>>
>> Mike
>>
>> On Mon, Jul 27, 2009 at 11:26 PM, Apache Hudson
>> Server wrote:
>> > See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/902/changes
>> >
>> > Changes:
>> >
>> > [uschindler] LUCENE-1754: JavaDoc updates
>> >
>> > [mikemccand] LUCENE-1754: EMPTY_DOCIDSET subclasses DocIdSet directly
>> >
>> > [mikemccand] LUCENE-1754: just use EMPTY_DOCIDSET.iterator() instead of
>> new EmptyDocIdSetIterator
>> >
>> > [mikemccand] LUCENE-1595: don't use SortField.AUTO; deprecate
>> LineDocMaker & EnwikiDocMaker
>> >
>> > [mikemccand] LUCENE-1754: add EmptyDocIdSetIterator
>> >
>> > [mikemccand] LUCENE-1754: update back-compat test
>> >
>> > [mikemccand] LUCENE-1754: BooleanQuery detects up front if it won't
>> match any docs and returns null from its scorer() instead of
>> NonMatchingScorer
>> >
>> > --
>> > [...truncated 21062 lines...]
>> >  [javadoc] Note: Custom tags that were not seen: �...@todo, @uml.property
>> >  [javadoc] 1 error
>> >  [javadoc] 32 warnings
>> >      [jar] Building jar:
>> http://hudson.zones.apache.org/hudson/job/Lucene-
>> trunk/ws/trunk/build/contrib/spatial/lucene-spatial-2009-07-28_02-04-46-
>> javadoc.jar
>> >     [echo] Building spellchecker...
>> >
>> > javadocs:
>> >  [javadoc] Generating Javadoc
>> >  [javadoc] Javadoc execution
>> >  [javadoc] Loading source files for package
>> org.apache.lucene.search.spell...
>> >  [javadoc] Constructing Javadoc information...
>> >  [javadoc] javadoc: warning - Error reading file:
>> http://hudson.zones.apache.org/hudson/job/Lucene-
>> trunk/ws/trunk/build/docs/api/contrib-spellchecker/../package-list
>> >  [javadoc] Standard Doclet version 1.5.0_14
>> >  [javadoc] Building tree for all the packages and classes...
>> >  [javadoc] Building index for all the packages and classes...
>> >  [javadoc] Building index for all classes...
>> >  [javadoc] javadoc: error - Error while reading file
>> http://hudson.zones.apache.org/hudson/job/Lucene-
>> trunk/ws/trunk/contrib/spellchecker/src/java/overview.html
>> >  [javadoc] Generating http://hudson.zones.apache.org/hudson/job/Lucene-
>> trunk/ws/trunk/build/docs/api/contrib-spellchecker/stylesheet.css...
>> >  [javadoc] Note: Custom tags that could override future standard tags:
>> �...@todo. To avoid potential overrides, use at least one period character
>> (.) in custom tag names.
>> >  [javadoc] Note: Custom tags that were not seen: �...@todo, @uml

RE: Build failed in Hudson: Lucene-trunk #902

2009-07-29 Thread Uwe Schindler
This seems to be fixed now. But there is something completely wrong with
clover:

If you look into the clover reports, there are a lot of classes having 0%
code coverage, but there are tests available (e.g. my new NumericRange
things). Also *all* contribs have 0%.

After thinking a little bit about it, it seems, that the cloverage report is
build not from the normal test-run, but it is generated from the results of
the test-tag. This explains, why NumericRange and Spatial seem to have no
tests for clover.

Does anybody know, how to fix this. Maybe the cloverage should be disabled
for the test run in test-tag? What can be changed in build.xml to do this?

I have no clover installed locally, so I cannot try this out.

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Tuesday, July 28, 2009 12:13 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Build failed in Hudson: Lucene-trunk #902
> 
> Hmm... the build looks like it failed because of some odd clover
> licensing issue:
> 
>[clover] Sorry, you are not licensed to instrument files in the package
> ''.
> 
> Anyone have any ideas?
> 
> Mike
> 
> On Mon, Jul 27, 2009 at 11:26 PM, Apache Hudson
> Server wrote:
> > See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/902/changes
> >
> > Changes:
> >
> > [uschindler] LUCENE-1754: JavaDoc updates
> >
> > [mikemccand] LUCENE-1754: EMPTY_DOCIDSET subclasses DocIdSet directly
> >
> > [mikemccand] LUCENE-1754: just use EMPTY_DOCIDSET.iterator() instead of
> new EmptyDocIdSetIterator
> >
> > [mikemccand] LUCENE-1595: don't use SortField.AUTO; deprecate
> LineDocMaker & EnwikiDocMaker
> >
> > [mikemccand] LUCENE-1754: add EmptyDocIdSetIterator
> >
> > [mikemccand] LUCENE-1754: update back-compat test
> >
> > [mikemccand] LUCENE-1754: BooleanQuery detects up front if it won't
> match any docs and returns null from its scorer() instead of
> NonMatchingScorer
> >
> > --
> > [...truncated 21062 lines...]
> >  [javadoc] Note: Custom tags that were not seen: �...@todo, @uml.property
> >  [javadoc] 1 error
> >  [javadoc] 32 warnings
> >      [jar] Building jar:
> http://hudson.zones.apache.org/hudson/job/Lucene-
> trunk/ws/trunk/build/contrib/spatial/lucene-spatial-2009-07-28_02-04-46-
> javadoc.jar
> >     [echo] Building spellchecker...
> >
> > javadocs:
> >  [javadoc] Generating Javadoc
> >  [javadoc] Javadoc execution
> >  [javadoc] Loading source files for package
> org.apache.lucene.search.spell...
> >  [javadoc] Constructing Javadoc information...
> >  [javadoc] javadoc: warning - Error reading file:
> http://hudson.zones.apache.org/hudson/job/Lucene-
> trunk/ws/trunk/build/docs/api/contrib-spellchecker/../package-list
> >  [javadoc] Standard Doclet version 1.5.0_14
> >  [javadoc] Building tree for all the packages and classes...
> >  [javadoc] Building index for all the packages and classes...
> >  [javadoc] Building index for all classes...
> >  [javadoc] javadoc: error - Error while reading file
> http://hudson.zones.apache.org/hudson/job/Lucene-
> trunk/ws/trunk/contrib/spellchecker/src/java/overview.html
> >  [javadoc] Generating http://hudson.zones.apache.org/hudson/job/Lucene-
> trunk/ws/trunk/build/docs/api/contrib-spellchecker/stylesheet.css...
> >  [javadoc] Note: Custom tags that could override future standard tags:
> �...@todo. To avoid potential overrides, use at least one period character
> (.) in custom tag names.
> >  [javadoc] Note: Custom tags that were not seen: �...@todo, @uml.property
> >  [javadoc] 1 error
> >  [javadoc] 1 warning
> >      [jar] Building jar:
> http://hudson.zones.apache.org/hudson/job/Lucene-
> trunk/ws/trunk/build/contrib/spellchecker/lucene-spellchecker-2009-07-
> 28_02-04-46-javadoc.jar
> >     [echo] Building surround...
> >
> > javadocs:
> >  [javadoc] Generating Javadoc
> >  [javadoc] Javadoc execution
> >  [javadoc] Loading source files for package
> org.apache.lucene.queryParser.surround.parser...
> >  [javadoc] Loading source files for package
> org.apache.lucene.queryParser.surround.query...
> >  [javadoc] Constructing Javadoc information...
> >  [javadoc] javadoc: warning - Error reading file:
> http://hudson.zones.apache.org/hudson/job/Lucene-
> trunk/ws/trunk/build/docs/api/contrib-surround/../package-list
> >  [javadoc] Standard Doclet version 1.5.0_14
> >  [javadoc] Building tree for all the packages and

Re: Build failed in Hudson: Lucene-trunk #902

2009-07-28 Thread Michael McCandless
Hmm... the build looks like it failed because of some odd clover
licensing issue:

   [clover] Sorry, you are not licensed to instrument files in the package ''.

Anyone have any ideas?

Mike

On Mon, Jul 27, 2009 at 11:26 PM, Apache Hudson
Server wrote:
> See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/902/changes
>
> Changes:
>
> [uschindler] LUCENE-1754: JavaDoc updates
>
> [mikemccand] LUCENE-1754: EMPTY_DOCIDSET subclasses DocIdSet directly
>
> [mikemccand] LUCENE-1754: just use EMPTY_DOCIDSET.iterator() instead of new 
> EmptyDocIdSetIterator
>
> [mikemccand] LUCENE-1595: don't use SortField.AUTO; deprecate LineDocMaker & 
> EnwikiDocMaker
>
> [mikemccand] LUCENE-1754: add EmptyDocIdSetIterator
>
> [mikemccand] LUCENE-1754: update back-compat test
>
> [mikemccand] LUCENE-1754: BooleanQuery detects up front if it won't match any 
> docs and returns null from its scorer() instead of NonMatchingScorer
>
> --
> [...truncated 21062 lines...]
>  [javadoc] Note: Custom tags that were not seen: �...@todo, @uml.property
>  [javadoc] 1 error
>  [javadoc] 32 warnings
>      [jar] Building jar: 
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/contrib/spatial/lucene-spatial-2009-07-28_02-04-46-javadoc.jar
>     [echo] Building spellchecker...
>
> javadocs:
>  [javadoc] Generating Javadoc
>  [javadoc] Javadoc execution
>  [javadoc] Loading source files for package org.apache.lucene.search.spell...
>  [javadoc] Constructing Javadoc information...
>  [javadoc] javadoc: warning - Error reading file: 
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-spellchecker/../package-list
>  [javadoc] Standard Doclet version 1.5.0_14
>  [javadoc] Building tree for all the packages and classes...
>  [javadoc] Building index for all the packages and classes...
>  [javadoc] Building index for all classes...
>  [javadoc] javadoc: error - Error while reading file 
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/contrib/spellchecker/src/java/overview.html
>  [javadoc] Generating 
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-spellchecker/stylesheet.css...
>  [javadoc] Note: Custom tags that could override future standard tags: 
> �...@todo. To avoid potential overrides, use at least one period character 
> (.) in custom tag names.
>  [javadoc] Note: Custom tags that were not seen: �...@todo, @uml.property
>  [javadoc] 1 error
>  [javadoc] 1 warning
>      [jar] Building jar: 
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/contrib/spellchecker/lucene-spellchecker-2009-07-28_02-04-46-javadoc.jar
>     [echo] Building surround...
>
> javadocs:
>  [javadoc] Generating Javadoc
>  [javadoc] Javadoc execution
>  [javadoc] Loading source files for package 
> org.apache.lucene.queryParser.surround.parser...
>  [javadoc] Loading source files for package 
> org.apache.lucene.queryParser.surround.query...
>  [javadoc] Constructing Javadoc information...
>  [javadoc] javadoc: warning - Error reading file: 
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-surround/../package-list
>  [javadoc] Standard Doclet version 1.5.0_14
>  [javadoc] Building tree for all the packages and classes...
>  [javadoc] Building index for all the packages and classes...
>  [javadoc] Building index for all classes...
>  [javadoc] javadoc: error - Error while reading file 
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/contrib/surround/src/java/overview.html
>  [javadoc] Generating 
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-surround/stylesheet.css...
>  [javadoc] Note: Custom tags that could override future standard tags: 
> �...@todo. To avoid potential overrides, use at least one period character 
> (.) in custom tag names.
>  [javadoc] Note: Custom tags that were not seen: �...@todo, @uml.property
>  [javadoc] 1 error
>  [javadoc] 1 warning
>      [jar] Building jar: 
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/contrib/surround/lucene-surround-2009-07-28_02-04-46-javadoc.jar
>     [echo] Building swing...
>
> javadocs:
>  [javadoc] Generating Javadoc
>  [javadoc] Javadoc execution
>  [javadoc] Loading source files for package org.apache.lucene.swing.models...
>  [javadoc] Constructing Javadoc information...
>  [javadoc] javadoc: warning - Error reading file: 
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-swing/../package-list
>  [javadoc] Standard Doclet version 1.5.0_14
>  [javadoc] Building tree for all the packages and classes...
>  [javadoc] Building index for all the packages and classes...
>  [javadoc] Building index for all classes...
>  [javadoc] Generating 
> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-swing/stylesheet.css...
>  [javadoc] Note: C

Build failed in Hudson: Lucene-trunk #902

2009-07-27 Thread Apache Hudson Server
See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/902/changes

Changes:

[uschindler] LUCENE-1754: JavaDoc updates

[mikemccand] LUCENE-1754: EMPTY_DOCIDSET subclasses DocIdSet directly

[mikemccand] LUCENE-1754: just use EMPTY_DOCIDSET.iterator() instead of new 
EmptyDocIdSetIterator

[mikemccand] LUCENE-1595: don't use SortField.AUTO; deprecate LineDocMaker & 
EnwikiDocMaker

[mikemccand] LUCENE-1754: add EmptyDocIdSetIterator

[mikemccand] LUCENE-1754: update back-compat test

[mikemccand] LUCENE-1754: BooleanQuery detects up front if it won't match any 
docs and returns null from its scorer() instead of NonMatchingScorer

--
[...truncated 21062 lines...]
  [javadoc] Note: Custom tags that were not seen:  @todo, @uml.property
  [javadoc] 1 error
  [javadoc] 32 warnings
  [jar] Building jar: 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/contrib/spatial/lucene-spatial-2009-07-28_02-04-46-javadoc.jar
 
 [echo] Building spellchecker...

javadocs:
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.search.spell...
  [javadoc] Constructing Javadoc information...
  [javadoc] javadoc: warning - Error reading file: 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-spellchecker/../package-list
 
  [javadoc] Standard Doclet version 1.5.0_14
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] javadoc: error - Error while reading file 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/contrib/spellchecker/src/java/overview.html
 
  [javadoc] Generating 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-spellchecker/stylesheet.css...
 
  [javadoc] Note: Custom tags that could override future standard tags:  @todo. 
To avoid potential overrides, use at least one period character (.) in custom 
tag names.
  [javadoc] Note: Custom tags that were not seen:  @todo, @uml.property
  [javadoc] 1 error
  [javadoc] 1 warning
  [jar] Building jar: 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/contrib/spellchecker/lucene-spellchecker-2009-07-28_02-04-46-javadoc.jar
 
 [echo] Building surround...

javadocs:
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package 
org.apache.lucene.queryParser.surround.parser...
  [javadoc] Loading source files for package 
org.apache.lucene.queryParser.surround.query...
  [javadoc] Constructing Javadoc information...
  [javadoc] javadoc: warning - Error reading file: 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-surround/../package-list
 
  [javadoc] Standard Doclet version 1.5.0_14
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] javadoc: error - Error while reading file 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/contrib/surround/src/java/overview.html
 
  [javadoc] Generating 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-surround/stylesheet.css...
 
  [javadoc] Note: Custom tags that could override future standard tags:  @todo. 
To avoid potential overrides, use at least one period character (.) in custom 
tag names.
  [javadoc] Note: Custom tags that were not seen:  @todo, @uml.property
  [javadoc] 1 error
  [javadoc] 1 warning
  [jar] Building jar: 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/contrib/surround/lucene-surround-2009-07-28_02-04-46-javadoc.jar
 
 [echo] Building swing...

javadocs:
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.swing.models...
  [javadoc] Constructing Javadoc information...
  [javadoc] javadoc: warning - Error reading file: 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-swing/../package-list
 
  [javadoc] Standard Doclet version 1.5.0_14
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/api/contrib-swing/stylesheet.css...
 
  [javadoc] Note: Custom tags that could override future standard tags:  @todo. 
To avoid potential overrides, use at least one period character (.) in custom 
tag names.
  [javadoc] Note: Custom tags that were not seen:  @todo, @uml.property
  [javadoc] 1 warning
  [jar] Building jar: 
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/contrib/swing/lucene-swing-2009-07-2