lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4115) JAR resolution/ cleanup should be done automatically for ant clean/ eclipse/ resolve.
Date Fri, 08 Jun 2012 23:11:23 GMT


Hoss Man commented on LUCENE-4115:

bq. I agree with you 100% that we shouldn't be doing any copying or filtering manually –
it has to be the same fileset. 

Right ... that's the crux of my concern.

bq. Note that at the moment this isn't consistent either – if there is a jar dependency
upgrade people are left with unused jars under lib/* and this can (and does) cause headaches
until you realize you need to clean up that folder (which is a reason for this issue, actually).

but our checksum validation warns you of that .. the reason for this issue was not that people
didn't know they had bad jars (the build already told them that) the point was to try and
make dealing with it automatic. 

bq. One thing I didn't know how to work around with direct ivy caches was jar checksums –
I think it is a good idea to keep these but then I don't know how they could be verified if
we use ivy caches directly.

yeah ... the checksum validation is really huge ... we definitely should sacrifice that.


Which leads me to a strawman suggestion: what if instead of making all these ant targets depend
on "ant clean-jars" we add an optional build property that tells the checksum validation code
to try to remove any jar that doesn't have a checksum file?  values for the property could
 * don't try to delete but warn of existence
 * don't try to delete and fail because of existence (current behavior)
 * try to delete, fail if delete fails (new default)
 * try to delete, warn & don't fail if delete fails (new default if windows) the cases where deletion failure is non-fatal, the code could still register a deleteOnExit()
for the files as a fallback (which should work on windows right? by that point windows will
have closed the file handle for the jar?)

if we did that, then (i think) the worst case scenario for windows dev/jenkins users after
ivy config changes would be that the *first* build attempt might fail because of a jar that
couldn't be deleted (because it was in use), but that file should be deleted when the JVM
exists, and after that the build should start working.


> JAR resolution/ cleanup should be done automatically for ant clean/ eclipse/ resolve.
> -------------------------------------------------------------------------------------
>                 Key: LUCENE-4115
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Dawid Weiss
>            Assignee: Dawid Weiss
>            Priority: Trivial
>             Fix For: 4.0, 5.0
>         Attachments: LUCENE-4111.patch, LUCENE-4115.patch
> I think we should add the following target deps:
> ant clean [depends on] clean-jars
> ant resolve [depends on] clean-jars
> ant eclipse [depends on] resolve, clean-jars
> ant idea [depends on] resolve, clean-jars
> This eliminates the need to remember about cleaning up stale jars which users complain
about (and I think they're right about it). The overhead will be minimal since resolve is
only going to copy jars from cache. Eclipse won't have a problem with updated JARs if they
end up at the same location.
> If there are no objections I will fix this in a few hours.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message