.
Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.6.3
or better
---
Key: LUCENE-1769
URL: https://issues.apache.org/jira/browse/LUCENE-1769
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1769:
--
Fix Version/s: 3.1
Fix wrong clover analysis because of backwards-tests, upgrade clover
Thanks Atlassian!
The new clover report (after ugprading to 2.6 for our nighly build) is
fabulous -- eg from yesterday's Lucene trunk build:
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/1033/clover-report
I think we should call wider attention to this, so other Apache
committers
As a first step we should upload to the private committers area where the
other clover licenses are. But also make public, that it's now open for all,
also non-committers.
Do we have to contact infrastructure or whoever first?
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1769:
--
Attachment: (was: clover.license)
Fix wrong clover analysis because of backwards-tests
!
Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.6.3
or better
---
Key: LUCENE-1769
URL: https://issues.apache.org/jira/browse/LUCENE-1769
! (without ASF
grant attached)
Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.6.3
or better
---
Key: LUCENE-1769
URL: https://issues.apache.org/jira
Hi all,
After multiple iterations and failed Hudson build, Mike and me got it
running:
We upgraded the build.xml and Hudson configuration to use now Clover 2.6.3
with a new license for Apache projects granted by Nick Pellow from
Atlassian. The new reports now cover all tests not only
Uwe, do you know why the assert lines come through as not covered?
Are we not running w/ asserts enabled when we run with clover?
Mike
On Thu, Dec 17, 2009 at 1:25 PM, Uwe Schindler u...@thetaphi.de wrote:
Hi all,
After multiple iterations and failed Hudson build, Mike and me got it
running
I will try this out later and add an always-failing assert to the code and
try with/without clover. I will add this as a test:
try {
assert false;
fail(asserts disabled)
} catch (AssertionFailedError e} {}
Maybe Nick can explain this to us. This was the same behaviour in clover
1
and tag tests completely. Currently the xml files for
test report generation are mixed together, so tag tests overwrite core results.
This was by the way the reason for the defect in clover 1.x - only recorded
test runs were instrumented. Also contrib was missing. The junit report now
generates
this, but it would break hudson. Somebody with hudson
access (command line + config) should do the following:
- download
[http://www.atlassian.com/software/clover/downloads/binary/clover-ant-2.5.1.zip]
and extract the clover.jar
- download
[https://svn.apache.org/repos/private/committers/donated
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1769:
--
Affects Version/s: (was: 2.9)
3.1
Fix wrong clover analysis
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791470#action_12791470
]
Uwe Schindler commented on LUCENE-1769:
---
I verified, the latest clover version
: 891402
I keep this open because of further improvements with license and maybe ship it
with lucene.
Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3
or better
[http://repo2.maven.org/maven2/com/cenqua/clover/clover/2.6.3/clover-2.6.3.jar]
- fetch the attached license
[https://issues.apache.org/jira/secure/attachment/12415461/clover.license]
put both in your ANT lib path - have fun.
Fix wrong clover analysis because of backwards-tests, upgrade clover
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1769:
--
Summary: Fix wrong clover analysis because of backwards-tests, upgrade
clover to 2.6.3
...
Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3
or better
---
Key: LUCENE-1769
URL: https://issues.apache.org/jira/browse/LUCENE-1769
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791241#action_12791241
]
Uwe Schindler commented on LUCENE-1769:
---
For fixing the clover analysis on hudson
for the JAR and license!
bq. Clover will automatically detect any tests it finds as it instruments the
source code.
But they must not be tests nor available as source code? I say this, because
the backwards tests are not available as source code, they are only packaged in
a JAR and then run against
to integrate Clover, you also excluded
the following from instrumentation:
exclude name=org/apache/lucene/analysis/
TestASCIIFoldingFilter.java /!-- Class too large for clover --
Do you remember the error you were getting when Clover tried to
instrument this file?
I was getting:
[clover] /Users
compatibility layers in Lucene core still work
the same as before).
All tests in Lucene Core use only the new API, so to test the old APIs, the
backwards tests do their job for the deprecated methods. The problem is now,
that I cannot simply add this special build step to the clover analysis,
because
. It was definitely a problem with Clover not
correctly handling a unicode 4.1 character in the source file.
Clover was incorrectly asserting that if Character.isDefined(); returns false,
then the character is illegal. That method only returns true for unicode
Unicode 4.0 characters in java 1.5
bq. so the linkage in the clover reports between tests and source code are
completely broken.
In what way is it broken? Are the test method names missing, or do you have
duplicate test methods? There should be one testMethod listed for each test run
that occured.
bq. Is there any possibility
of the week, when you sent me the 2.6 snapshot
build. My problems are currently:
- The tests are not directly instumented (neither in core nor contrib nor bw).
Currenty the core classes and contrib classes are instrumented. The testcases
are linked in clover-setup via testsources, if I leave
in clover-setup via testsources, if I leave this out, I get 0%
coverage. The backwards tests do not appear in testsources. Because of that,
the tests still call the instrumented classes, but the coverage report shows no
coverage. You can easily see this e.g. for the old HitCollector backwards
in clover-setup via testsources, if I leave this out, I get 0%
coverage. The backwards tests do not appear in testsources. Because of that,
the tests still call the instrumented classes, but the coverage report shows no
coverage. You can easily see this e.g. for the old HitCollector backwards
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12739842#action_12739842
]
Nick Pellow commented on LUCENE-1769:
-
Hi Uwe,
Clover will still produce code
for you
[here|http://www.atlassian.com/software/clover/downloads/binary/clover-2.6.0-dev.jar].
Please note that this is a dev build.
This is a development build of Clover 2.6 . It has support for recognizing the
org.apache site license attached to this issue.
Simply put the clover.jar
, someone from Atlassian will send
the following email to the lucene mailing list confirming the usage and terms
of the site license.
{quote}
This Clover license can be used for any code that is under an org.apache
package. Further, this license can be used by any developer on their machine
to the (I call it deprecated nightly
target, which is a relict from the time before Hudson and replace by package
in the first run and to ant test for the clover enabled version. The build
would run two times faster.
But then we would be publishing artifacts before testing them
it deprecated nightly
target, which is a relict from the time before Hudson and replace by package
in the first run and to ant test for the clover enabled version. The build
would run two times faster.
But then we would be publishing artifacts before testing them. that was the
whole point behind
this comment correctly you are implying...
* that you represent Atlassian and are offering an updated license to use
clover 2.x
* that Atlassian will allow us to make this license available for anyone,
anywhere in the world, to use when building/developing Lucene (regardless of
what
that all of the src and test java files in contrib will also be
instrumented by clover, if that is what you want?
Not really, my intention was to only instrument the source files using the
tests (I can see this, that during compilation it tells me that XXX files are
instrumented). This is how
a bug in the hudson build script:
The new clover version creates very large additional class files when
instrumenting the source, which also go into the TAR file.
Hudson builds this tar file without clover and publishes it, which is ok. But
later hudson runs all tests a second time, with clover
:
Here an updated patch with merged changes.
There is currently a bug in the hudson build script:
The new clover version creates very large additional class files when
instrumenting the source, which also go into the TAR file.
Hudson builds this tar file without clover and publishes it, which
to run the tests without clover at all?
I didn't realize the nightly build runs the tests twice (with w/o clover); I
agree, running only with clover seems fine?
bq. Mike: You told me, that I should apply for a hudson account. On the Wiki
page stands, that this is only possible for PMCs?
Urgh
: I didn't realize the nightly build runs the tests twice (with w/o
: clover); I agree, running only with clover seems fine?
i'm not caught up on this issue, but i happen to notice this comment in
email.
the reason the tests are run twice is because in between the two runs we
package up
the binary package
- ant clean
- ant nightly with clover enabled - This packages the binaries again, but
does not copy them. This is also not the best. This step should simple do
ant test with clover
- build the clover report
I only want to remove the call to the (I call it deprecated nightly
target, which
it here for completeness:
: I didn't realize the nightly build runs the tests twice (with w/o
: clover); I agree, running only with clover seems fine?
i'm not caught up on this issue, but i happen to notice this comment in
email.
the reason the tests are run twice is because in between
Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3
or better
---
Key: LUCENE-1769
URL: https://issues.apache.org/jira/browse/LUCENE-1769
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1769:
--
Attachment: LUCENE-1769.patch
This patch uses the features ov clover 2.0.
We can only commit
:
This patch uses the features ov clover 2.0.
We can only commit this to trunk, when hudson is able to use clover 2.0. The
JAR and license files are in the private contributor area
[https://svn.apache.org/repos/private/committers/donated-licenses/clover/2.4.3]
and can be installed on hudson
Upgrade Clover to 2.5.1
---
Key: LUCENE-1772
URL: https://issues.apache.org/jira/browse/LUCENE-1772
Project: Lucene - Java
Issue Type: Task
Components: Build
Reporter: Nick Pellow
Lucene
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12737366#action_12737366
]
Nick Pellow commented on LUCENE-1769:
-
HI Uwe,
Great work getting Clover upgraded
:
--
HI Uwe,
Great work getting Clover upgraded. I've also done an upgrade, although have
some test failures on my local machine. I am pretty sure these are not caused
by Clover, however would love for you to double check.
Clover 2 does not require the clover.jar to be installed into an Ant Lib
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Pellow updated LUCENE-1769:
Attachment: nicks-LUCENE-1769.patch
a patch to upgrade to clover 2.5.1 .
Clover 2.5.1 can
of https://issues.apache.org/jira/browse/LUCENE-1769
Upgrade Clover to 2.5.1
---
Key: LUCENE-1772
URL: https://issues.apache.org/jira/browse/LUCENE-1772
Project: Lucene - Java
Issue Type: Task
Components: Build
[
https://issues.apache.org/jira/browse/LUCENE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-1202.
-
Resolution: Fixed
OK, I confirm that Clover reports are now being generated. Looks
LUCENE-1202:
Assignee: Grant Ingersoll
I was hoping seeing it again would jog your memory : )
i committed the changes to the build files, if the hudson problem
was related to the classpath for clover this may magically solve
that problem -- if not, just
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
said that long ago?
I _believe_ it has to do with where clover and other libraries are now
located. Before they were in ant/lib, now they are elsewhere. When you commit
these, I can look into that piece.
Clover setup currently has some problems
the changes to the build files, if the hudson problem was related
to the classpath for clover this may magically solve that problem -- if not,
just makesure whatever directory clover is in gets added to the CLASSPATH
before running ant.
Committed revision 637344.
assigning to you to track
[
https://issues.apache.org/jira/browse/LUCENE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578615#action_12578615
]
Hoss Man commented on LUCENE-1202:
--
bq. Does the Clover license allow instrumenting non
[
https://issues.apache.org/jira/browse/LUCENE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575702#action_12575702
]
Grant Ingersoll commented on LUCENE-1202:
-
Does the Clover license allow
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
(tracking
/Lucene-trunk/lastSuccessfulBuild/artifact/trunk/build/test/clover/reports/index.html
...the only things in the artifact directory are the docs and the
changes.html.
-Hoss
-
To unsubscribe, e-mail: [EMAIL PROTECTED
to the hudson zone that has been missed until now?
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/lastSuccessfulBuild/artifact/trunk/build/test/clover/reports/index.html
...the only things in the artifact directory are the docs and the
changes.html.
-Hoss
not sure when they stoped working, possibly a side effect of the move to
the hudson zone that has been missed until now?
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/lastSuccessfulBuild/artifact/trunk/build/test/clover/reports/index.html
...the only things in the artifact directory
Grant Ingersoll wrote:
Also, can someone else verify clover runs? I feel like I am going in
circles and need a sanity check.
I just tried it, clover instrumentation fails for me when I enable
clover and execute target test-core:
[clover] Sorry, you are not licensed to instrument files
:[clover] Sorry, you are not licensed to instrument files in the
: package ''.
:[clover] ** Error(s) occurred and the instrumentation process can't
: continue.
that looks like maybe we have code somwhere without any package
declaration ... the apache clover license only allows
it just blanks out the file
but does not carry over the fact that it was removed. I think this is
what got me in this case.
Mike
Chris Hostetter [EMAIL PROTECTED] wrote:
:[clover] Sorry, you are not licensed to instrument files in the
: package ''.
:[clover] ** Error(s) occurred
: I think this is the danger of applying a patch to a clean area and
: then committing from there: certain SVN operations (remove, changing
: properties, etc) do not survive the svn diff - patch process. When
right ... this doesn't just apply to deleted files, but also files that
were 'svn
Note: https://issues.apache.org/jira/browse/LUCENE-1002 covers these
two issues to the extent that they are breaking the nightly builds.
-Grant
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Guys,
I just wanted to point out that Parabuild has been building Lucene happily for
quite some time
without any problems, with binaries, statistics and everything:
http://parabuild.viewtier.com:8080/parabuild/index.htm?displaygroupid=5
Is there anything that prevent you from considering
Grant,
--- Grant Ingersoll [EMAIL PROTECTED] wrote:
Are you proposing to donate a license to Lucene (ASF) so we can host
it here as long as we choose.
Yes, it is absolutely possible. Just let me know if you want to go ahead with
this.
or do you want to continue to host it as
you
Are you proposing to donate a license to Lucene (ASF) so we can host
it here as long as we choose or do you want to continue to host it as
you already do? The main reason, in my opinion, we use Hudson is b/
c we have control over it, we have someone within the committership
willing to
Also, can someone else verify clover runs? I feel like I am going in
circles and need a sanity check.
Thanks,
Grant
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[
https://issues.apache.org/jira/browse/LUCENE-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Busch closed LUCENE-873.
Resolution: Fixed
This is fixed and verified.
nightly builds depend on clover
depend on clover
---
Key: LUCENE-873
URL: https://issues.apache.org/jira/browse/LUCENE-873
Project: Lucene - Java
Issue Type: Bug
Reporter: Hoss Man
as reported by Michael Pelz Sherman on [EMAIL
script
(but slightly modified). The main modification was that I commented out the
copy of the docs and tar files to the release server (since Hudson takes care
of publishing these now). Unforunately, this meant that the subsequent clover
build further down in the script over-wrote the tar files
nightly builds depend on clover
---
Key: LUCENE-873
URL: https://issues.apache.org/jira/browse/LUCENE-873
Project: Lucene - Java
Issue Type: Bug
Reporter: Hoss Man
as reported by Michael Pelz
72 matches
Mail list logo
