: One minor bug, the new 'no-dbd-lib' variable in db/bdb/build.xml should be
: spelled 'no-bdb-lib' (bdb instead of dbd).
ah yes ... that's my perl roots showing through.
FWIW: I also made one other small change to the bdb nd bdb-je tests so
that they would put the indexes they make in the tmp
: ...the issue of what to do about contrib/db/bdbd's native library
: dependencies should definitely be discussed.
:
: As the maintainer of the contrib/db tree, I should point out that indeed,
: the bdb part depends on a C release of Sleepycat's (now Oracle) Berkeley DB.
Andi: could you please
On Tue, 29 May 2007, Chris Hostetter wrote:
: ...the issue of what to do about contrib/db/bdbd's native library
: dependencies should definitely be discussed.
:
: As the maintainer of the contrib/db tree, I should point out that indeed,
: the bdb part depends on a C release of Sleepycat's
On Fri, 18 May 2007, Chris Hostetter wrote:
Even if we get the neccessary native lib installed on the lucene zone for
nightly builds, that doesn't really help in the case of official releases
where a release manager builds locally -- assuming the tests are fine
because the nightly buidls are
On Fri, 18 May 2007, Andi Vajda wrote:
If the Runtime.loadLibrary() API can load the bdb native library, the tests
should be run, else they should be skipped with a warning. [1]
i suppose we could just define bdb test target to only run if some new
test.contrib.db.bdb property is set --
:
: According to the Berkeley DB Java/C interface sources, this call look like:
:- on Unix
: System.loadLibrary(libdb_java- + VERSION_MAJOR + . + VERSION_MINOR)
:- on Windows
: System.loadLibrary(libdb_java + VERSION_MAJOR + VERSION_MINOR)
really? ... can you give a link to
On Friday 18 May 2007 18:52, Doug Cutting wrote:
...
Paul Elschot wrote:
When a contrib fails and is not fixed, that might be a good reason to
remove it from the distribution. With such a policy the present contribs
would
also stay up to date, provided their tests are good enough.
Andi Vajda wrote on 5/18/2007, 9:50 PM:
As the maintainer of the contrib/db tree, I should point out that indeed,
the bdb part depends on a C release of Sleepycat's (now Oracle)
Berkeley DB.
Would it make sense to migrate to the BDB Java Edition?
: Would it make sense to migrate to the BDB Java Edition?
:
: http://www.oracle.com/database/berkeley-db/je/index.html
unless i'm missing something, both versions are currently supported
(contrib/db/bdb and contrib/db/bdb-je)
-Hoss
On Sat, 19 May 2007, Sean Timm wrote:
Andi Vajda wrote on 5/18/2007, 9:50 PM:
As the maintainer of the contrib/db tree, I should point out that indeed,
the bdb part depends on a C release of Sleepycat's (now Oracle)
Berkeley DB.
Would it make sense to migrate to the BDB Java Edition?
+1 for renaming the 'test' target to 'test-core', and adding a 'test'
target that depends on 'test-core' and 'test-contrib'. That's what
other projects tend to do.
Paul Elschot wrote:
When a contrib fails and is not fixed, that might be a good reason to
remove it from the distribution. With
Doug Cutting wrote:
If a contrib package is failing tests or breaking the build, then we
should file an issue in Jira. One potential patch is to remove the
package (since incompatible changes are permitted in contrib). That
can be proposed, and if no one with a binding vote objects, it can
: +1 for renaming the 'test' target to 'test-core', and adding a 'test'
: target that depends on 'test-core' and 'test-contrib'. That's what
: other projects tend to do.
This proved a little tricker then i originally thought, but i've got it
working (it even runs all tests on all contribs
On Fri, 18 May 2007, Chris Hostetter wrote:
: +1 for renaming the 'test' target to 'test-core', and adding a 'test'
: target that depends on 'test-core' and 'test-contrib'. That's what
: other projects tend to do.
This proved a little tricker then i originally thought, but i've got it
: allows the bdb contrib module to build for everyone. To run tests though, a
: functioning install of Berkeley DB is required.
:
: If it's practical to install a live version of Berkeley DB on the Lucene build
: bot machines, I'd have no objections in doing so. All I need is ssh access and
Even
: Yeah, I hate to admit it and start another round of Maven vs. ANT,
Yeah, i guess i hsould have been more clear ... my question was not about
how we could improve the build system to ensure this happens ... my
question was about wether or not this behavior is desirable/intentional
It could be
On Thursday 17 May 2007 09:10, Chris Hostetter wrote:
...
It could be argued that contribs are not important enough for contrib test
failures to result in a nightly build failing (I have no strong opinion
about this). It could also be argued that while it's good to run test
against the core
+1 on running the contrib tests. +1 for a policy that tests should
be run when building a release.
On May 17, 2007, at 3:10 AM, Chris Hostetter wrote:
: Yeah, I hate to admit it and start another round of Maven vs. ANT,
Yeah, i guess i hsould have been more clear ... my question was not
Grant Ingersoll [EMAIL PROTECTED] wrote on 17/05/2007 04:09:59:
+1 on running the contrib tests. +1 for a policy that tests should
be run when building a release.
+1 for both as well.
In fact I would rename current target test to test-core
and make a new target test which depends on both
: In fact I would rename current target test to test-core
: and make a new target test which depends on both test-core
: and test-contrib. That way during developing you can run
: test-core - that should be quicker. But the nightly and the
i'm certianly on board with that ... i would have
@lucene.apache.org
Sent: Thursday, May 17, 2007 3:51:14 AM
Subject: Re: Tests, Contribs, and Releases
On Thursday 17 May 2007 09:10, Chris Hostetter wrote:
...
It could be argued that contribs are not important enough for contrib test
failures to result in a nightly build failing (I have no strong opinion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From: Paul Elschot [EMAIL PROTECTED]
To: java-dev@lucene.apache.org
Sent: Thursday, May 17, 2007 3:51:14 AM
Subject: Re: Tests, Contribs, and Releases
Hey everybody, this thread has been sitting in my inbox for a while
waiting for me to have a few minutes to look into it...
http://www.nabble.com/Packaging-Lucene-2.1.0-for-Debian--found-2-junit-errors-tf3571676.html
In a nutshell, when a guy from Debian went looking to package Lucene he
Does Lucene have a gump run descriptor? That's quite useful for
tracking this sort of thing too. It's very good at nagging! :)
The standard maven assembly packaging runs the unit tests by default
too. Changing the lucene build system to maven is not something
you'd want to jump at
Yeah, I hate to admit it and start another round of Maven vs. ANT,
but Maven does take care of darn near all these issues. :-) To
share my experience, we are actually in the process of upgrading from
Maven 1 to Maven 2. The docs are good for the basics (i.e. 80-90% of
what you need),
To answer your question, though, I don't see any reason not to make
the changes to make the current process more repeatable.
Yeah, mod'ing the ant process now is going to be simpler to catch the
current problem. Still, I'd check the Gump stuff for Lucene, because
I'd be surprised that
26 matches
Mail list logo
