[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738754#action_12738754
]
Hoss Man commented on LUCENE-1769:
----------------------------------
bq. I only want to remove the 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 "publishing" artifacts before testing them. that was the
whole point behind the double run when clover was first introduced: run the
tests to ensure there *should* be a build, then produce the build artifacts,
then run reports against the build.
i don't disagree with your goal: if we can eliminate the double test run that
would be great, i'm just explaining why it is the way it is, and why removing
that middle step will result in a process which isn't equivalent.
bq. We will be generating a new site license for org.apache that can also be
committed to your public svn server, so anyone wanting to develop on Lucene can
just use Clover out of the box, on their desktop.
Nick: if i'm understanding 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 their affiliation is with the ASF)
FYI: in addition to 1.3.2, Apache already has a clover.license file for 2.0.3
and 2.4.3 (Lucene just never got around to using them in our build system) and
these are checked into the "private" svn repository (ie: only accessible to
committers). The fact that these licenses are committed into the private
repository suggests that when they were granted to the ASF, it was with some
instructions that it only be made available to people who were directly
associated with the AF, and not made publicly available (The README files
associated with the licenses don't contain any specific instructions either
way, so the location in "private/committers" suggests it's access restriction).
I believe that has been the general understanding of many ASF projects, and is
the basis for the current hacks in the Lucene build system -- it was never an
issue of where to put clover.jar, it was an issue of making sure anyone could
use the build.xml file even without access to a clover.license.
If we truly can make both the license publicly available then we could simplify
a lot of things by commiting clover.license into the source tree (and including
in source releases), and having the build file download the clover.jar as
needed if people set the build property to run the tests in clover.
If i am in fact understanding this all correctly, then the best way to proceed
is if you (or someone else with an @atlassian.com address) could send an
"official" email to java-...@lucene spelling out exactly how the license can be
used/disseminated. then one of the lucene committers can commit the new
license into both the private/committers repository along with the full email
so that there won't be any confusion for other developers in other projects
about how it can be shared. .... then we copy the license to the lucene
repository and commit the simplifications to the lucene build system.
> 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
> Project: Lucene - Java
> Issue Type: Bug
> Components: Build
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Attachments: LUCENE-1769.patch, LUCENE-1769.patch,
> nicks-LUCENE-1769.patch
>
>
> This is a followup for
> [http://www.lucidimagination.com/search/document/6248d6eafbe10ef4/build_failed_in_hudson_lucene_trunk_902]
> The problem with clover running on hudson is, that it does not instrument all
> tests ran. The autodetection of clover 1.x is not able to find out which
> files are the correct tests and only instruments the backwards test. Because
> of this, the current coverage report is only from the backwards tests running
> against the current Lucene JAR.
> You can see this, if you install clover and start the tests. During test-core
> no clover data is added to the db, only when backwards-tests begin, new files
> are created in the clover db folder.
> Clover 2.x supports a new ant task, <testsources> that can be used to specify
> the files, that are the tests. It works here locally with clover 2.4.3 and
> produces a really nice coverage report, also linking with test files work, it
> tells which tests failed and so on.
> I will attach a patch, that changes common-build.xml to the new clover
> version (other initialization resource) and tells clover where to find the
> tests (using the test folder include/exclude properties).
> One problem with the current patch: It does *not* instrument the backwards
> branch, so you see only coverage of the core/contrib tests. Getting the
> coverage also from the backwards tests is not easy possible because of two
> things:
> - the tag test dir is not easy to find out and add to <testsources> element
> (there may be only one of them)
> - the test names in BW branch are identical to the trunk tests. This
> completely corrupts the linkage between tests and code in the coverage report.
> In principle the best would be to generate a second coverage report for the
> backwards branch with a separate clover DB. The attached patch does not
> instrument the bw branch, it only does trunk tests.
--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
