Lucene - Core
  1. Lucene - Core
  2. LUCENE-4115

JAR resolution/ cleanup should be done automatically for ant clean/ eclipse/ resolve.

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-BETA, 6.0
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      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.

        Activity

        Hide
        Steve Rowe added a comment -

        +1

        (possibly ant idea too?)

        I think ant idea too should depend on clean-jars resolve, if for no other reason than to immediately fail on attempting to link to stale jars when the idea config is out of sync.

        Show
        Steve Rowe added a comment - +1 (possibly ant idea too?) I think ant idea too should depend on clean-jars resolve, if for no other reason than to immediately fail on attempting to link to stale jars when the idea config is out of sync.
        Hide
        Steve Rowe added a comment -

        ant eclipse [depends on] resolve, clean-jars
        ant idea [depends on] resolve, clean-jars

        Shouldn't the order be clean-jars,resolve ? (Maybe I'm missing something...)

        Show
        Steve Rowe added a comment - ant eclipse [depends on] resolve, clean-jars ant idea [depends on] resolve, clean-jars Shouldn't the order be clean-jars,resolve ? (Maybe I'm missing something...)
        Hide
        Dawid Weiss added a comment -

        This doesn't matter, it'll sort topologically anyway (if resolve depends on clean-jars). But you're right – I was just being intentionally sloppy

        Show
        Dawid Weiss added a comment - This doesn't matter, it'll sort topologically anyway (if resolve depends on clean-jars). But you're right – I was just being intentionally sloppy
        Hide
        Jack Krupansky added a comment -

        The other case I was interested in is if I do "ant clean test", it is smart enough to go and fetch the new jars, but I have to manually do the resolve. And it would be nice if ant eclipse was triggered in that case as well. In other words, anything that caused jars to be updated should do resolve and eclipse.

        Show
        Jack Krupansky added a comment - The other case I was interested in is if I do "ant clean test", it is smart enough to go and fetch the new jars, but I have to manually do the resolve. And it would be nice if ant eclipse was triggered in that case as well. In other words, anything that caused jars to be updated should do resolve and eclipse.
        Hide
        Steve Rowe added a comment -

        In other words, anything that caused jars to be updated should do resolve and eclipse.

        -1

        ant eclipse, ant idea, etc. should never be called by the standard build.

        Why? I don't use eclipse. I don't want it cluttering my build dir/slowing down my build.
        (Your version: "I don't use IntelliJ. I don't want it cluttering my build dir/slowing down my build.")

        Show
        Steve Rowe added a comment - In other words, anything that caused jars to be updated should do resolve and eclipse. -1 ant eclipse, ant idea, etc. should never be called by the standard build. Why? I don't use eclipse. I don't want it cluttering my build dir/slowing down my build. (Your version: "I don't use IntelliJ. I don't want it cluttering my build dir/slowing down my build.")
        Hide
        Dawid Weiss added a comment -

        If you invoke 'ant clean test' this will fetch new jars after this patch. It will not prepare any IDE settings (because of what Steve mentioned).

        Show
        Dawid Weiss added a comment - If you invoke 'ant clean test' this will fetch new jars after this patch. It will not prepare any IDE settings (because of what Steve mentioned).
        Hide
        Jack Krupansky added a comment -

        Sounds good. Just to be sure I followed it all, if I do "ant clean eclipse test" after "svn co", all of the jar processing should happen as desired.

        Show
        Jack Krupansky added a comment - Sounds good. Just to be sure I followed it all, if I do "ant clean eclipse test" after "svn co", all of the jar processing should happen as desired.
        Hide
        Dawid Weiss added a comment -

        Yep (and you only need to call ant eclipse if the JARs change; you'll see when they change because Eclipse won't be able to find the required library JARs and will show a configuration/ build error).

        Show
        Dawid Weiss added a comment - Yep (and you only need to call ant eclipse if the JARs change; you'll see when they change because Eclipse won't be able to find the required library JARs and will show a configuration/ build error).
        Hide
        Dawid Weiss added a comment -

        Suggested patch. Note jar resync in 'ant resolve' for any submodule. This is intentional and will prevent stale jars even if somebody works on a submodule only.

        Show
        Dawid Weiss added a comment - Suggested patch. Note jar resync in 'ant resolve' for any submodule. This is intentional and will prevent stale jars even if somebody works on a submodule only.
        Hide
        Mark Miller added a comment -

        Looks like Windows does not like this one.

        BUILD FAILED
        C:\Jenkins\workspace\Lucene-Solr-4.x-Windows-Java7-64\build.xml:29: The following error occurred while executing this line:
        C:\Jenkins\workspace\Lucene-Solr-4.x-Windows-Java7-64\lucene\build.xml:448: The following error occurred while executing this line:
        C:\Jenkins\workspace\Lucene-Solr-4.x-Windows-Java7-64\lucene\common-build.xml:618: The following error occurred while executing this line:
        C:\Jenkins\workspace\Lucene-Solr-4.x-Windows-Java7-64\lucene\common-build.xml:286: Unable to delete file C:\Jenkins\workspace\Lucene-Solr-4.x-Windows-Java7-64\lucene\test-framework\lib\junit4-ant-1.5.0.jar

        Show
        Mark Miller added a comment - Looks like Windows does not like this one. BUILD FAILED C:\Jenkins\workspace\Lucene-Solr-4.x-Windows-Java7-64\build.xml:29: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-4.x-Windows-Java7-64\lucene\build.xml:448: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-4.x-Windows-Java7-64\lucene\common-build.xml:618: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-4.x-Windows-Java7-64\lucene\common-build.xml:286: Unable to delete file C:\Jenkins\workspace\Lucene-Solr-4.x-Windows-Java7-64\lucene\test-framework\lib\junit4-ant-1.5.0.jar
        Hide
        Dawid Weiss added a comment -

        Can you check what's causing the JAR file to be locked?

        • what target did you issue (it can be that ant's own url class loader holds a lock)?
        • was Eclipse/IntelliJ running in the background?
        • was there any executing test/ other class in the background (these would all hold a lock)?

        We can always add failonerror=false to delete but not able to delete that jar signals a problem and it'd be nice to know where it comes from.

        Show
        Dawid Weiss added a comment - Can you check what's causing the JAR file to be locked? what target did you issue (it can be that ant's own url class loader holds a lock)? was Eclipse/IntelliJ running in the background? was there any executing test/ other class in the background (these would all hold a lock)? We can always add failonerror=false to delete but not able to delete that jar signals a problem and it'd be nice to know where it comes from.
        Hide
        Robert Muir added a comment -

        This is creating a lot of noise. Can we back it out until there is a solution that works on windows?

        Show
        Robert Muir added a comment - This is creating a lot of noise. Can we back it out until there is a solution that works on windows?
        Hide
        Dawid Weiss added a comment -

        Sorry – I'm on mobile and couldn't check properly (didn't know it fails on jenkins). Robert will revert this commit and I'll see what the problem is tomorrow. Quite likely a class loader holds a lock on a jar file. I don't know why yet.

        Show
        Dawid Weiss added a comment - Sorry – I'm on mobile and couldn't check properly (didn't know it fails on jenkins). Robert will revert this commit and I'll see what the problem is tomorrow. Quite likely a class loader holds a lock on a jar file. I don't know why yet.
        Hide
        Mark Miller added a comment -

        what target did you issue

        I'm getting this from Uwe's jenkins emails to the devs list rather than my own machine. I don't think there is any IDE involved there.

        A quick test in my vm shows it happening at the end of running ant test though.

        Show
        Mark Miller added a comment - what target did you issue I'm getting this from Uwe's jenkins emails to the devs list rather than my own machine. I don't think there is any IDE involved there. A quick test in my vm shows it happening at the end of running ant test though.
        Hide
        Dawid Weiss added a comment -

        Yeah, sorry Mark – didn't check it thoroughly, I'm on mobile.

        Show
        Dawid Weiss added a comment - Yeah, sorry Mark – didn't check it thoroughly, I'm on mobile.
        Hide
        Robert Muir added a comment -

        Another possibility (didnt investigate if it has options that would work for us) is the sync=true option for retrieve:

        http://ant.apache.org/ivy/history/trunk/use/retrieve.html

        Just at a glance there could be some problems: sha1/license/notice files, and solr/lib which is 'shared' across solrj and core dependencies.

        But maybe we could still utilize this...

        Show
        Robert Muir added a comment - Another possibility (didnt investigate if it has options that would work for us) is the sync=true option for retrieve: http://ant.apache.org/ivy/history/trunk/use/retrieve.html Just at a glance there could be some problems: sha1/license/notice files, and solr/lib which is 'shared' across solrj and core dependencies. But maybe we could still utilize this...
        Hide
        Dawid Weiss added a comment -

        I've checked that – sync on retrieve deletes everything from a folder (there is no exclusion pattern to be applied). Besides it won't solve the locking problem on windows (assuming something keeps a lock on a jar to be deleted it'd fail anyway).

        A true nice solution would be to revisit the issue where classpaths are constructed to ivy cache directly (they're always correct then) and just use copying for packaging.

        Show
        Dawid Weiss added a comment - I've checked that – sync on retrieve deletes everything from a folder (there is no exclusion pattern to be applied). Besides it won't solve the locking problem on windows (assuming something keeps a lock on a jar to be deleted it'd fail anyway). A true nice solution would be to revisit the issue where classpaths are constructed to ivy cache directly (they're always correct then) and just use copying for packaging.
        Hide
        Hoss Man added a comment -

        A true nice solution would be to revisit the issue where classpaths are constructed to ivy cache directly (they're always correct then) and just use copying for packaging.

        seems like that might introduce some risk of the classpath(s) used by developers/jenkins for running tests deviating from the ones people would get if they use the binary distributions (particularly solr users who don't know/understand java classpaths and just copy the example & lib dirs as a starting point).

        Show
        Hoss Man added a comment - A true nice solution would be to revisit the issue where classpaths are constructed to ivy cache directly (they're always correct then) and just use copying for packaging. seems like that might introduce some risk of the classpath(s) used by developers/jenkins for running tests deviating from the ones people would get if they use the binary distributions (particularly solr users who don't know/understand java classpaths and just copy the example & lib dirs as a starting point).
        Hide
        Dawid Weiss added a comment -

        Why would this be so? I mean – the risk of users messing up their classpath with lib/*.jar is pretty much the same compared to an ivy classpath from cache + ivy classpath from cache copied to lib/ at distribution time?

        Show
        Dawid Weiss added a comment - Why would this be so? I mean – the risk of users messing up their classpath with lib/*.jar is pretty much the same compared to an ivy classpath from cache + ivy classpath from cache copied to lib/ at distribution time?
        Hide
        Hoss Man added a comment -

        I'm not sure i'm following you.

        right now, we know that when you run "ant test" (or "java -jar start.jar" in solr) you getting the exact same classpath and set of jars as someone who downloads a binary dist you might build from your checkout – because the classpath you are using comes from the lib dirs, built by ivy. there is only one places jars are "copied" from the ivy cache to the lib dir(s).

        if instead we have ant <classpath/> declarations that use ivy features to build up classpaths pointed directly at jars in the ivy cache, and independently we have <copy> directives building up the lib/ dirs that make it into the binary dists, then isn't there a risk that (overtime) those will diverge in a way we might not notice because all the testing will only be done with the ivy generated classpaths?

        (maybe i'm wrong ... maybe the ivy classpath stuff works diff then i understand ... i'm just raising it as a potential concern)

        Show
        Hoss Man added a comment - I'm not sure i'm following you. right now, we know that when you run "ant test" (or "java -jar start.jar" in solr) you getting the exact same classpath and set of jars as someone who downloads a binary dist you might build from your checkout – because the classpath you are using comes from the lib dirs, built by ivy. there is only one places jars are "copied" from the ivy cache to the lib dir(s). if instead we have ant <classpath/> declarations that use ivy features to build up classpaths pointed directly at jars in the ivy cache, and independently we have <copy> directives building up the lib/ dirs that make it into the binary dists, then isn't there a risk that (overtime) those will diverge in a way we might not notice because all the testing will only be done with the ivy generated classpaths? (maybe i'm wrong ... maybe the ivy classpath stuff works diff then i understand ... i'm just raising it as a potential concern)
        Hide
        Dawid Weiss added a comment -

        I know why the jars are locked - it's because junit4-ant* is taskdef'ed from ant and url jar loader will keep it open. Makes sense. A workaround is to ignore failed deletes (I don't see a cleaner solution other than the one mentioned above – construct the classpath from ivy cache directly).

        I'll post a patch but I'm away most of the time until Sunday so if somebody is willing to commit and monitor jenkins for sanity – feel free to do so.

        Show
        Dawid Weiss added a comment - I know why the jars are locked - it's because junit4-ant* is taskdef'ed from ant and url jar loader will keep it open. Makes sense. A workaround is to ignore failed deletes (I don't see a cleaner solution other than the one mentioned above – construct the classpath from ivy cache directly). I'll post a patch but I'm away most of the time until Sunday so if somebody is willing to commit and monitor jenkins for sanity – feel free to do so.
        Hide
        Dawid Weiss added a comment -

        Corrected patch, checked the build on windows, didn't fail for me.

        Show
        Dawid Weiss added a comment - Corrected patch, checked the build on windows, didn't fail for me.
        Hide
        Dawid Weiss added a comment -

        Hoss – I've been doing some experiments with ivy (and I know very little about it) but it seems that you can use ivy to build both <path> elements and <fileset> elements from the same configuration. This means you would construct an identical path for any java invocation/ taskdef, etc. and a fileset for <copy> to lib/.

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

        http://ant.apache.org/ivy/history/trunk/use/cachepath.html
        http://ant.apache.org/ivy/history/trunk/use/cachefileset.html

        We could even use the fileset only and just put it under a custom <path id="..."> element.

        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).

        Show
        Dawid Weiss added a comment - Hoss – I've been doing some experiments with ivy (and I know very little about it) but it seems that you can use ivy to build both <path> elements and <fileset> elements from the same configuration. This means you would construct an identical path for any java invocation/ taskdef, etc. and a fileset for <copy> to lib/. I agree with you 100% that we shouldn't be doing any copying or filtering manually – it has to be the same fileset. http://ant.apache.org/ivy/history/trunk/use/cachepath.html http://ant.apache.org/ivy/history/trunk/use/cachefileset.html We could even use the fileset only and just put it under a custom <path id="..."> element. 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).
        Hide
        Dawid Weiss added a comment -

        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.

        Show
        Dawid Weiss added a comment - 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.
        Hide
        Hoss Man added a comment -

        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.

        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.

        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 indicate:

        • 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)
          ...in 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.

        right?

        Show
        Hoss Man added a comment - 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. 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. 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 indicate: 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) ...in 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. right?
        Hide
        Uwe Schindler added a comment -

        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.

        You can get the ivy:cachefileset and iterate it using a hand-written <script> task or similar?

        Show
        Uwe Schindler added a comment - 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. You can get the ivy:cachefileset and iterate it using a hand-written <script> task or similar?
        Hide
        Uwe Schindler added a comment - - edited

        I know why the jars are locked - it's because junit4-ant* is taskdef'ed from ant and url jar loader will keep it open. Makes sense. A workaround is to ignore failed deletes (I don't see a cleaner solution other than the one mentioned above – construct the classpath from ivy cache directly).

        I thought all taskdefs are using ivy:cachepath? I changed (or I hope to have changed) at least all those everywhere. Everything ANT needs to build with custom tasks should come from ivy directly. Those JARs never need to be in any binary distribution.

        Show
        Uwe Schindler added a comment - - edited I know why the jars are locked - it's because junit4-ant* is taskdef'ed from ant and url jar loader will keep it open. Makes sense. A workaround is to ignore failed deletes (I don't see a cleaner solution other than the one mentioned above – construct the classpath from ivy cache directly). I thought all taskdefs are using ivy:cachepath? I changed (or I hope to have changed) at least all those everywhere. Everything ANT needs to build with custom tasks should come from ivy directly. Those JARs never need to be in any binary distribution.
        Hide
        Uwe Schindler added a comment -

        For examples see classpath of generate-webpage, cpp-tasks,... Those are all tasks I created during the migration.

        Show
        Uwe Schindler added a comment - For examples see classpath of generate-webpage, cpp-tasks,... Those are all tasks I created during the migration.
        Hide
        Dawid Weiss added a comment -

        Good point, Uwe – the problematic jars are junit4 and randomized runner – these are required for tests though... so I think it's in the gray area somewhere because they will need to be distributed (if tests are distributed) and at the same time they could be loaded from ivy cache?

        What's your opinion on this?

        Show
        Dawid Weiss added a comment - Good point, Uwe – the problematic jars are junit4 and randomized runner – these are required for tests though... so I think it's in the gray area somewhere because they will need to be distributed (if tests are distributed) and at the same time they could be loaded from ivy cache? What's your opinion on this?
        Hide
        Robert Muir added a comment -

        I'm not sure we should really go to the trouble for this issue.

        why can't developers just 'ant clean-jars' after they svn update? Really we are just talking about committers etc tracking development branches here: they should be subscribed to the commits@ list and watching what is happening. Jar upgrades should be no surprise.

        The problem with doing all this automagic stuff is it makes things too automagic: what if i just want to plop in a jar today to test it before dealing with maven etc? This works completely fine today: but if we start rm'ing jars in 'resolve' then this becomes impossible.

        if anything gets done on this issue, then personally i want it triggered by a property that is completely defaulted to 'off'. If you want it on, put it in your ~/build.properties etc.

        Show
        Robert Muir added a comment - I'm not sure we should really go to the trouble for this issue. why can't developers just 'ant clean-jars' after they svn update? Really we are just talking about committers etc tracking development branches here: they should be subscribed to the commits@ list and watching what is happening. Jar upgrades should be no surprise. The problem with doing all this automagic stuff is it makes things too automagic: what if i just want to plop in a jar today to test it before dealing with maven etc? This works completely fine today: but if we start rm'ing jars in 'resolve' then this becomes impossible. if anything gets done on this issue, then personally i want it triggered by a property that is completely defaulted to 'off'. If you want it on, put it in your ~/build.properties etc.
        Hide
        Dawid Weiss added a comment -

        I don't agree – the current situation in which you need to remember about cleaning up jars and resolving again is confusing. It should be syncing automatically with respect to the contents of ivy files. If you need a temporary jar, oh well, modify the ivy file. Given the tradeoff between the two situations I'm opting for having an automagic sync that the need to remember to do cleanups manually every time.

        Currently we 'ant resolve' on ant test anyway so it's half-way to full syncing to me.

        A middle ground would be to have ant clean/eclipse/idea resync everything and 'ant test' and 'ant resolve' not do anything special, but like I said – I think it should be consistent with ivy files. For better or worse, that's the reason we have them – to specify dependencies.

        Show
        Dawid Weiss added a comment - I don't agree – the current situation in which you need to remember about cleaning up jars and resolving again is confusing. It should be syncing automatically with respect to the contents of ivy files. If you need a temporary jar, oh well, modify the ivy file. Given the tradeoff between the two situations I'm opting for having an automagic sync that the need to remember to do cleanups manually every time. Currently we 'ant resolve' on ant test anyway so it's half-way to full syncing to me. A middle ground would be to have ant clean/eclipse/idea resync everything and 'ant test' and 'ant resolve' not do anything special, but like I said – I think it should be consistent with ivy files. For better or worse, that's the reason we have them – to specify dependencies.
        Hide
        Robert Muir added a comment -

        For better or worse, that's the reason we have them – to specify dependencies.

        Not exactly true. in the current build, what is in lib/ specifies the dependencies.

        ivy files are just being used as jar-downloaders.

        Show
        Robert Muir added a comment - For better or worse, that's the reason we have them – to specify dependencies. Not exactly true. in the current build, what is in lib/ specifies the dependencies. ivy files are just being used as jar-downloaders.
        Hide
        Dawid Weiss added a comment -

        Hmm... I don't think the use of ivy should stop at being just a jar-downloader. I have mixed feelings about transitive dependency management (this applies to both ivy and maven) so I'm not suggesting we jump into it full time, but the current build system would really benefit (time and I/O wise) if we used direct ivy cache references instead of copying jars to lib/ folders. And I don't share your concerns about it – I don't think it makes things more complicated or more magical.

        Show
        Dawid Weiss added a comment - Hmm... I don't think the use of ivy should stop at being just a jar-downloader. I have mixed feelings about transitive dependency management (this applies to both ivy and maven) so I'm not suggesting we jump into it full time, but the current build system would really benefit (time and I/O wise) if we used direct ivy cache references instead of copying jars to lib/ folders. And I don't share your concerns about it – I don't think it makes things more complicated or more magical.
        Hide
        Dawid Weiss added a comment -

        A new version of this patch that doesn't attempt to delete *.jar files on per-module resolve (does it from the top-level resolve once).

        JUnit4 dependency is picked from ivy cache now. There is no redundancy as the same ivy module config is used and this will prevent jar locking.

        Show
        Dawid Weiss added a comment - A new version of this patch that doesn't attempt to delete *.jar files on per-module resolve (does it from the top-level resolve once). JUnit4 dependency is picked from ivy cache now. There is no redundancy as the same ivy module config is used and this will prevent jar locking.
        Hide
        Dawid Weiss added a comment -

        I've committed this one in (checked on Windows and Linux, doesn't seem to be causing any problems anymore).

        It isn't ideal but better than what's currently in.

        Show
        Dawid Weiss added a comment - I've committed this one in (checked on Windows and Linux, doesn't seem to be causing any problems anymore). It isn't ideal but better than what's currently in.
        Hide
        Hoss Man added a comment -

        hoss20120711-manual-post-40alpha-change

        Show
        Hoss Man added a comment - hoss20120711-manual-post-40alpha-change

          People

          • Assignee:
            Dawid Weiss
            Reporter:
            Dawid Weiss
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development