Lucene - Core
  1. Lucene - Core
  2. LUCENE-3961

don't build and rebuild jar files for dependencies in tests

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 4.9, 5.0
    • Component/s: general/build
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Hossman's comments about when jars are built had me thinking,
      its not really great how dependencies are managed currently.

      say i have contrib/hamburger that depends on contrib/cheese

      if I do 'ant test' in contrib/hamburger, you end out with a situation
      where you have no hamburger.jar but you have a cheese.jar.

      The reason for this: i think is how we implement the contrib-uptodate,
      via .jar files. I think instead contrib-uptodate shouldnt use actual
      jar files (cheese.jar) but a simple file we 'touch' like cheese.compiled.

      This will make the build faster, especially I think the solr tests
      which uses these dependencies across a lot of lucene modules. we won't
      constantly jar their stuff.

        Activity

        Hide
        Hoss Man added a comment -

        I don't have a strong opinion about this, but there are two counter arguments i've heard from over the years made in favor of always building the jar(s) even though it's a bit slower for the tests...

        1) it mean you always test against hte same jars that you ship – so there is no risk that the classpath you build for testing is subtly different then the files that make it into the jar (ie: maybe contrib/cheeseburger/build.xml copies a cheese_types.xml file into it's classes dir, but it accidentally gets excluded from contrib-cheeses.jar

        2) it means less risk that someone accidentally uses an older jar then they thing...

        a) "ant something" ... builds contrib-hamburger.jar and contrib-cheese.jar
        b) you realize it doesn't work the way you want, so you apply a patch (with tests!)
        c) "ant test" rebuilds contrib/*/classes and you see your new hamburger test passes
        d) you copy contrib-hamburger.jar and contrib-cheese.jar not realizing they are still left over from #a above, and don't have your patch.

        Show
        Hoss Man added a comment - I don't have a strong opinion about this, but there are two counter arguments i've heard from over the years made in favor of always building the jar(s) even though it's a bit slower for the tests... 1) it mean you always test against hte same jars that you ship – so there is no risk that the classpath you build for testing is subtly different then the files that make it into the jar (ie: maybe contrib/cheeseburger/build.xml copies a cheese_types.xml file into it's classes dir, but it accidentally gets excluded from contrib-cheeses.jar 2) it means less risk that someone accidentally uses an older jar then they thing... a) "ant something" ... builds contrib-hamburger.jar and contrib-cheese.jar b) you realize it doesn't work the way you want, so you apply a patch (with tests!) c) "ant test" rebuilds contrib/*/classes and you see your new hamburger test passes d) you copy contrib-hamburger.jar and contrib-cheese.jar not realizing they are still left over from #a above, and don't have your patch.
        Hide
        Robert Muir added a comment -

        Hossman: I don't understand your #2: We currently don't generally use jars
        as the actual classpath for testing though, and i strongly disagree that
        we should. This really REALLY REALLY slow things down.

        we might build them in module/contrib-uptodate, but its just because they
        are a file with a timestamp. Touch is a much faster way to make a file with
        a timestamp.

        by never creating a jar in the first place your #2 doesn't happen at all really.
        in fact i think whatever we put in build/ is "private" implementation details
        of our build. If someone wants to rebuild jar files they should be running
        the packaging tasks and getting them from dist/

        Show
        Robert Muir added a comment - Hossman: I don't understand your #2: We currently don't generally use jars as the actual classpath for testing though, and i strongly disagree that we should. This really REALLY REALLY slow things down. we might build them in module/contrib-uptodate, but its just because they are a file with a timestamp. Touch is a much faster way to make a file with a timestamp. by never creating a jar in the first place your #2 doesn't happen at all really. in fact i think whatever we put in build/ is "private" implementation details of our build. If someone wants to rebuild jar files they should be running the packaging tasks and getting them from dist/
        Hide
        Robert Muir added a comment -

        Also, if we were to go with your logic, really we should be rebuilding the solr.war everytime
        we run 'ant test' too.

        (I'm just pointing out why i think its infeasible).

        I think we need to keep this stuff fast so that compile-test-debug lifecycle is as fast as possible,
        especially stuff like ant test -Dtestcase

        Show
        Robert Muir added a comment - Also, if we were to go with your logic, really we should be rebuilding the solr.war everytime we run 'ant test' too. (I'm just pointing out why i think its infeasible). I think we need to keep this stuff fast so that compile-test-debug lifecycle is as fast as possible, especially stuff like ant test -Dtestcase
        Hide
        Robert Muir added a comment -

        a) "ant something" ... builds contrib-hamburger.jar and contrib-cheese.jar
        b) you realize it doesn't work the way you want, so you apply a patch (with tests!)
        c) "ant test" rebuilds contrib/*/classes and you see your new hamburger test passes
        d) you copy contrib-hamburger.jar and contrib-cheese.jar not realizing they are still left over from #a above, and don't have your patch.

        This also fails if your patch actually fixes contrib-cheese.

        Going with this logic, any time i run ant test -Dtestcase in lucene, i should rebuild the entirety
        of lucene/solr, because this poor user might have out of date jars

        Show
        Robert Muir added a comment - a) "ant something" ... builds contrib-hamburger.jar and contrib-cheese.jar b) you realize it doesn't work the way you want, so you apply a patch (with tests!) c) "ant test" rebuilds contrib/*/classes and you see your new hamburger test passes d) you copy contrib-hamburger.jar and contrib-cheese.jar not realizing they are still left over from #a above, and don't have your patch. This also fails if your patch actually fixes contrib-cheese. Going with this logic, any time i run ant test -Dtestcase in lucene, i should rebuild the entirety of lucene/solr, because this poor user might have out of date jars
        Hide
        Hoss Man added a comment -

        We currently don't generally use jars as the actual classpath for testing though

        understood, #1 is just an argument i've seen as to why it would be better to do so – otherwise we never actually know when testing that our jars are useful – someone could accidentally put "excludes="*.class" on a jar task and you'd never notice because all the tests would still pass.

        by never creating a jar in the first place your #2 doesn't happen at all really.

        note step #a ... the point is if someone does whatever officially blessed step there is to build the jars ("ant", "ant jar", "ant whatever") and then decides they want to change the behavior of those jars – they may never run "ant clean" and it may not occur to then to re-run whatever that official way to build jars is and they may not notice that the jar's aren't rebuilt when they do "ant test" – because they can already see the new code was "compiled" and running based on the test output.

        Also, if we were to go with your logic, really we should be rebuilding the solr.war everytime

        correct, a war is just a jar with a special structure

        (I'm just pointing out why i think its infeasible). ... I think we need to keep this stuff fast so that compile-test-debug lifecycle is as fast as possible

        agreed ... like i said, i don't have a strong opinion about it, but since we're discussing it i just wanted to point out the arguments i've heard over and over when having this discussion in the past on other projects.

        I think in an ideal world, devs could run fast tests against ../*/classes/ directories, but jenkins would run all those same tests against fully build jars to ensure they aren't missing anything ... but that would probably be an anoying build.xml to maintain

        Show
        Hoss Man added a comment - We currently don't generally use jars as the actual classpath for testing though understood, #1 is just an argument i've seen as to why it would be better to do so – otherwise we never actually know when testing that our jars are useful – someone could accidentally put "excludes="*.class" on a jar task and you'd never notice because all the tests would still pass. by never creating a jar in the first place your #2 doesn't happen at all really. note step #a ... the point is if someone does whatever officially blessed step there is to build the jars ("ant", "ant jar", "ant whatever") and then decides they want to change the behavior of those jars – they may never run "ant clean" and it may not occur to then to re-run whatever that official way to build jars is and they may not notice that the jar's aren't rebuilt when they do "ant test" – because they can already see the new code was "compiled" and running based on the test output. Also, if we were to go with your logic, really we should be rebuilding the solr.war everytime correct, a war is just a jar with a special structure (I'm just pointing out why i think its infeasible). ... I think we need to keep this stuff fast so that compile-test-debug lifecycle is as fast as possible agreed ... like i said, i don't have a strong opinion about it, but since we're discussing it i just wanted to point out the arguments i've heard over and over when having this discussion in the past on other projects. I think in an ideal world, devs could run fast tests against ../*/classes/ directories, but jenkins would run all those same tests against fully build jars to ensure they aren't missing anything ... but that would probably be an anoying build.xml to maintain
        Hide
        Robert Muir added a comment -

        I think in an ideal world, devs could run fast tests against ../*/classes/ directories, but jenkins would run all those same tests against fully build jars to ensure they aren't missing anything ... but that would probably be an anoying build.xml to maintain

        I agree with that, but maybe in the future we could do it without it being so troublesome...

        Show
        Robert Muir added a comment - I think in an ideal world, devs could run fast tests against ../*/classes/ directories, but jenkins would run all those same tests against fully build jars to ensure they aren't missing anything ... but that would probably be an anoying build.xml to maintain I agree with that, but maybe in the future we could do it without it being so troublesome...
        Hide
        Steve Rowe added a comment -

        Bulk move 4.4 issues to 4.5 and 5.0

        Show
        Steve Rowe added a comment - Bulk move 4.4 issues to 4.5 and 5.0
        Hide
        Uwe Schindler added a comment -

        Move issue to Lucene 4.9.

        Show
        Uwe Schindler added a comment - Move issue to Lucene 4.9.

          People

          • Assignee:
            Unassigned
            Reporter:
            Robert Muir
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development