I don't really get what is going on here, apart from that Clover is failing
due to this test.  The file it is looking for seems crazy, is that expected?

Having looked at the test, I haven't come across the @ParametersFactory
annotation before but maybe that somehow doesn't work with Clover?

On Thu, Jul 5, 2012 at 5:34 PM, Apache Jenkins Server <
[EMAIL PROTECTED]> wrote:

> Build: https://builds.apache.org/job/Lucene-trunk/1981/
>
> All tests passed
>
> Build Log:
> [...truncated 37937 lines...]
>
> [...truncated 37937 lines...]
>
> [...truncated 37937 lines...]
>
> [...truncated 37937 lines...]
>
> [...truncated 37937 lines...]
>
> [...truncated 37937 lines...]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

--
Chris Male

Hi Chris,

 

See my mail from yesterday: Clover does not have a problem with the code, it
is more that the code nesting in this test is so deep, that the filename
generated is too long for the underlying os.

 

Maybe make test simplier with less code nesting (inner-inner-inner classes,
too long variable names). The file name seems to be generated by that.

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: [EMAIL PROTECTED]

 

From: Chris Male [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 05, 2012 7:41 AM
To: [EMAIL PROTECTED]
Subject: Re: [JENKINS] Lucene-trunk - Build # 1981 - Still Failing

 

I don't really get what is going on here, apart from that Clover is failing
due to this test.  The file it is looking for seems crazy, is that expected?

 

Having looked at the test, I haven't come across the @ParametersFactory
annotation before but maybe that somehow doesn't work with Clover?

On Thu, Jul 5, 2012 at 5:34 PM, Apache Jenkins Server
<[EMAIL PROTECTED]> wrote:

Build: https://builds.apache.org/job/Lucene-trunk/1981/

All tests passed

Build Log:
[...truncated 37937 lines...]

[...truncated 37937 lines...]

[...truncated 37937 lines...]

[...truncated 37937 lines...]

[...truncated 37937 lines...]

[...truncated 37937 lines...]
---------------------------------------------------------------------

 

--
Chris Male

Thanks Uwe.

Maybe I'm blind but I can't really see any inner classes in this test (or
the classes it extends).  The file names seems to contain the parameters
used to run the test method, I'm not sure where these values are taken from
so I don't know how to compress them.

On Thu, Jul 5, 2012 at 5:55 PM, Uwe Schindler <[EMAIL PROTECTED]> wrote:

> Hi Chris,****
>
> ** **
>
> See my mail from yesterday: Clover does not have a problem with the code,
> it is more that the code nesting in this test is so deep, that the filename
> generated is too long for the underlying os.****
>
> ** **
>
> Maybe make test simplier with less code nesting (inner-inner-inner
> classes, too long variable names). The file name seems to be generated by
> that.****
>
> ** **
>
> -----****
>
> Uwe Schindler****
>
> H.-H.-Meier-Allee 63, D-28213 Bremen****
>
> http://www.thetaphi.de****
>
> eMail: [EMAIL PROTECTED]****
>
> ** **
>
> *From:* Chris Male [mailto:[EMAIL PROTECTED]]
> *Sent:* Thursday, July 05, 2012 7:41 AM
> *To:* [EMAIL PROTECTED]
> *Subject:* Re: [JENKINS] Lucene-trunk - Build # 1981 - Still Failing****
>
> ** **
>
> I don't really get what is going on here, apart from that Clover is
> failing due to this test.  The file it is looking for seems crazy, is that
> expected?****
>
> ** **
>
> Having looked at the test, I haven't come across the @ParametersFactory
> annotation before but maybe that somehow doesn't work with Clover?****
>
> On Thu, Jul 5, 2012 at 5:34 PM, Apache Jenkins Server <
> [EMAIL PROTECTED]> wrote:****
>
> Build: https://builds.apache.org/job/Lucene-trunk/1981/
>
> All tests passed
>
> Build Log:
> [...truncated 37937 lines...]
>
> [...truncated 37937 lines...]
>
> [...truncated 37937 lines...]
>
> [...truncated 37937 lines...]
>
> [...truncated 37937 lines...]
>
> [...truncated 37937 lines...]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]****
>
>
>
> ****
>
> ** **
>
> --
> Chris Male****
>

