lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2333) Failures during contrib builds, when classes in core were changed without ant clean
Date Fri, 19 Mar 2010 16:20:27 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847418#action_12847418
] 

Uwe Schindler commented on LUCENE-2333:
---------------------------------------

bq. So I guess you'd compare the .jar date and the build/classes/java date

For between-contrib-relationships: The central element is a macro in contrib-build.xml called
<contrib-uptodate>. It tests, if the specified contrib's jar-file is newer than any
source file and sets a property.

And the original change is that the contrib builds no longer use the jar file of core at all
(see shai2-patch).

> 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: LUCENE-2333.patch, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message