You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Chris Hostetter <ho...@fucit.org> on 2007/05/17 00:02:32 UTC
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
noticed that the official 2.1.0 release contained 2 test failures -- one
each in the highlighter and spellchecker contribs.
The specifics of the test failures don't really interest me as much as the
question: how did we manage to have a release with test failures?
A few things have jumped out at me while looking into this...
1) the task "build-contrib" can be used to walk the contrib directory
building each contrib, the task "test-contrib" can be used to walk the
contrib directory testing each contrib.
2) the "test" task only tests the lucene-core ... it does not depend on
(or call) "test-contrib"
3) The "nightly" build task depends on the "test" and "package-tgz" task
(which depends on "build-contrib") but at no point is "test-contrib"
run.
4) The steps for creating an official release...
http://wiki.apache.org/lucene-java/ReleaseTodo
...specify using the "dist" and
"dist-src" tasks -- neither of which depend on *ANY* tests being run
(let alone contrib tests)
This seems very strange to me ... i would think that we would want:
a) nightly builds to run the tests for all contribs, ala...
<target name="nightly" depends="test, build-contrib, test-contrib, package-tgz">
b) the release insctructions to make it clear that all unit tests (core
and contrib) should be run prior to creating teh distribution.
Does anyone see any reason not to make these changes?
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Paul Elschot <pa...@xs4all.nl>.
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.
> > Thinking about it a bit more, there is a process to add contribs, but
there
> > is not really a process to remove them. The policy of removing a contrib
> > before a release when its unit tests fail could make a nice fit for that.
>
> I think what you're arguing is that, unlike the core, contrib is not
> guaranteed to be back-compatible (since removing a module is not a
> back-compatible change). Otherwise this is no different than other bugs
> and code changes. 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 happen. We shouldn't release with unresolved issues,
> whether they involve contrib or core. Does that sound reasonable?
Yes.
The idea is roughly to give interested people enough time to fix
a contrib when some of its tests fail. In case no fix is made
available, one can reasonably conclude that there is no more
interest, so removing the contrib can be considered.
An impending release is a good moment for that.
Btw. this presupposes that the contrib unit tests are good enough
from the start, and except for contrib/surround I don't know about
that.
Good enough means that such tests implicitly verify all of
the lucene core library that the contrib can be expected to
normally use.
As long as they pass, such contrib tests are also a good motivation
to keep the contrib close to the core.
I had not considered contribs that depend things other than the
lucene core, but discussion on that has already started.
Regards,
Paul Elschot
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Michael Busch <bu...@gmail.com>.
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
> happen.
+1. A good way to prevent situations in which unmaintained contribs hold
up a release.
> We shouldn't release with unresolved issues, whether they involve
> contrib or core. Does that sound reasonable?
>
+1 of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Chris Hostetter <ho...@fucit.org>.
: 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 dir specified when
the tests are run -- this is a a seperate directory for each contrib under
the top level build/ so it's automaticly removed when "ant clean" is run,
and keeps the tests from polluting the code tree.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Andi Vajda <va...@osafoundation.org>.
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 (now Oracle) Berkeley DB.
>
> Andi: could you please test the most recent patch in LUCENE-885 and give
> any feedback you have on the "SanityLoadLibrary" approach I've taken to
> check if the db/bdb unit tests should be run?
>
> Barring objections i'm planning to commit all of these test-conrtib
> changes in a few days.
>
> https://issues.apache.org/jira/browse/LUCENE-885
Hoss,
Looks good. I tested it with Berkeley DB 4.4.20 and verified that
without DYLD_LIBRARY_PATH set correctly on my Mac, the SanityLoadLibrary class
would fail to load the lib. With that env var properly set though, the
SanityLoadLibrary class succeeds and the db/bdb tests run correctly.
One minor bug, the new 'no-dbd-lib' variable in db/bdb/build.xml should be
spelled 'no-bdb-lib' (bdb instead of dbd).
Thanks for doing this !
Andi..
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Chris Hostetter <ho...@fucit.org>.
: > ...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 test the most recent patch in LUCENE-885 and give
any feedback you have on the "SanityLoadLibrary" approach I've taken to
check if the db/bdb unit tests should be run?
Barring objections i'm planning to commit all of these test-conrtib
changes in a few days.
https://issues.apache.org/jira/browse/LUCENE-885
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Andi Vajda <va...@osafoundation.org>.
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?
>
> http://www.oracle.com/database/berkeley-db/je/index.html
Under contrib/db there already are two directories, one for the Java Edition
under bdb-je and one for the C Edition under bdb.
The bdb contrib was written first, before there even was such a thing as the
Berkeley DB Java Edition. The bdb-je contrib was added later. Both contribs
are maintained. I am the maintainer for both although the coding for the
bdb-je contrib is done by its original author, I just commit his changes.
Both contribs have their purpose. If your project is 100% Java, the BDB Java
Edition should be fine. If your project is not a Java project however, and
its use of Java is just a side-effect of Lucene being written in Java then the
C edition of Berkeley DB is needed.
For example, I use the bdb contrib with PyLucene, a Python wrapper for Lucene
[1], and I share bdb handles and transactions between Lucene and PyLucene in
Chandler, a C Python project [2].
Andi..
[1] http://pylucene.osafoundation.org/
[2] http://chandler.osafoundation.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Sean Timm <ti...@aol.com>.
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?
http://www.oracle.com/database/berkeley-db/je/index.html
-Sean
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Chris Hostetter <ho...@fucit.org>.
:
: 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 that, it seems weird that the call
would be differnet (since my reading of the loadLibrary javadocs is that
the method is suppose to abstract away all of the OS specifics for native
library filenames / locations.
is there perhaps a BDB "static boolean libCanBeLoaded()" method that
could be used so we aren't reinventing a wheel?
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Andi Vajda <va...@osafoundation.org>.
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 -- and if not, echo a big fat
>> wraning anytime anyone attempts to run the test.
>
> Yep.
>
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)
If the call succeeds, then the tests should be run.
The supported versions are 4.3.29 and 4.4.20 (set with a property in the bdb
contrib build.xml).
Therefore libs like libdb_java43.dll on Windows or libdb_java-4.4.so on Unix
should be present. Note that the lib file extension is omitted with the
loadLibrary call.
Andi..
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Andi Vajda <va...@osafoundation.org>.
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 fine isn't relaly a good policy, since
> releases may be on a patch branch with no nightly build.
>
> From a unit testing purist standpoint, the unit tests for contrib/db/bdb
> wouldn't require the native lib at all -- they would use a mock API to
> simyulate the real API so that there were no dependencies (native or
> otherwise) ... other "integration tests" could be optional and require the
> ral native lib to run successfully.
>
> I have no idea how hard it would be to mock out the BDB API, but
> personally I'd settle for a clean way to gracefully skip the
> contrib/db/bdb tests if the lib isn't available (much the way the build
> system skips contrib/gdata-server if java 1.5 is not available).
>
> I don't really know enough about JNI however to know how to do this ...
> the best idea i have is to try and catch these exceptions in the test --
> but if we just ignore them then the test stats would give the false
> impression that they passed -- what we really need is a way for ant to
> know that the native lib isn't available, and skip the tests in that case.
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 -- and if not, echo a big fat
> wraning anytime anyone attempts to run the test.
Yep.
Andi..
[1] http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#loadLibrary(java.lang.String)
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Chris Hostetter <ho...@fucit.org>.
: 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 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 fine isn't relaly a good policy, since
releases may be on a patch branch with no nightly build.
>From a unit testing purist standpoint, the unit tests for contrib/db/bdb
wouldn't require the native lib at all -- they would use a mock API to
simyulate the real API so that there were no dependencies (native or
otherwise) ... other "integration tests" could be optional and require the
ral native lib to run successfully.
I have no idea how hard it would be to mock out the BDB API, but
personally I'd settle for a clean way to gracefully skip the
contrib/db/bdb tests if the lib isn't available (much the way the build
system skips contrib/gdata-server if java 1.5 is not available).
I don't really know enough about JNI however to know how to do this ...
the best idea i have is to try and catch these exceptions in the test --
but if we just ignore them then the test stats would give the false
impression that they passed -- what we really need is a way for ant to
know that the native lib isn't available, and skip the tests in that case.
i suppose we could just define bdb test target to only run if some new
"test.contrib.db.bdb" property is set -- and if not, echo a big fat
wraning anytime anyone attempts to run the test.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Andi Vajda <va...@osafoundation.org>.
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
> working (it even runs all tests on all contribs before failing so the
> generate-test-reports task is useful for the whole proejct)
>
> Feedback would be appreciated...
> http://issues.apache.org/jira/browse/LUCENE-885
>
> ...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.
That software is open source and can be downloaded in source form at no cost
by anyone from [1]. Since it's a native library, it would be rather onerous to
have pre-compiled, auto-downloadable, binary versions of this library
available for every platform under the sun.
I do provide a downloadable .jar file for the Java/C interface. That file is
auto-downloaded by the contrib's ant script from an OSAF server [2]. This
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
a C compiler. If the build bot machine(s) is/are Linux, I believe there should
be up to date binary packages for Berkeley DB 4.3.29 or 4.4.20 available for
installation as well.
Andi..
[1] http://www.oracle.com/technology/documentation/berkeley-db/db/index.html
[2] http://downloads.osafoundation.org/db/db-4.4.20.jar
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Chris Hostetter <ho...@fucit.org>.
: +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 before failing so the
generate-test-reports task is useful for the whole proejct)
Feedback would be appreciated...
http://issues.apache.org/jira/browse/LUCENE-885
...the issue of what to do about contrib/db/bdbd's native library
dependencies should definitely be discussed. if anyone would like to
volunteer to fix the other failing contrib tests that would also be
helpful.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Doug Cutting <cu...@apache.org>.
+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 such a policy the present contribs would
> also stay up to date, provided their tests are good enough.
> Thinking about it a bit more, there is a process to add contribs, but there
> is not really a process to remove them. The policy of removing a contrib
> before a release when its unit tests fail could make a nice fit for that.
I think what you're arguing is that, unlike the core, contrib is not
guaranteed to be back-compatible (since removing a module is not a
back-compatible change). Otherwise this is no different than other bugs
and code changes. 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 happen. We shouldn't release with unresolved issues,
whether they involve contrib or core. Does that sound reasonable?
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Paul Elschot <pa...@xs4all.nl>.
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" on a regular basis (ie: in the nightly), test failures
> should not in and of themselves block a release -- so the ReleaseTodo
> doesn't need to include any mention of running tests (I would argue
> against this position very strongly)
>
I'd rather have a few tests too many, which means that I would prefer
to have the contribs tested by default, and at least before a new release.
Contribs depend on the core, and their tests might also indicate a
problem in the core, even though that is not their intention.
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.
Thinking about it a bit more, there is a process to add contribs, but there
is not really a process to remove them. The policy of removing a contrib
before a release when its unit tests fail could make a nice fit for that.
Regards,
Paul Elschot
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Chris Hostetter <ho...@fucit.org>.
: 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 suggested it but i
wasn't sure if people liked the idea of targets they are use to suddenly
getting a lot more complicated.
from a semantic equivilence standpoint, we could also:
1) rename "test" as "test-core"
2) create a new deprecated "test" that just depends on "test-core" (but
has no description so we do't advertise it)
3) create a new "test-all" that depends on "test-core" and "test-contrib"
4) replace all current dependencies on "test" with "test-all"
...but it's probably not really worth it unles someone cares strongly
about "ant test" meaning the same thing it always has.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Doron Cohen <DO...@il.ibm.com>.
Grant Ingersoll <gs...@apache.org> 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 "test-core"
and "test-contrib". That way during developing you can run
"test-core" - that should be quicker. But the nightly and the
policies for "check-in" and "release" remain syntactically
the same, running the (now broader) target "test".
I am not fond of removing a contrib part from the release
because its tests fail - I would like to believe that we
can fix whatever contrib tests are failing before any release.
Doron
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Grant Ingersoll <gs...@apache.org>.
+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
> 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 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" on a regular basis (ie: in the nightly), test
> failures
> should not in and of themselves block a release -- so the ReleaseTodo
> doesn't need to include any mention of running tests (I would argue
> against this position very strongly)
>
> So the question remains, regardless of what build system we have
> now, or
> may choose to have in the future: is the current behavior
> desirable, or do
> we want contrib-tests to be run more often, and do we want to make
> it a
> "policy" that tests should be run when building a release?
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org/tech/lucene.asp
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Chris Hostetter <ho...@fucit.org>.
: 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 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" on a regular basis (ie: in the nightly), test failures
should not in and of themselves block a release -- so the ReleaseTodo
doesn't need to include any mention of running tests (I would argue
against this position very strongly)
So the question remains, regardless of what build system we have now, or
may choose to have in the future: is the current behavior desirable, or do
we want contrib-tests to be run more often, and do we want to make it a
"policy" that tests should be run when building a release?
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Paul Smith <ps...@aconex.com>.
>
> 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 wouldn't have caught this and continuously
nagged you all to get it fixed.. :)
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Grant Ingersoll <gs...@apache.org>.
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), but as soon as you want to get in deeper, it becomes
difficult to figure out w/o digging into the code. Having said that,
I still think it is worthwhile for what we do.
Plus, since Maven is Apache, it has a lot of things built into it for
managing Apache releases, like signing, publishing, etc.
Now, for us, Maven for the core is quite simple and would be real
easy to setup, it is the contribs that will take a little work to get
in place, but still wouldn't be all that difficult.
To answer your question, though, I don't see any reason not to make
the changes to make the current process more repeatable.
-Grant
On May 16, 2007, at 6:07 PM, Paul Smith wrote:
> 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 without careful thought , but might
> be worth considering. I used to be anti-maven, but since version
> 2, and since Curt Arnold has been setting up the log4j build
> environment for maven, I've been quite impressed with it's capability.
>
> cheers,
>
> Paul Smith
>
>
> On 17/05/2007, at 8:02 AM, Chris Hostetter wrote:
>
>>
>> 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
>> noticed that the official 2.1.0 release contained 2 test failures
>> -- one
>> each in the highlighter and spellchecker contribs.
>>
>> The specifics of the test failures don't really interest me as
>> much as the
>> question: how did we manage to have a release with test failures?
>>
>> A few things have jumped out at me while looking into this...
>>
>> 1) the task "build-contrib" can be used to walk the contrib directory
>> building each contrib, the task "test-contrib" can be used to
>> walk the
>> contrib directory testing each contrib.
>> 2) the "test" task only tests the lucene-core ... it does not
>> depend on
>> (or call) "test-contrib"
>> 3) The "nightly" build task depends on the "test" and "package-
>> tgz" task
>> (which depends on "build-contrib") but at no point is "test-
>> contrib"
>> run.
>> 4) The steps for creating an official release...
>> http://wiki.apache.org/lucene-java/ReleaseTodo
>> ...specify using the "dist" and
>> "dist-src" tasks -- neither of which depend on *ANY* tests
>> being run
>> (let alone contrib tests)
>>
>> This seems very strange to me ... i would think that we would want:
>>
>> a) nightly builds to run the tests for all contribs, ala...
>> <target name="nightly" depends="test, build-contrib, test-
>> contrib, package-tgz">
>> b) the release insctructions to make it clear that all unit
>> tests (core
>> and contrib) should be run prior to creating teh distribution.
>>
>>
>> Does anyone see any reason not to make these changes?
>>
>>
>>
>> -Hoss
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
> Paul Smith
> Core Engineering Manager
>
> Aconex
> The easy way to save time and money on your project
>
> 696 Bourke Street, Melbourne,
> VIC 3000, Australia
> Tel: +61 3 9240 0200 Fax: +61 3 9240 0299
> Email: psmith@aconex.com www.aconex.com
>
> This email and any attachments are intended solely for the
> addressee. The contents may be privileged, confidential and/or
> subject to copyright or other applicable law. No confidentiality or
> privilege is lost by an erroneous transmission. If you have
> received this e-mail in error, please let us know by reply e-mail
> and delete or destroy this mail and all copies. If you are not the
> intended recipient of this message you must not disseminate, copy
> or take any action in reliance on it. The sender takes no
> responsibility for the effect of this message upon the recipient's
> computer system.
>
>
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org/tech/lucene.asp
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Tests, Contribs, and Releases
Posted by Paul Smith <ps...@aconex.com>.
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 without careful thought , but might be worth
considering. I used to be anti-maven, but since version 2, and since
Curt Arnold has been setting up the log4j build environment for
maven, I've been quite impressed with it's capability.
cheers,
Paul Smith
On 17/05/2007, at 8:02 AM, Chris Hostetter wrote:
>
> 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
> noticed that the official 2.1.0 release contained 2 test failures
> -- one
> each in the highlighter and spellchecker contribs.
>
> The specifics of the test failures don't really interest me as much
> as the
> question: how did we manage to have a release with test failures?
>
> A few things have jumped out at me while looking into this...
>
> 1) the task "build-contrib" can be used to walk the contrib directory
> building each contrib, the task "test-contrib" can be used to
> walk the
> contrib directory testing each contrib.
> 2) the "test" task only tests the lucene-core ... it does not
> depend on
> (or call) "test-contrib"
> 3) The "nightly" build task depends on the "test" and "package-tgz"
> task
> (which depends on "build-contrib") but at no point is "test-
> contrib"
> run.
> 4) The steps for creating an official release...
> http://wiki.apache.org/lucene-java/ReleaseTodo
> ...specify using the "dist" and
> "dist-src" tasks -- neither of which depend on *ANY* tests being
> run
> (let alone contrib tests)
>
> This seems very strange to me ... i would think that we would want:
>
> a) nightly builds to run the tests for all contribs, ala...
> <target name="nightly" depends="test, build-contrib, test-
> contrib, package-tgz">
> b) the release insctructions to make it clear that all unit tests
> (core
> and contrib) should be run prior to creating teh distribution.
>
>
> Does anyone see any reason not to make these changes?
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
Paul Smith
Core Engineering Manager
Aconex
The easy way to save time and money on your project
696 Bourke Street, Melbourne,
VIC 3000, Australia
Tel: +61 3 9240 0200 Fax: +61 3 9240 0299
Email: psmith@aconex.com www.aconex.com
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to
copyright or other applicable law. No confidentiality or privilege is
lost by an erroneous transmission. If you have received this e-mail
in error, please let us know by reply e-mail and delete or destroy
this mail and all copies. If you are not the intended recipient of
this message you must not disseminate, copy or take any action in
reliance on it. The sender takes no responsibility for the effect of
this message upon the recipient's computer system.