--
Chris Male | Software Developer | DutchWorks | www.dutchworks.nl

Let's trick clover, by adding magic comments:

 

///CLOVER:OFF

. code .

///CLOVER:ON

 

See
https://confluence.atlassian.com/display/CLOVER026/Using+Source+Directives

 

Uwe

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: [EMAIL PROTECTED]

 

From: Chris Male [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 05, 2012 8:14 AM
To: [EMAIL PROTECTED]
Subject: Re: [JENKINS] Lucene-trunk - Build # 1981 - Still Failing

 

Thanks Uwe.

 

Maybe I'm blind but I can't really see any inner classes in this test (or
the classes it extends).  The file names seems to contain the parameters
used to run the test method, I'm not sure where these values are taken from
so I don't know how to compress them.

On Thu, Jul 5, 2012 at 5:55 PM, Uwe Schindler <[EMAIL PROTECTED]> wrote:

Hi Chris,

 

See my mail from yesterday: Clover does not have a problem with the code, it
is more that the code nesting in this test is so deep, that the filename
generated is too long for the underlying os.

 

Maybe make test simplier with less code nesting (inner-inner-inner classes,
too long variable names). The file name seems to be generated by that.

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de <http://www.thetaphi.de/>

eMail: [EMAIL PROTECTED]

 

From: Chris Male [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 05, 2012 7:41 AM
To: [EMAIL PROTECTED]
Subject: Re: [JENKINS] Lucene-trunk - Build # 1981 - Still Failing

 

I don't really get what is going on here, apart from that Clover is failing
due to this test.  The file it is looking for seems crazy, is that expected?

 

Having looked at the test, I haven't come across the @ParametersFactory
annotation before but maybe that somehow doesn't work with Clover?

On Thu, Jul 5, 2012 at 5:34 PM, Apache Jenkins Server
<[EMAIL PROTECTED]> wrote:

Build: https://builds.apache.org/job/Lucene-trunk/1981/

All tests passed

Build Log:
[...truncated 37937 lines...]

[...truncated 37937 lines...]

[...truncated 37937 lines...]

[...truncated 37937 lines...]

[...truncated 37937 lines...]

[...truncated 37937 lines...]
---------------------------------------------------------------------

 

--
Chris Male

 

--
Chris Male | Software Developer | DutchWorks | www.dutchworks.nl

Hm, the Clover magic comment did not seem to help... I have no idea whats wrong with this test!

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Apache Jenkins Server [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 05, 2012 11:44 PM
> To: [EMAIL PROTECTED]
> Subject: [JENKINS] Lucene-trunk - Build # 1982 - Still Failing
>
> Build: https://builds.apache.org/job/Lucene-trunk/1982/
>
> All tests passed
>
> Build Log:
> [...truncated 38248 lines...]
>
> [...truncated 38248 lines...]
>
> [...truncated 38248 lines...]
>
> [...truncated 38248 lines...]
>
> [...truncated 38248 lines...]
>
> [...truncated 38248 lines...]
>

---------------------------------------------------------------------

This has been failing due to:

BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-trunk/checkout/lucene/build.xml:158: com.cenqua.clover.CloverException: java.io.FileNotFoundException: /usr/home/hudson/hudson-slave/workspace/Lucene-trunk/checkout/lucene/build/test/clover/reports/org/apache/lucene/spatial/PortedSolr3Test_testDistanceOrder__p0_RecursivePrefixTreeStrategy_prefixGridScanLevel_8_SPG__GeohashPrefixTree_maxLevels_12_ctx_SimpleSpatialContext_units_KILOMETERS__calculator_Haversine__worldBounds_Rect_minX__180_0_maxX_180_0_minY__90_0_maxY_90_0_______-1.html (File name too long)

Looks like that long filename is blowing out clover. I seem to remember that we can exclude from clover?

On Jul 6, 2012, at 6:26 AM, Apache Jenkins Server wrote:

> Build: https://builds.apache.org/job/Lucene-trunk/1983/
>
> All tests passed
>
> Build Log:
> [...truncated 38228 lines...]
>
> [...truncated 38228 lines...]
>
> [...truncated 38228 lines...]
>
> [...truncated 38228 lines...]
>
> [...truncated 38228 lines...]
>
> [...truncated 38228 lines...]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

- Mark Miller
lucidimagination.com


---------------------------------------------------------------------

I think Uwe tried excluding it and the build was still failing.  I've no
idea how the name of the test class (PortedSolr3Test) and test method
(testDistanceOrder) translates into that file name.  I somehow feel it is
related to the @ParametersFactory annotation in the method since I cannot
find it used anywhere else in Lucene.  Perhaps we should just rename the
class so it is excluded from running as a test till we've resolved the
problem.

On Sat, Jul 7, 2012 at 1:12 AM, Mark Miller <[EMAIL PROTECTED]> wrote:

> This has been failing due to:
>
> BUILD FAILED
> /usr/home/hudson/hudson-slave/workspace/Lucene-trunk/checkout/lucene/build.xml:158:
> com.cenqua.clover.CloverException: java.io.FileNotFoundException:
> /usr/home/hudson/hudson-slave/workspace/Lucene-trunk/checkout/lucene/build/test/clover/reports/org/apache/lucene/spatial/PortedSolr3Test_testDistanceOrder__p0_RecursivePrefixTreeStrategy_prefixGridScanLevel_8_SPG__GeohashPrefixTree_maxLevels_12_ctx_SimpleSpatialContext_units_KILOMETERS__calculator_Haversine__worldBounds_Rect_minX__180_0_maxX_180_0_minY__90_0_maxY_90_0_______-1.html
> (File name too long)
>
> Looks like that long filename is blowing out clover. I seem to remember
> that we can exclude from clover?
>
> On Jul 6, 2012, at 6:26 AM, Apache Jenkins Server wrote:
>
> > Build: https://builds.apache.org/job/Lucene-trunk/1983/
> >
> > All tests passed
> >
> > Build Log:
> > [...truncated 38228 lines...]
> >
> > [...truncated 38228 lines...]
> >
> > [...truncated 38228 lines...]
> >
> > [...truncated 38228 lines...]
> >
> > [...truncated 38228 lines...]
> >
> > [...truncated 38228 lines...]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> - Mark Miller
> lucidimagination.com
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Chris Male | Software Developer | DutchWorks | www.dutchworks.nl

On Fri, Jul 6, 2012 at 9:16 AM, Chris Male <[EMAIL PROTECTED]> wrote:
> I think Uwe tried excluding it and the build was still failing.  I've no
> idea how the name of the test class (PortedSolr3Test) and test method
> (testDistanceOrder) translates into that file name.  I somehow feel it is
> related to the @ParametersFactory annotation in the method since I cannot
> find it used anywhere else in Lucene.  Perhaps we should just rename the
> class so it is excluded from running as a test till we've resolved the
> problem.
>

I agree this is the problem, though in general we have used pure junit
parameterized tests with clover before, just not with
ParametersFactory.

Maybe Dawid has some insight into why this parameterized test gets
such a long name and if there is a way we can work around it?

--
lucidimagination.com

---------------------------------------------------------------------

On Fri, Jul 6, 2012 at 2:44 PM, Robert Muir <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 6, 2012 at 9:16 AM, Chris Male <[EMAIL PROTECTED]> wrote:
>> I think Uwe tried excluding it and the build was still failing.  I've no
>> idea how the name of the test class (PortedSolr3Test) and test method
>> (testDistanceOrder) translates into that file name.  I somehow feel it is
>> related to the @ParametersFactory annotation in the method since I cannot
>> find it used anywhere else in Lucene.  Perhaps we should just rename the
>> class so it is excluded from running as a test till we've resolved the
>> problem.
>>
>
> I agree this is the problem, though in general we have used pure junit
> parameterized tests with clover before, just not with
> ParametersFactory.
>
> Maybe Dawid has some insight into why this parameterized test gets
> such a long name and if there is a way we can work around it?
>
> --
> lucidimagination.com
Actually i found it. This parameter name (p0) is coming from
RecursivePrefixTreeStrategy.toString

Can we make this toString method less verbose?

--
lucidimagination.com

---------------------------------------------------------------------

>> Maybe Dawid has some insight into why this parameterized test gets
>> such a long name and if there is a way we can work around it?

Sorry, I was out. I don't know how this is related to the output files
but parameterized tests do contain their parameters in their
description (name) so .toString should return a sensible value for the
test description. Also see this example for @Name annotation which can
be used to name parameters for clarity:

https://github.com/carrotsearch/randomizedtesting/blob/master/examples/maven/src/main/java/com/carrotsearch/examples/randomizedrunner/Test007ParameterizedTests.java

Dawid

---------------------------------------------------------------------

On Fri, Jul 6, 2012 at 2:58 PM, Dawid Weiss
<[EMAIL PROTECTED]> wrote:
>>> Maybe Dawid has some insight into why this parameterized test gets
>>> such a long name and if there is a way we can work around it?
>
> Sorry, I was out. I don't know how this is related to the output files
> but parameterized tests do contain their parameters in their
> description (name) so .toString should return a sensible value for the
> test description. Also see this example for @Name annotation which can
> be used to name parameters for clarity:
>

I committed a workaround (not wanting to change non-test code for
clover), that boxes the param in a holder object with a simple
toString.

lets see if the build succeeds tonight.

--
lucidimagination.com

---------------------------------------------------------------------

Ok, now I get what the problem was so for anybody who wants to use
parameterized tests a short clarification:

1) The factory method returns arguments for the constructor:

@ParametersFactory
public static Iterable<Object[]> parameters() { ... }

2) the constructor is, for example:

public MySuiteClass(Integer param1, Integer param2) {

3) RandomizedRunner will create a tree of tests where each method will
have sub-nodes corresponding to parameters passed to the constructor.
To make these tests legible, parameters must supply a sensible (and
short!) toString() because that's what's used in test naming. So if
parameters were two Integers: 2 and 3, the tests would be named:

method {p0=2 p1=3}

The "p0" and "p1" are parameter names which are, unfortunately,
missing from java reflection API (cannot be extracted at runtime even
if they're present in the debug symbols). For naming them to something
more sensible you can use @Name annotation. In the above example we
could use:

public MySuiteClass(@Name("param1") Integer param1, @Name("param2"
Integer param2) {

which would result in tests named:

method {param1=2 param2=3}

Hopefully it's clearer now.

Dawid

---------------------------------------------------------------------

On Fri, Jul 6, 2012 at 2:58 PM, Dawid Weiss
<[EMAIL PROTECTED]> wrote:

> Also see this example for @Name annotation which can
> be used to name parameters for clarity:
>
> https://github.com/carrotsearch/randomizedtesting/blob/master/examples/maven/src/main/java/com/carrotsearch/examples/randomizedrunner/Test007ParameterizedTests.java
>

ok i did this too, looks much nicer in the ide:

testIntersections {strategy=recursive_geohash} (0.230s)
testIntersections {strategy=recursive_quad} (0.058s)
...
and so on
--
lucidimagination.com

---------------------------------------------------------------------