[
https://issues.apache.org/jira/browse/LUCENE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-1202:
-----------------------------
Attachment: LUCENE-1202.patch
builds on previous patch to fix contrib/db (which i should note: also
centralized teh clover "db" and reports so they were in one place even if you
ran clover on individual contribs) to also fix it so the classpath for runing
the contrib tests can find clover.
without this patch, contrib tests don't include ${java.class.path} (the core
tests did) ... this was causing a problem because ${java.class.path} is where i
had the clover jar and dependencies.
i'm not sure if we want to change this to add an explicit "clover.path"
property that people must set saying explicitly where they want the build
system to look for clover ... that seems like a cleaner way to ensure the
contrib tests don't include stuff in the junit classpath that they shouldn't -
but it may not be a big deal considering the core tests have always worked this
way.
comments?
Grant: still need clarification on your comments about hudson...
bq. ...There is also a bit of a change on Hudson during the migration to the
new servers that needs to be ironed out.
> Clover setup currently has some problems
> ----------------------------------------
>
> Key: LUCENE-1202
> URL: https://issues.apache.org/jira/browse/LUCENE-1202
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Hoss Man
> Attachments: LUCENE-1202.db-contrib-instrumentation.patch,
> LUCENE-1202.patch
>
>
> (tracking as a bug before it get lost in email...
>
> http://www.nabble.com/Clover-reports-missing-from-hudson--to15510616.html#a15510616
> )
> The clover setup for Lucene currently has some problems, 3 i think...
> 1) instrumentation fails on contrib/db/ because it contains java packages the
> ASF Clover lscence doesn't allow instrumentation of. i have a patch for this.
> 2) running instrumented contrib tests for other contribs produce strange
> errors...
> {{monospaced}}
> [junit] Testsuite: org.apache.lucene.analysis.el.GreekAnalyzerTest
> [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.126 sec
> [junit]
> [junit] ------------- Standard Error -----------------
> [junit] [CLOVER] FATAL ERROR: Clover could not be initialised. Are you
> sure you have Clover
> in the runtime classpath? (class
> java.lang.NoClassDefFoundError:com_cenqua_clover/CloverVersionInfo)
> [junit] ------------- ---------------- ---------------
> [junit] Testcase:
> testAnalyzer(org.apache.lucene.analysis.el.GreekAnalyzerTest): Caused
> an ERROR
> [junit] com_cenqua_clover/g
> [junit] java.lang.NoClassDefFoundError: com_cenqua_clover/g
> [junit] at
> org.apache.lucene.analysis.el.GreekAnalyzer.<init>(GreekAnalyzer.java:157)
> [junit] at
> org.apache.lucene.analysis.el.GreekAnalyzerTest.testAnalyzer(GreekAnalyzerTest.java:60)
> [junit]
> [junit]
> [junit] Test org.apache.lucene.analysis.el.GreekAnalyzerTest FAILED
> {{monospaced}}
> ...i'm not sure what's going on here. the error seems to happen both when
> trying to run clover on just a single contrib, or when doing the full
> build ... i suspect there is an issue with the way the batchtests fork
> off, but I can't see why it would only happen to contribs (the regular
> tests fork as well)
> 3) according to Grant...
> {{quote}}
> ...There is also a bit of a change on Hudson during the migration to the new
> servers that needs to be ironed out.
> {{quote}}
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
