[
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
.
> 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/
! (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://issu
!
> 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/
[
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-te
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
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
commi
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 a
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
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 wrote:
> Hi all,
>
> After multiple iterations and failed Hudson build, Mike and me got it
> run
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 the
[
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 or
load
[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 cl
sion: 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
>
add the test for
ASCII folding back (was bug in 2.5.1).
When hudson is reconfigured, this should be ready for commit.
> Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3
> or
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791470#action_12791470
]
Uwe Schindler commented on LUCENE-1769:
---
I verified, the latest clover ver
[
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 analy
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:comment-tabpanel&focusedCommentId=12791241#action_12791241
]
Uwe Schindler commented on LUCENE-1769:
---
For fixing the clover analysis on hu
d up ...
> Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3
> or better
> ---
>
> Key: LUCENE-1769
> URL: https://issues.apache.org/j
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 aga
svn, 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 machin
just 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.ja
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739842#action_12739842
]
Nick Pellow commented on LUCENE-1769:
-
Hi Uwe,
Clover will still produce
nked in clover-setup via , 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
compatibi
nked in clover-setup via , 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
compatibi
end 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 , if I leave this ou
not need for
your regression tests
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
th
. 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,
all backwards 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 c
your patch to integrate Clover, you also excluded
> the following from instrumentation:
>
> Do you remember the error you were getting when Clover tried to
> instrument this file?
>
> I was getting:
> [clover] /Users/niick/work/hudson/plugins/clover/work/jobs/Lucene/
> w
call 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 "publishin
rstanding 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
w
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" artifac
y 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 reaso
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 "nigh
: 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
eded 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 fo
5 AM:
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, w
for all yours by making Lucene!
re: ..
OK - I was not aware of the backwards-branch tests.
As long as the right tests are being instrumented Clover, and correctly
detected as tests, then all should be good.
bq. The problem with that is, that we then have clover.jar inside the source
distribu
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
eans 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
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
[
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 be
9 PM:
--
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 a
[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737366#action_12737366
]
Nick Pellow commented on LUCENE-1769:
-
HI Uwe,
Great work getting Clover upgr
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 is
6 PM:
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 hu
[
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
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-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
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 the
hing 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 p
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 di
[
https://issues.apache.org/jira/browse/LUCENE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578615#action_12578615
]
Hoss Man commented on LUCENE-1202:
--
bq. Does the Clover license allow instrumenting
[
https://issues.apache.org/jira/browse/LUCENE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575702#action_12575702
]
Grant Ingersoll commented on LUCENE-1202:
-
Does the Clover license a
[
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.db-contrib-instrumentation.patch
patch to limit the files we ask clover to
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 as a
that needs to be ironed out.
can you elaborate on what problems you know of?
I just tried running the clover build locally, it works for core stuff,
and i see the bdb contrib instrumentation failure -- that seems easy to
fix with something like this in common-build.xml
o 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.
n/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
-
To unsubscribe, e-mail: [EMAIL PROTECTED
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,
--- 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 main
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 Parab
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: [EMA
: 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 m
t had an "svn remove" 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 t
:[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
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 fi
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 clo
lds 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 repor
nightly.sh 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
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
76 matches
Mail list logo
