: We are going to setup Hudson to run the nightly.sh so that the
: website and javadocs are pushed to people.a.o. I think this makes
: more sense, b/c if Hudson fails then critical things like the website
: and javadocs are down, whereas I think p.a.o seems to be better in
+1 for the stability of
OK, I have Hudson access, and I notice that Doug does as well, so we
have at least three people capable of administering. Anyone else w/
zones access can see the wiki for instructions on how to access. It
is pretty straightforward.
We are going to setup Hudson to run the nightly.sh so tha
On Mar 31, 2007, at 7:26 PM, Chris Hostetter wrote:
: I imagine there are user accounts/passwords available. I volunteer
: to be his backup, although I hope the only reason I would be needed
: for it is if he decides he doesn't want to maintain it anymore and
: not the bus scenario.
Sorry, i
: I imagine there are user accounts/passwords available. I volunteer
: to be his backup, although I hope the only reason I would be needed
: for it is if he decides he doesn't want to maintain it anymore and
: not the bus scenario.
Sorry, i didn't mean to be negative -- it's just the classic
tec
I will ask Nigel to update http://wiki.apache.org/lucene-java/
HowNightlyBuildsAreMade
I imagine there are user accounts/passwords available. I volunteer
to be his backup, although I hope the only reason I would be needed
for it is if he decides he doesn't want to maintain it anymore and
: It is still running the crontab. I haven't had time to move over to
: the Hudson stuff, yet. I will try to this weekend.
I thought the Lucene Hudson install was "beta" ... something someone on
Nutch was experimenting with and setup for all lucene subprojects to test
it out ... if Hudson is "
It is still running the crontab. I haven't had time to move over to
the Hudson stuff, yet. I will try to this weekend.
-Grant
On Mar 30, 2007, at 12:44 PM, Doug Cutting wrote:
java-dev@lucene.apache.org wrote:
BUILD FAILED
/tmp/lucene-nightly-gsi/common-build.xml:210: Tests failed!
Total
java-dev@lucene.apache.org wrote:
BUILD FAILED
/tmp/lucene-nightly-gsi/common-build.xml:210: Tests failed!
Total time: 11 minutes 19 seconds
Are we still running a crontab-based nightly? I thought Hudson had
replaced this?
http://lucene.zones.apache.org:8080/hudson/view/Lucene/
We shouldn
This may be an infrastructure issue because according to Parabuild everything
is fine:
http://parabuild.viewtier.com:8080/parabuild/build/log.htm?logid=3405&buildrunid=2568
Slava
- Original Message -
From:
To:
Sent: Thursday, March 29, 2007 4:23 PM
Subject: Lucene nightly b
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
clover.setup:
[mkdir] Created dir: /tmp/lucen
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
clover.setup:
[mkdir] Created dir: /tmp/lucen
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
clover.setup:
clover.info:
[echo]
[ec
This is caused by the same java.io.tempdir problem with
TestFieldsReader.testLazyPerformance. I have been working on nighly
builds on lucene.zones (Lucene 708) and I am afraid my testing of the
script is conflicting with Doug's nightly cron job when it comes to
testing.
I think we should
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
clover.setup:
[mkdir] Created dir: /tmp/lucen
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
clover.setup:
clover.info:
[echo]
[ec
blem, but i'm not sure if those other new directories
> should have javadocs as well.
>
> can you take care of this?
>
>
> : Date: Thu, 14 Dec 2006 00:08:46 +
> : From: java-dev@lucene.apache.org
> : To: java-dev@lucene.apache.org
> : Subject: Lucene night
ocs as well.
can you take care of this?
: Date: Thu, 14 Dec 2006 00:08:46 +
: From: java-dev@lucene.apache.org
: To: java-dev@lucene.apache.org
: Subject: Lucene nightly build failure
:
:
: javacc-uptodate-check:
:
: javacc-notice:
: [echo]
: [echo] One or more of the JavaCC .
problem, but i'm not sure if those other new directories
should have javadocs as well.
can you take care of this?
: Date: Thu, 14 Dec 2006 00:08:46 +
: From: java-dev@lucene.apache.org
: To: java-dev@lucene.apache.org
: Subject: Lucene nightly build failure
:
:
: javacc-uptodate-check:
:
: j
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
clover.setup:
clover.info:
[echo]
[ec
: [javac]
/tmp/lucene-nightly/src/java/org/apache/lucene/queryParser/QueryParser.java:654:
cannot resolve symbol
: [javac] symbol : method toChars (int,char[],int)
: [javac] location: class java.lang.Character
: [javac] length += Character.toChars(codePoint, output, le
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
common.compile-core:
[mkdir] Created dir: /tm
On 11/3/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: Misconfigured IP address on the host that does the nightly builds
: (prob due to the infra move)
: I just corrected it.
For posterity / future refernece, can you clarify:
1) what the host is/was?
lucene.zones.apache.org
2) how you c
: Misconfigured IP address on the host that does the nightly builds
: (prob due to the infra move)
: I just corrected it.
For posterity / future refernece, can you clarify:
1) what the host is/was?
2) how you corrected it?
-Hoss
---
On 11/2/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
So that's 2 days in a row that the nightly build has failed because of a
connection timeout in TestRemoteSearchable .. the tests works locally (for
me anyway
Misconfigured IP address on the host that does the nightly builds
(prob due to the
So that's 2 days in a row that the nightly build has failed because of a
connection timeout in TestRemoteSearchable .. the tests works locally (for
me anyway)
I don't know a lot about RMI, but the test seems to be doing the right
thing: registering an RMI resource on localhost, and then connectin
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
common.compile-core:
[mkdir] Created dir: /tm
javacc-uptodate-check:
javacc-notice:
[echo]
[echo] One or more of the JavaCC .jj files is newer than its
corresponding
[echo] .java file. Run the "javacc" target to regenerate the
artifacts.
[echo]
init:
common.compile-core:
[mkdir] Created dir: /tm
27 matches
Mail list logo
