[
https://issues.apache.org/jira/browse/LUCENE-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2333:
----------------------------------
Attachment: shai-compile-fix2.patch
shai-compile-fix.patch
Here 2 patches:
*The first one only changes the following:*
It now does not do any "short-circuit" checks for the core.jar available,
instead solely uses a property that is set by the parent.
This works good, now always when you compile a contrib solely (inside its
folder), the core is compiled. If you run from top-level build.xml the
top-level build compiles the core as dependency and passes the "core.compiled"
property down to the contrib-crawl.
In contrib are still other short-circuits like this. E.g. The benchmark contrib
checks, if the jar files of other contribs it depends on are available and only
if not recompiles. This leads to the same problem is you change one of the
depends-on contribs source code. In this case there is no way around a
top-level clean, sorry.
*The second patch improves more:*
It removes the dependency to build the jar file of lucene, it simply uses the
classes/java folder. It needed some more refactoring, to get rid of the
${lucene.jar} property. In contrib-build.xml now a separate base.classpath ref
is defined that can be used everywhere to extend the default classpath, also
set by contrib-build.xml.
The patch also contains a refactoring of contrib-ant, to use a resources-folder
like other contribs. To get contrib-ant jar file compile correctly, do the
folldoing svn commands inside contrib/ant:
{noformat}
svn mkdir src/resources/org/apache/lucene/ant/
svn move src/java/org/apache/lucene/ant/antlib.xml \
src/resources/org/apache/lucene/ant/antlib.xml
{noformat}
> Failures during contrib builds, when classes in core were changed without ant
> clean
> -----------------------------------------------------------------------------------
>
> Key: LUCENE-2333
> URL: https://issues.apache.org/jira/browse/LUCENE-2333
> Project: Lucene - Java
> Issue Type: Bug
> Components: Build
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1
>
> Attachments: shai-compile-fix.patch, shai-compile-fix2.patch
>
>
> From java-dev by Shai Erera:
> {quote}
> I've noticed that sometimes, after I run test-core and test-contrib, and then
> change core code, test-contrib fail on NoSuchMethodError and stuff like that.
> I've noticed that core.jar exists under build, and I assumed it's used by
> test-contrib, and probably is not recreated after core code has changed.
> I verified it when looking in contrib-build.xml, which defines a property
> lucene.jar.present which is set to true if the jar is ... well, present.
> Which I believe is the reason for these failures. I've been thinking how to
> resolve that, and I can think of two ways:
> (1) have test-core always delete that file, but that has two issues:
> (1.1) It's redundant if the code hasn't changed.
> (1.2) It forces you to either jar-core or test-core before you test-contrib,
> if you want to make sure you run w/ the latest jar.
> or
> (2) have test-contrib always call jar-core, which will first delete the file
> and then re-create it by compiling first. Compiling should not do anything if
> the code hasn't changed. So the only waste would be to create the .jar, but I
> think that's quite fast?
> Does anyone, with more Ant skills than me, know of a better way to detect
> from test-contrib that core code has changed and only then rebuild the jar?
> {quote}
--
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
