: Check that, Nigel and I had a little snafu on this one. I will try to work it
: out in the coming days.
:
: I notice the code coverage is failing in the Berkeley contrib, which is the
: cause of the problem. There is also a bit of a change on Hudson during the
: migration to the new servers th
Check that, Nigel and I had a little snafu on this one. I will try to
work it out in the coming days.
I notice the code coverage is failing in the Berkeley contrib, which
is the cause of the problem. There is also a bit of a change on
Hudson during the migration to the new servers that ne
It was disabled. I think I have fixed it, so let's see tonight.
-Grant
On Feb 15, 2008, at 4:34 PM, Chris Hostetter wrote:
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/Lu
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
: 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
Argh, I thought I had removed this! Thanks Hoss.
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
you apply a patch that had an "svn remov
:[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 for
instr
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 in
10 matches
Mail list logo
