Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.0.2
    • Fix Version/s: 3.1, 3.2, 4.0-ALPHA
    • Component/s: general/build
    • Labels:
      None
    • Lucene Fields:
      New, Patch Available

      Description

      The test classes are useful for writing unit tests for code external to the Lucene project. It would be helpful to build a jar of these classes and publish them as a maven dependency.

      1. LUCENE-2609-naming-fixes.patch
        22 kB
        Steve Rowe
      2. LUCENE-2609-naming-fixes.patch
        22 kB
        Steve Rowe
      3. LUCENE-2609.patch
        2 kB
        Drew Farris
      4. LUCENE-2609.patch
        2 kB
        Drew Farris
      5. LUCENE-2609.patch
        3 kB
        Shai Erera
      6. LUCENE-2609.patch
        176 kB
        Shai Erera
      7. LUCENE-2609.patch
        6 kB
        Shai Erera
      8. LUCENE-2609.patch
        13 kB
        Shai Erera
      9. LUCENE-2609.patch
        17 kB
        Shai Erera
      10. LUCENE-2609.patch
        17 kB
        Shai Erera
      11. LUCENE-2609.patch
        17 kB
        Shai Erera
      12. LUCENE-2609.patch
        42 kB
        Steve Rowe

        Issue Links

          Activity

          Hide
          Grant Ingersoll added a comment -

          Bulk close for 3.1

          Show
          Grant Ingersoll added a comment - Bulk close for 3.1
          Hide
          Steve Rowe added a comment -

          Committed:

          • r1085499: lucene_solr_3_1
          • r1085558: branch_3x
          • r1085581: trunk
          Show
          Steve Rowe added a comment - Committed: r1085499: lucene_solr_3_1 r1085558: branch_3x r1085581: trunk
          Hide
          Steve Rowe added a comment -

          This version of the patch adds an include pattern to lucene/build.xml's binary.build.dist.patterns patternset for the renamed lucene-test-framework-version.jar, so that the test-framework binary and javaodc jars will be included in the binary packages, and adds an exclude pattern so that the test-framework source jar is excluded from the non-Maven binary packages.

          Everything seems to work with this patch.

          Committing shortly.

          Show
          Steve Rowe added a comment - This version of the patch adds an include pattern to lucene/build.xml 's binary.build.dist.patterns patternset for the renamed lucene-test-framework-version.jar , so that the test-framework binary and javaodc jars will be included in the binary packages, and adds an exclude pattern so that the test-framework source jar is excluded from the non-Maven binary packages. Everything seems to work with this patch. Committing shortly.
          Hide
          Steve Rowe added a comment -

          Patch against branches/lucene_solr_3_1 that addresses the naming issues. Testing now - if no problems, I will commit shortly.

          Show
          Steve Rowe added a comment - Patch against branches/lucene_solr_3_1 that addresses the naming issues. Testing now - if no problems, I will commit shortly.
          Hide
          Steve Rowe added a comment - - edited

          The Lucene test-framework jar name should include "test-framework". Also, the test-framework maven artifacts should not have a "tests" classifier (or "test-sources" or "test-javadoc") - rather, they should be named as any other module's non-test artifacts are named: artifactId-version.jar, artifactId-version-javadoc.jar, and artifactId-version-sources.jar.

          Show
          Steve Rowe added a comment - - edited The Lucene test-framework jar name should include "test-framework". Also, the test-framework maven artifacts should not have a "tests" classifier (or "test-sources" or "test-javadoc") - rather, they should be named as any other module's non-test artifacts are named: artifactId-version.jar , artifactId-version-javadoc.jar , and artifactId-version-sources.jar .
          Hide
          Shai Erera added a comment -

          Committed revision 1067738.

          Thanks all for your comments and help !

          Show
          Shai Erera added a comment - Committed revision 1067738. Thanks all for your comments and help !
          Hide
          Shai Erera added a comment -

          Thanks Steven !

          Committed revision 1067623 (3x).

          Merging to trunk now ...

          Show
          Shai Erera added a comment - Thanks Steven ! Committed revision 1067623 (3x). Merging to trunk now ...
          Hide
          Steve Rowe added a comment -

          This patch includes a new POM template for the Lucene test framework. I ran into an issue with circular dependence: Lucene core can't depend on the test framework, because the test framework depends on Lucene core. I solved this problem by including src/test-framework/ in Lucene core's test source directories, so that no dependency is required on the test framework. ant generate-maven-artifacts is also modified to include the binary, source, and javadoc jars for the test framework.

          I tried to make all other modules depend only on the test framework, but several Lucene contrib modules refer to Lucene test classes that were not included in src/test-framework: analyzers/common, icu, misc, queryparser, and remote. For these, I kept the previous dependency on the full Lucene tests jar.

          One other minor change in this patch: the jarify macro now has an optional excludes attribute that defaults to **/pom.xml, so that pom.xml files don't end up in any jars.

          This patch includes all of Shai's patch, as well as a minor addition mentioned by Uwe on IRC: title attributes are included for all test-framework jarify calls. Like Shai's patch, I excluded the moved java files from the patch.

          Show
          Steve Rowe added a comment - This patch includes a new POM template for the Lucene test framework. I ran into an issue with circular dependence: Lucene core can't depend on the test framework, because the test framework depends on Lucene core. I solved this problem by including src/test-framework/ in Lucene core's test source directories, so that no dependency is required on the test framework. ant generate-maven-artifacts is also modified to include the binary, source, and javadoc jars for the test framework. I tried to make all other modules depend only on the test framework, but several Lucene contrib modules refer to Lucene test classes that were not included in src/test-framework : analyzers/common, icu, misc, queryparser, and remote. For these, I kept the previous dependency on the full Lucene tests jar. One other minor change in this patch: the jarify macro now has an optional excludes attribute that defaults to **/pom.xml , so that pom.xml files don't end up in any jars. This patch includes all of Shai's patch, as well as a minor addition mentioned by Uwe on IRC: title attributes are included for all test-framework jarify calls. Like Shai's patch, I excluded the moved java files from the patch.
          Hide
          Shai Erera added a comment -

          Patch fixes the manifest issue Uwe raised. I exposed a title attribute in jarify, which defaults to whatever build-manifest defaults, and is set by jar-test-framework to "Lucene Search Engine: Test Framework".

          Show
          Shai Erera added a comment - Patch fixes the manifest issue Uwe raised. I exposed a title attribute in jarify, which defaults to whatever build-manifest defaults, and is set by jar-test-framework to "Lucene Search Engine: Test Framework".
          Hide
          Uwe Schindler added a comment -

          Hi Shai, patch looks fine (applies only to 3.x with Tortoise, I assume you used 3.x), with something minor not easy to fix: The JAR files' MANIFEST of the test-framework still contain the project name "-core" because <build-manifest> uses the ANT project name. To fix we need to add another parameter to build-manifest which is hairy, so I would leave that out for now.

          I would commit it, I tested almost every combination and my build-release script!

          Nice work!

          Show
          Uwe Schindler added a comment - Hi Shai, patch looks fine (applies only to 3.x with Tortoise, I assume you used 3.x), with something minor not easy to fix: The JAR files' MANIFEST of the test-framework still contain the project name "-core" because <build-manifest> uses the ANT project name. To fix we need to add another parameter to build-manifest which is hairy, so I would leave that out for now. I would commit it, I tested almost every combination and my build-release script! Nice work!
          Hide
          Shai Erera added a comment -

          Last patch had misplaced text outside a target.

          Show
          Shai Erera added a comment - Last patch had misplaced text outside a target.
          Hide
          Shai Erera added a comment -

          Fix some more Ant targets and adds javadocs-test-framework and jar-test-framework-src. Also adds dependencies on both of these.

          Don't forget to run the "svn mv" commands from above and also "svn rm dev-tools/testjar"

          Show
          Shai Erera added a comment - Fix some more Ant targets and adds javadocs-test-framework and jar-test-framework-src. Also adds dependencies on both of these. Don't forget to run the "svn mv" commands from above and also "svn rm dev-tools/testjar"
          Hide
          Uwe Schindler added a comment -

          Hi Shai,
          I will try this out today, also with Clover. In the Clover part of build.xml may some changes needed, as Clover needs to find test source files to create the statistics!

          Show
          Uwe Schindler added a comment - Hi Shai, I will try this out today, also with Clover. In the Clover part of build.xml may some changes needed, as Clover needs to find test source files to create the statistics!
          Hide
          Shai Erera added a comment -

          I plan to commit this sometime today or tomorrow if there are no objections. I will then make the same changes (+ move the extra files) to trunk

          Show
          Shai Erera added a comment - I plan to commit this sometime today or tomorrow if there are no objections. I will then make the same changes (+ move the extra files) to trunk
          Hide
          Shai Erera added a comment -

          Patch fixes Solr build.xmls to depend only on lucene's test-framework, as well as removing dev-tools/testjar.

          Again, I only included the .xml changes in the path - the rest are just svn moves.

          Show
          Shai Erera added a comment - Patch fixes Solr build.xmls to depend only on lucene's test-framework, as well as removing dev-tools/testjar. Again, I only included the .xml changes in the path - the rest are just svn moves.
          Hide
          Shai Erera added a comment -

          I think we should compile test-framework under classes/test as well. It will only simplify the build.xml, and tests have to reference both test and test-framework in their classpath.

          I forgot to modify jar-test-core, but I will do so in my next patch. I will rename to jar-test-framework and remove dev-tools/testjar.

          Show
          Shai Erera added a comment - I think we should compile test-framework under classes/test as well. It will only simplify the build.xml, and tests have to reference both test and test-framework in their classpath. I forgot to modify jar-test-core, but I will do so in my next patch. I will rename to jar-test-framework and remove dev-tools/testjar.
          Hide
          Shai Erera added a comment -

          Previous patch was hard to review IMO. This patch includes the changes to the .xml files only. If you run the 'svn mv' commands I pasted before and then apply this patch, all should work.

          Show
          Shai Erera added a comment - Previous patch was hard to review IMO. This patch includes the changes to the .xml files only. If you run the 'svn mv' commands I pasted before and then apply this patch, all should work.
          Hide
          Shai Erera added a comment -

          Patch includes changes to build.xmls (ignore the other changes, they are caused by svn moves – I didn't touch the source files). I'd appreciate an Ant 'expert' looking at them.

          Since some tests depend on other tests (e.g. through extension) and other classes that are not under test-framework, I couldn't make a test.classpath that references test-framework only. So I modified test.classpath to reference both classes/test and classes/test-framework.

          If you want to apply the patch, make sure to run the following commands:

          svn mkdir lucene/src/test-framework
          svn mv --parents lucene/src/test/org/apache/lucene/util/_TestUtil.java lucene/src/test-framework/org/apache/lucene/util/_TestUtil.java
          svn mv --parents lucene/src/test/org/apache/lucene/util/LineFileDocs.java lucene/src/test-framework/org/apache/lucene/util/LineFileDocs.java
          svn mv --parents lucene/src/test/org/apache/lucene/util/LuceneJUnitDividingSelector.java lucene/src/test-framework/org/apache/lucene/util/LuceneJUnitDividingSelector.java
          svn mv --parents lucene/src/test/org/apache/lucene/util/LuceneJUnitResultFormatter.java lucene/src/test-framework/org/apache/lucene/util/LuceneJUnitResultFormatter.java
          svn mv --parents lucene/src/test/org/apache/lucene/util/LuceneTestCase.java lucene/src/test-framework/org/apache/lucene/util/LuceneTestCase.java
          svn mv --parents lucene/src/test/org/apache/lucene/search/QueryUtils.java lucene/src/test-framework/org/apache/lucene/search/QueryUtils.java
          svn mv --parents lucene/src/test/org/apache/lucene/search/CheckHits.java lucene/src/test-framework/org/apache/lucene/search/CheckHits.java
          svn mv --parents lucene/src/test/org/apache/lucene/analysis/BaseTokenStreamTestCase.java lucene/src/test-framework/org/apache/lucene/analysis/BaseTokenStreamTestCase.java
          svn mv --parents lucene/src/test/org/apache/lucene/analysis/MockAnalyzer.java lucene/src/test-framework/org/apache/lucene/analysis/MockAnalyzer.java
          svn mv --parents lucene/src/test/org/apache/lucene/index/MockIndexInput.java lucene/src/test-framework/org/apache/lucene/index/MockIndexInput.java
          svn mv --parents lucene/src/test/org/apache/lucene/index/RandomIndexWriter.java lucene/src/test-framework/org/apache/lucene/index/RandomIndexWriter.java
          svn mv --parents lucene/src/test/org/apache/lucene/index/DocHelper.java lucene/src/test-framework/org/apache/lucene/index/DocHelper.java
          svn mv --parents lucene/src/test/org/apache/lucene/store/_TestHelper.java lucene/src/test-framework/org/apache/lucene/store/_TestHelper.java
          svn mv --parents lucene/src/test/org/apache/lucene/store/MockDirectoryWrapper.java lucene/src/test-framework/org/apache/lucene/store/MockDirectoryWrapper.java
          svn mv --parents lucene/src/test/org/apache/lucene/store/MockIndexInputWrapper.java lucene/src/test-framework/org/apache/lucene/store/MockIndexInputWrapper.java
          svn mv --parents lucene/src/test/org/apache/lucene/store/MockIndexOutputWrapper.java lucene/src/test-framework/org/apache/lucene/store/MockIndexOutputWrapper.java
          

          I did not convert Solr build yet - will do so after we review the 'lucene' patch.

          Also, can someone please list the Solr test-framework classes? I will handle them as well.

          Show
          Shai Erera added a comment - Patch includes changes to build.xmls (ignore the other changes, they are caused by svn moves – I didn't touch the source files). I'd appreciate an Ant 'expert' looking at them. Since some tests depend on other tests (e.g. through extension) and other classes that are not under test-framework, I couldn't make a test.classpath that references test-framework only. So I modified test.classpath to reference both classes/test and classes/test-framework. If you want to apply the patch, make sure to run the following commands: svn mkdir lucene/src/test-framework svn mv --parents lucene/src/test/org/apache/lucene/util/_TestUtil.java lucene/src/test-framework/org/apache/lucene/util/_TestUtil.java svn mv --parents lucene/src/test/org/apache/lucene/util/LineFileDocs.java lucene/src/test-framework/org/apache/lucene/util/LineFileDocs.java svn mv --parents lucene/src/test/org/apache/lucene/util/LuceneJUnitDividingSelector.java lucene/src/test-framework/org/apache/lucene/util/LuceneJUnitDividingSelector.java svn mv --parents lucene/src/test/org/apache/lucene/util/LuceneJUnitResultFormatter.java lucene/src/test-framework/org/apache/lucene/util/LuceneJUnitResultFormatter.java svn mv --parents lucene/src/test/org/apache/lucene/util/LuceneTestCase.java lucene/src/test-framework/org/apache/lucene/util/LuceneTestCase.java svn mv --parents lucene/src/test/org/apache/lucene/search/QueryUtils.java lucene/src/test-framework/org/apache/lucene/search/QueryUtils.java svn mv --parents lucene/src/test/org/apache/lucene/search/CheckHits.java lucene/src/test-framework/org/apache/lucene/search/CheckHits.java svn mv --parents lucene/src/test/org/apache/lucene/analysis/BaseTokenStreamTestCase.java lucene/src/test-framework/org/apache/lucene/analysis/BaseTokenStreamTestCase.java svn mv --parents lucene/src/test/org/apache/lucene/analysis/MockAnalyzer.java lucene/src/test-framework/org/apache/lucene/analysis/MockAnalyzer.java svn mv --parents lucene/src/test/org/apache/lucene/index/MockIndexInput.java lucene/src/test-framework/org/apache/lucene/index/MockIndexInput.java svn mv --parents lucene/src/test/org/apache/lucene/index/RandomIndexWriter.java lucene/src/test-framework/org/apache/lucene/index/RandomIndexWriter.java svn mv --parents lucene/src/test/org/apache/lucene/index/DocHelper.java lucene/src/test-framework/org/apache/lucene/index/DocHelper.java svn mv --parents lucene/src/test/org/apache/lucene/store/_TestHelper.java lucene/src/test-framework/org/apache/lucene/store/_TestHelper.java svn mv --parents lucene/src/test/org/apache/lucene/store/MockDirectoryWrapper.java lucene/src/test-framework/org/apache/lucene/store/MockDirectoryWrapper.java svn mv --parents lucene/src/test/org/apache/lucene/store/MockIndexInputWrapper.java lucene/src/test-framework/org/apache/lucene/store/MockIndexInputWrapper.java svn mv --parents lucene/src/test/org/apache/lucene/store/MockIndexOutputWrapper.java lucene/src/test-framework/org/apache/lucene/store/MockIndexOutputWrapper.java I did not convert Solr build yet - will do so after we review the 'lucene' patch. Also, can someone please list the Solr test-framework classes? I will handle them as well.
          Hide
          Robert Muir added a comment -

          Sorry Shai... I'll try to blame this one on the new JIRA.

          Show
          Robert Muir added a comment - Sorry Shai... I'll try to blame this one on the new JIRA.
          Hide
          Robert Muir added a comment -

          Sorry, wrong jira issue

          Show
          Robert Muir added a comment - Sorry, wrong jira issue
          Hide
          Uwe Schindler added a comment -

          I think we can make the Solr changes here on this issue. I don't think we need a separate JIRA.

          We must do them on this issue, as solr and also contrib/modules build will fail after the changes in core only: The base classes will be at a different build folder (build/classes/test-base), so all build.xmls need some changes.

          Else i would prefer simply: "test-framework". I can work on a patch later!

          Show
          Uwe Schindler added a comment - I think we can make the Solr changes here on this issue. I don't think we need a separate JIRA. We must do them on this issue, as solr and also contrib/modules build will fail after the changes in core only: The base classes will be at a different build folder (build/classes/test-base), so all build.xmls need some changes. Else i would prefer simply: "test-framework". I can work on a patch later!
          Hide
          Grant Ingersoll added a comment -

          Sounds good. I think we can make the Solr changes here on this issue. I don't think we need a separate JIRA.

          Show
          Grant Ingersoll added a comment - Sounds good. I think we can make the Solr changes here on this issue. I don't think we need a separate JIRA.
          Hide
          Uwe Schindler added a comment -

          That was exactly my proposal. In addition I would also change module and contrib test compile/run to only depend on the test-base to be compiled. We have to change their build.xml in all cases, as we need to change classpath.

          Show
          Uwe Schindler added a comment - That was exactly my proposal. In addition I would also change module and contrib test compile/run to only depend on the test-base to be compiled. We have to change their build.xml in all cases, as we need to change classpath.
          Hide
          Shai Erera added a comment -

          To summarize the plan then:

          • We'll separate tests into src/test and src/test-base (you're welcome to suggest better name)
            • Under test-base we put the framework classes
            • Under test we put the actual test cases (and all other classes that are not 'framework'?)
          • Keep package names the same under each
          • jar-test-core will jar up test-base

          In a follow on issue, we fix the build to depend on test-base when compiling tests. We can also make the same changes to Solr tests and let Solr's test-base depend on Lucene's test-base and Solr's test depend on Solr's test-base. Maybe this is an issue to open under Solr's JIRA as a follow on?

          Show
          Shai Erera added a comment - To summarize the plan then: We'll separate tests into src/test and src/test-base (you're welcome to suggest better name) Under test-base we put the framework classes Under test we put the actual test cases (and all other classes that are not 'framework'?) Keep package names the same under each jar-test-core will jar up test-base In a follow on issue, we fix the build to depend on test-base when compiling tests. We can also make the same changes to Solr tests and let Solr's test-base depend on Lucene's test-base and Solr's test depend on Solr's test-base. Maybe this is an issue to open under Solr's JIRA as a follow on?
          Hide
          Robert Muir added a comment -

          The real tests are compiled later and not jared and reference the jar or build/classes/test-base in classpath. Then packages are identical and no problems occur.

          This is much better, because it resolves some practical concerns.

          • the package namespace is unchanged, we can still use pkg-private stuff
          • there is no hardcoded list, we can still eclipse-refactor and run 'ant test' and the build will not break. So, its
            still easy to refactor tests.

          It would require some up-front work to the build etc, but could be good, for example to simplify up2date macros
          where moduleA's tests depend upon base classes of moduleB (this is currently messy).

          Show
          Robert Muir added a comment - The real tests are compiled later and not jared and reference the jar or build/classes/test-base in classpath. Then packages are identical and no problems occur. This is much better, because it resolves some practical concerns. the package namespace is unchanged, we can still use pkg-private stuff there is no hardcoded list, we can still eclipse-refactor and run 'ant test' and the build will not break. So, its still easy to refactor tests. It would require some up-front work to the build etc, but could be good, for example to simplify up2date macros where moduleA's tests depend upon base classes of moduleB (this is currently messy).
          Hide
          Uwe Schindler added a comment -

          If it will make things any simpler, then let's put all the framework classes under src/test/o.a.l/framework and have simple target which jars up everything underneath it.

          Well i mean sounds good (so do parts of Uwe's idea too).

          But, some of this stuff is in packages for a reason, it uses package-private hacks to improve test-coverage, etc.
          So if we do this, we need to expose lots of things as 'public' and @lucene.internal for testing, possibly even whole
          classes (haven't looked in a while).

          This is different in my proposal. The copy task from shais task would be done one time to a different and self-contained src/test-base (need better name). That gets compiled separate and produces jar file.

          The real tests are compiled later and not jared and reference the jar or build/classes/test-base in classpath. Then packages are identical and no problems occur.

          Show
          Uwe Schindler added a comment - If it will make things any simpler, then let's put all the framework classes under src/test/o.a.l/framework and have simple target which jars up everything underneath it. Well i mean sounds good (so do parts of Uwe's idea too). But, some of this stuff is in packages for a reason, it uses package-private hacks to improve test-coverage, etc. So if we do this, we need to expose lots of things as 'public' and @lucene.internal for testing, possibly even whole classes (haven't looked in a while). This is different in my proposal. The copy task from shais task would be done one time to a different and self-contained src/test-base (need better name). That gets compiled separate and produces jar file. The real tests are compiled later and not jared and reference the jar or build/classes/test-base in classpath. Then packages are identical and no problems occur.
          Hide
          Shai Erera added a comment -

          It was just a suggestion. If we have utilities that use package-private API (though their API can be public) then let's keep them where we are. I don't want to over-complicate our tests, just because we want to give users (and ourselves) some useful utilities.

          BTW, I modified the target to jar only the *.java files and it resulted in a 1.2 MB file (just .class ones). It's less intimidating, but it still contains 254 classes which is a lot. I wouldn't even know where to start.

          To me, what I see with the 'focused' file is that I (think) can easily understand what should I use for what purpose. We can start with even a smaller set of files, like _TestUtil, LuceneTestCase and BaseTokenStreamTestCase (and maybe the MockDirWrapper and RandomIndexWriter?).

          Alternatively, we can .jar up all .class files for convenience, and include a README that describes what you should be looking at when you use this .jar. But personally, I don't think refactoring to tests will severely affect our ability to maintain that .jar. Really, it's just renaming of some classes, and/or adding few more.

          Show
          Shai Erera added a comment - It was just a suggestion. If we have utilities that use package-private API (though their API can be public) then let's keep them where we are. I don't want to over-complicate our tests, just because we want to give users (and ourselves) some useful utilities. BTW, I modified the target to jar only the *.java files and it resulted in a 1.2 MB file (just .class ones). It's less intimidating, but it still contains 254 classes which is a lot. I wouldn't even know where to start. To me, what I see with the 'focused' file is that I (think) can easily understand what should I use for what purpose. We can start with even a smaller set of files, like _TestUtil, LuceneTestCase and BaseTokenStreamTestCase (and maybe the MockDirWrapper and RandomIndexWriter?). Alternatively, we can .jar up all .class files for convenience, and include a README that describes what you should be looking at when you use this .jar. But personally, I don't think refactoring to tests will severely affect our ability to maintain that .jar. Really, it's just renaming of some classes, and/or adding few more.
          Hide
          Robert Muir added a comment -

          If it will make things any simpler, then let's put all the framework classes under src/test/o.a.l/framework and have simple target which jars up everything underneath it.

          Well i mean sounds good (so do parts of Uwe's idea too).

          But, some of this stuff is in packages for a reason, it uses package-private hacks to improve test-coverage, etc.
          So if we do this, we need to expose lots of things as 'public' and @lucene.internal for testing, possibly even whole
          classes (haven't looked in a while).

          Currently we use tricks like this often in tests: unlike other software (e.g. JRE itself) we don't have a separate impl
          namespace to manage things like this without polluting the API... we have to use @internal for a lot of things.

          Just saying I don't think its simple, sure if someone wants to do the work to reorganize all of this stuff, thats great.
          its also a bit scary right before a release, considering modifications of core src/java stuff would be involved (how much,
          I am not sure).

          Do we have to do this for 3.1? Or can we include the huge jar file for 3.1 and work on this stuff for a future release?

          Show
          Robert Muir added a comment - If it will make things any simpler, then let's put all the framework classes under src/test/o.a.l/framework and have simple target which jars up everything underneath it. Well i mean sounds good (so do parts of Uwe's idea too). But, some of this stuff is in packages for a reason, it uses package-private hacks to improve test-coverage, etc. So if we do this, we need to expose lots of things as 'public' and @lucene.internal for testing, possibly even whole classes (haven't looked in a while). Currently we use tricks like this often in tests: unlike other software (e.g. JRE itself) we don't have a separate impl namespace to manage things like this without polluting the API... we have to use @internal for a lot of things. Just saying I don't think its simple, sure if someone wants to do the work to reorganize all of this stuff, thats great. its also a bit scary right before a release, considering modifications of core src/java stuff would be involved (how much, I am not sure). Do we have to do this for 3.1? Or can we include the huge jar file for 3.1 and work on this stuff for a future release?
          Hide
          Shai Erera added a comment -

          Agreed - tests improvement should be our main concern. That's why I said this .jar is just a service, we don't commit to anything besides saying "for each release, tests.jar includes the classes that make up our framework". If it will make things any simpler, then let's put all the framework classes under src/test/o.a.l/framework and have simple target which jars up everything underneath it.

          But I don't have any intentions complicating tests development, improvement and refactoring. Indeed, including specific files by path would mean some more work when we refactor those classes (e.g. move them around), but I don't think it's such a big deal if they'll be absent from the .jar. It's easily fixed. However, if we agree to put everything under */framework, then it won't happen, right?

          And if the Solr tests depend on actual test cases, because e.g. they extend them, then let's discuss that too - Uwe's proposal makes sense too.

          Show
          Shai Erera added a comment - Agreed - tests improvement should be our main concern. That's why I said this .jar is just a service, we don't commit to anything besides saying "for each release, tests.jar includes the classes that make up our framework". If it will make things any simpler, then let's put all the framework classes under src/test/o.a.l/framework and have simple target which jars up everything underneath it. But I don't have any intentions complicating tests development, improvement and refactoring. Indeed, including specific files by path would mean some more work when we refactor those classes (e.g. move them around), but I don't think it's such a big deal if they'll be absent from the .jar. It's easily fixed. However, if we agree to put everything under */framework, then it won't happen, right? And if the Solr tests depend on actual test cases, because e.g. they extend them, then let's discuss that too - Uwe's proposal makes sense too.
          Hide
          Robert Muir added a comment -

          It's always hard to argue with arguments like that. I don't know what it will need in the future, but I'd bet not much more. And if it will, we can just include that file.

          I agree it was a bad argument, here's what I was trying to express:

          My concerns rotate around slowing down the development of the tests themselves, which are not sexy to work on
          and always need more improvements, serious cleanup work, complete rewrites, mega-refactors, etc. So I think
          if we are going to provide test stuff to users, we need to be extra cautious about hindering our own development.

          Show
          Robert Muir added a comment - It's always hard to argue with arguments like that. I don't know what it will need in the future, but I'd bet not much more. And if it will, we can just include that file. I agree it was a bad argument, here's what I was trying to express: My concerns rotate around slowing down the development of the tests themselves, which are not sexy to work on and always need more improvements, serious cleanup work, complete rewrites, mega-refactors, etc. So I think if we are going to provide test stuff to users, we need to be extra cautious about hindering our own development.
          Hide
          Shai Erera added a comment -

          What backwards compatibility policy Robert? This .jar is not under any back-compat policy. And if we realize it gets more and more complicated maintaining it, we can either jar src/test or delete the .jar. This is just a tiny service we're giving to users (and ourselves). Nothing more.

          Show
          Shai Erera added a comment - What backwards compatibility policy Robert? This .jar is not under any back-compat policy. And if we realize it gets more and more complicated maintaining it, we can either jar src/test or delete the .jar. This is just a tiny service we're giving to users (and ourselves). Nothing more.
          Hide
          Shai Erera added a comment -

          but what else does it use/might it use in the future?

          It's always hard to argue with arguments like that. I don't know what it will need in the future, but I'd bet not much more. And if it will, we can just include that file.

          Let's remember what's the purpose of this issue - to allow people to use the great tools that we have (mostly b/c of you !) in their test environment. Like Uwe mentions, test someone's TokenStream is a very useful utility. I don't believe they want to run TestIndexWriter in their environment, and extending it doesn't sound very useful. So I dunno, I feel that shipping just a few select files will help users eventually and ease our life (c'mon, how complicated is adding another file to the list of files?). We can attach a README in the .jar which explains what does each class do.

          Show
          Shai Erera added a comment - but what else does it use/might it use in the future? It's always hard to argue with arguments like that. I don't know what it will need in the future, but I'd bet not much more. And if it will, we can just include that file. Let's remember what's the purpose of this issue - to allow people to use the great tools that we have (mostly b/c of you !) in their test environment. Like Uwe mentions, test someone's TokenStream is a very useful utility. I don't believe they want to run TestIndexWriter in their environment, and extending it doesn't sound very useful. So I dunno, I feel that shipping just a few select files will help users eventually and ease our life (c'mon, how complicated is adding another file to the list of files?). We can attach a README in the .jar which explains what does each class do.
          Hide
          Robert Muir added a comment -

          BaseTokenSteamTestCase should be really available to everyone as a public and supported JAR file.

          new developers have a set of javadoced base classes againt those they need to write their tests

          What does this mean? whats the backwards compatibility policy when we rip the API completely apart to improve test coverage 0.01%?

          What is the discussion when its gone completely and part of the analyzers module, in order to move more analysis classes
          to the analyzers module itself, perhaps because we are separating analysis from the indexer more and want to start adding
          'alternative' analysis APIs completely to the analyzers module (so we want this one pulled out of core) ?

          Thats a big concrete concern of mine, if we introduce barriers to this kind of refactoring, but also other test improvements.

          Show
          Robert Muir added a comment - BaseTokenSteamTestCase should be really available to everyone as a public and supported JAR file. new developers have a set of javadoced base classes againt those they need to write their tests What does this mean? whats the backwards compatibility policy when we rip the API completely apart to improve test coverage 0.01%? What is the discussion when its gone completely and part of the analyzers module, in order to move more analysis classes to the analyzers module itself, perhaps because we are separating analysis from the indexer more and want to start adding 'alternative' analysis APIs completely to the analyzers module (so we want this one pulled out of core) ? Thats a big concrete concern of mine, if we introduce barriers to this kind of refactoring, but also other test improvements.
          Hide
          Uwe Schindler added a comment -

          But is anyone concerned about the file size of the tests jar? It just goes into someone's test mechanism, I think if its 7MB this is no problem.

          My problem is that you cannot run the tests from this jar file, as lots of tests need the files in classpath, but as real files. We may work around that, but all tests that call new File(Class.getResource().toURI()) will of course fail (and there are lots of them).

          So I prefer a small JAR file without crap that can also be shipped in the binary zip and helps the user. The large one confuses totally. If you want to use the whole test build incl all files, you can simply run "ant compile-tests" and point your IDE to build/classes/test. I think we want more a subset of "usefull" classes for external developers to test their own implementations like TokenStreams, Similarities, CustomScoreQueries,....

          Show
          Uwe Schindler added a comment - But is anyone concerned about the file size of the tests jar? It just goes into someone's test mechanism, I think if its 7MB this is no problem. My problem is that you cannot run the tests from this jar file, as lots of tests need the files in classpath, but as real files. We may work around that, but all tests that call new File(Class.getResource().toURI()) will of course fail (and there are lots of them). So I prefer a small JAR file without crap that can also be shipped in the binary zip and helps the user. The large one confuses totally . If you want to use the whole test build incl all files, you can simply run "ant compile-tests" and point your IDE to build/classes/test. I think we want more a subset of "usefull" classes for external developers to test their own implementations like TokenStreams, Similarities, CustomScoreQueries,....
          Hide
          Uwe Schindler added a comment -

          My problem with the large JAR file is: as its build on "ant package" its shipped with final binary ZIP and this one is huge already!

          I (and lots of others) prefer to ship a small jar file to the user, that helps developing Lucene-based test cases, e.g to check TokenStreams (thats my main issue). BaseTokenSteamTestCase should be really available to everyone as a public and supported JAR file. This was my personal idea behind that one.

          I propose to do it in a different way:

          Let's split up test source and build files into two folders: src/test-base and src/test, compiled to build/test-base and build/test and can separately zipped.
          Both of them are compiled separately so self-contained. The test simply import both target lib folders and all should work. The test-base build foder is the only one jared as class files and mabe also get javadocs. The original tests are not part of this.

          This would help both developers and users:

          • new developers have a set of javadoced base classes againt those they need to write their tests
          • users can reuse our cool checker/assert/... classes to check their own developments by simply adding a jar file (please, withot sources, we also dont package sources into lucene-core.jar).

          Comments?

          Show
          Uwe Schindler added a comment - My problem with the large JAR file is: as its build on "ant package" its shipped with final binary ZIP and this one is huge already! I (and lots of others) prefer to ship a small jar file to the user, that helps developing Lucene-based test cases, e.g to check TokenStreams (thats my main issue). BaseTokenSteamTestCase should be really available to everyone as a public and supported JAR file. This was my personal idea behind that one. I propose to do it in a different way: Let's split up test source and build files into two folders: src/test-base and src/test, compiled to build/test-base and build/test and can separately zipped. Both of them are compiled separately so self-contained. The test simply import both target lib folders and all should work. The test-base build foder is the only one jared as class files and mabe also get javadocs. The original tests are not part of this. This would help both developers and users: new developers have a set of javadoced base classes againt those they need to write their tests users can reuse our cool checker/assert/... classes to check their own developments by simply adding a jar file (please, withot sources, we also dont package sources into lucene-core.jar). Comments?
          Hide
          Robert Muir added a comment -

          We can jar up all *.java to reduce the file size. I'm not too concerned about the file size but more of the usability of it. If we're doing some service, then let's do it properly. If we jar dozens, or tens of dozens of .java files, how will users use the .jar? Vs if we just jar the relevant classes that make up the framework?

          But is anyone concerned about the file size of the tests jar?
          It just goes into someone's test mechanism, I think if its 7MB this is no problem.

          Thats why I looked at the changes and felt we are over-engineering this, but
          to only to make things more complex for us...

          Also keep in mind that as Grant mentioned, if he wants to use the Solr tests jar, it will
          depend upon this lucene tests jar. So I think its safest to include everything, otherwise
          the Solr tests jar might not work. I know for sure SolrTestCaseJ4 extends LuceneTestCase,
          but what else does it use/might it use in the future?

          Show
          Robert Muir added a comment - We can jar up all *.java to reduce the file size. I'm not too concerned about the file size but more of the usability of it. If we're doing some service, then let's do it properly. If we jar dozens, or tens of dozens of .java files, how will users use the .jar? Vs if we just jar the relevant classes that make up the framework? But is anyone concerned about the file size of the tests jar? It just goes into someone's test mechanism, I think if its 7MB this is no problem. Thats why I looked at the changes and felt we are over-engineering this, but to only to make things more complex for us... Also keep in mind that as Grant mentioned, if he wants to use the Solr tests jar, it will depend upon this lucene tests jar. So I think its safest to include everything, otherwise the Solr tests jar might not work. I know for sure SolrTestCaseJ4 extends LuceneTestCase, but what else does it use/might it use in the future?
          Hide
          Shai Erera added a comment -

          So Robert, I don't really follow the BUILD FAILURE thing - what could fail? Those files are compiled against the test.classpath so whatever changes you make to test classes, this sample of files won't be affected at compile time. It's only at runtime, meaning when someone actually integrating them into his test env. that a problem may be discovered.

          If you split LTC to LTC1 and LTC2, then all it means is that LTC won't be included (b/c the copy task won't find it) and we'll need to fix the testfiles file to include LTC1 and 2.

          How about some common courtesy here?

          Grant, I didn't mean to hastily commit something in the middle of your night, in order to slip it through. We did discuss it here and over IRC and it seemed ok to commit. And it was part of rapid issues solving phase. Sorry if I offended you in any way.

          We can jar up all *.java to reduce the file size. I'm not too concerned about the file size but more of the usability of it. If we're doing some service, then let's do it properly. If we jar dozens, or tens of dozens of .java files, how will users use the .jar? Vs if we just jar the relevant classes that make up the framework?

          Show
          Shai Erera added a comment - So Robert, I don't really follow the BUILD FAILURE thing - what could fail? Those files are compiled against the test.classpath so whatever changes you make to test classes, this sample of files won't be affected at compile time. It's only at runtime, meaning when someone actually integrating them into his test env. that a problem may be discovered. If you split LTC to LTC1 and LTC2, then all it means is that LTC won't be included (b/c the copy task won't find it) and we'll need to fix the testfiles file to include LTC1 and 2. How about some common courtesy here? Grant, I didn't mean to hastily commit something in the middle of your night, in order to slip it through. We did discuss it here and over IRC and it seemed ok to commit. And it was part of rapid issues solving phase. Sorry if I offended you in any way. We can jar up all *.java to reduce the file size. I'm not too concerned about the file size but more of the usability of it. If we're doing some service, then let's do it properly. If we jar dozens, or tens of dozens of .java files, how will users use the .jar? Vs if we just jar the relevant classes that make up the framework?
          Hide
          Grant Ingersoll added a comment -

          Hard to break what?

          I just meant in general I agree w/ the build failed principal, but some of these development tools/tests are really useful, so I'm inclined to want to add them even if it makes things marginally harder for us.

          And, yes, I agree we should do the whole jar.

          Show
          Grant Ingersoll added a comment - Hard to break what? I just meant in general I agree w/ the build failed principal, but some of these development tools/tests are really useful, so I'm inclined to want to add them even if it makes things marginally harder for us. And, yes, I agree we should do the whole jar.
          Hide
          Robert Muir added a comment -

          While agree with the "Build Failed" notion in general, I often think that it's a bit short sighted in that we make something marginally less annoying for us the committers (really, is it that hard to fix?) and much harder for our users b/c they have to go re-invent the wheel. Not everyone is an expert. We have to balance those two. I think instead of putting up roadblocks on principal to these kinds of things, we need to figure out ways to automate them and validate them so that it is hard to break.

          Hard to break what? I dont think we should have to jump through hoops to improve tests...
          I guess where we disagree here is that I don't think tests are for end users, they are for development.
          I don't think there is a balance here at all, its 100% tipped in favor of our test coverage.

          If we can jar all them up easily, like this original patch (which won't slow down development at all,
          since it will just compile all of them, no additional maintenance cost), then thats great if someone
          can make use of them...

          Show
          Robert Muir added a comment - While agree with the "Build Failed" notion in general, I often think that it's a bit short sighted in that we make something marginally less annoying for us the committers (really, is it that hard to fix?) and much harder for our users b/c they have to go re-invent the wheel. Not everyone is an expert. We have to balance those two. I think instead of putting up roadblocks on principal to these kinds of things, we need to figure out ways to automate them and validate them so that it is hard to break. Hard to break what? I dont think we should have to jump through hoops to improve tests... I guess where we disagree here is that I don't think tests are for end users, they are for development. I don't think there is a balance here at all, its 100% tipped in favor of our test coverage. If we can jar all them up easily, like this original patch (which won't slow down development at all, since it will just compile all of them, no additional maintenance cost), then thats great if someone can make use of them...
          Hide
          Robert Muir added a comment -

          Just to sum up, I think we should go back to the huge jar like the initial patch.

          I had no problems with this: its a test jar, its going to be part of someone's test infrastructure
          (not shipped to clients or anything). So I think size is not really a concern here, unlike the
          lucene-core jar for example.

          Furthermore, if someone is concerned about size for some reason, lets place that burden
          on them to deal with (e.g. just taking the classes they care about), instead of on us.

          Show
          Robert Muir added a comment - Just to sum up, I think we should go back to the huge jar like the initial patch. I had no problems with this: its a test jar, its going to be part of someone's test infrastructure (not shipped to clients or anything). So I think size is not really a concern here, unlike the lucene-core jar for example. Furthermore, if someone is concerned about size for some reason, lets place that burden on them to deal with (e.g. just taking the classes they care about), instead of on us.
          Hide
          Grant Ingersoll added a comment -

          Mostly, I think I need the SolrTestCaseJ4 (and thus the Lucene test case, Solr change is coming soon) as it is really useful for writing down stream tests that test applications that use Lucene/Solr, but if it's too big of a problem, I'm fine with reverting this and Drew and I can just publish our own Jar file.

          except its called from 'ant package', so I will see 'BUILD FAILED' if i refactor something that breaks this (lets say I split up LuceneTestCase, etc).

          While agree with the "Build Failed" notion in general, I often think that it's a bit short sighted in that we make something marginally less annoying for us the committers (really, is it that hard to fix?) and much harder for our users b/c they have to go re-invent the wheel. Not everyone is an expert. We have to balance those two. I think instead of putting up roadblocks on principal to these kinds of things, we need to figure out ways to automate them and validate them so that it is hard to break.

          I see a different tradeoff: 'maybe' breaking an unsupporte .jar to 'always' fetching a 7MB useless file ...

          As for the 7mb file, really, that's an issue these days? OK, well if it is useless than maybe, but... At any rate, what, does that take like 30 seconds to download, tops? I downloaded the Freebase dataset last night (1.6GB) for fun!

          Committed revision 1064066 (3x).
          Committed revision 1064068 (trunk) - added more files to testfiles that exist only in trunk.

          How about some common courtesy here? Making a decision in the middle of the night (for me) to commit something I was working on without getting my input is pretty rude. Is the issue really that urgent that it couldn't wait a few hours? I mean were you all of a sudden forced to download a 7mb file?

          Show
          Grant Ingersoll added a comment - Mostly, I think I need the SolrTestCaseJ4 (and thus the Lucene test case, Solr change is coming soon) as it is really useful for writing down stream tests that test applications that use Lucene/Solr, but if it's too big of a problem, I'm fine with reverting this and Drew and I can just publish our own Jar file. except its called from 'ant package', so I will see 'BUILD FAILED' if i refactor something that breaks this (lets say I split up LuceneTestCase, etc). While agree with the "Build Failed" notion in general, I often think that it's a bit short sighted in that we make something marginally less annoying for us the committers (really, is it that hard to fix?) and much harder for our users b/c they have to go re-invent the wheel. Not everyone is an expert. We have to balance those two. I think instead of putting up roadblocks on principal to these kinds of things, we need to figure out ways to automate them and validate them so that it is hard to break. I see a different tradeoff: 'maybe' breaking an unsupporte .jar to 'always' fetching a 7MB useless file ... As for the 7mb file, really, that's an issue these days? OK, well if it is useless than maybe, but... At any rate, what, does that take like 30 seconds to download, tops? I downloaded the Freebase dataset last night (1.6GB) for fun! Committed revision 1064066 (3x). Committed revision 1064068 (trunk) - added more files to testfiles that exist only in trunk. How about some common courtesy here? Making a decision in the middle of the night (for me) to commit something I was working on without getting my input is pretty rude. Is the issue really that urgent that it couldn't wait a few hours? I mean were you all of a sudden forced to download a 7mb file?
          Hide
          Robert Muir added a comment -

          I don't think this should hold us back when maintaining tests. It's like "ant eclipse/idea/maven" - not too many guarantees besides "we're gonna do the best we can to maintain it" (it being the .jar, not tests).

          except its called from 'ant package', so I will see 'BUILD FAILED' if i refactor something that breaks this (lets say I split up LuceneTestCase, etc).

          Furthermore, take an example where i add something to LuceneTestCase, where it reads data from a 10MB file, or something that breaks this design.
          If my idea is good for tests, it should be committed, and not "reconsidered because of test.jar packaging".
          This example is a totally ridiculous/absurd/extreme one: but there are also cases not-so-extreme.

          I think its vital that its easy for us to be able to refactor tests with wreckless abandon with only three goals in mind:

          1. Test Coverage
          2. Test Coverage
          3. Test Coverage

          I am getting worried that src/test starts getting held to a "higher standard" here, when its a tool to ensure test coverage.
          I agree when possible, we should try to keep the code quality high in src/test, but this is really just completely optional.

          Show
          Robert Muir added a comment - I don't think this should hold us back when maintaining tests. It's like "ant eclipse/idea/maven" - not too many guarantees besides "we're gonna do the best we can to maintain it" (it being the .jar, not tests). except its called from 'ant package', so I will see 'BUILD FAILED' if i refactor something that breaks this (lets say I split up LuceneTestCase, etc). Furthermore, take an example where i add something to LuceneTestCase, where it reads data from a 10MB file, or something that breaks this design. If my idea is good for tests, it should be committed, and not "reconsidered because of test.jar packaging". This example is a totally ridiculous/absurd/extreme one: but there are also cases not-so-extreme. I think its vital that its easy for us to be able to refactor tests with wreckless abandon with only three goals in mind: Test Coverage Test Coverage Test Coverage I am getting worried that src/test starts getting held to a "higher standard" here, when its a tool to ensure test coverage. I agree when possible, we should try to keep the code quality high in src/test, but this is really just completely optional.
          Hide
          Shai Erera added a comment -

          This is good point Robert, but I don't like the one huge .jar either, just because it contains everything. I think that it's ok if this .jar breaks - we don't guarantee anything. If something breaks, we can add the needed classes?

          I see a different tradeoff: 'maybe' breaking an unsupporte .jar to 'always' fetching a 7MB useless file ...

          I don't think this should hold us back when maintaining tests. It's like "ant eclipse/idea/maven" – not too many guarantees besides "we're gonna do the best we can to maintain it" (it being the .jar, not tests).

          Show
          Shai Erera added a comment - This is good point Robert, but I don't like the one huge .jar either, just because it contains everything. I think that it's ok if this .jar breaks - we don't guarantee anything. If something breaks, we can add the needed classes? I see a different tradeoff: 'maybe' breaking an unsupporte .jar to 'always' fetching a 7MB useless file ... I don't think this should hold us back when maintaining tests. It's like "ant eclipse/idea/maven" – not too many guarantees besides "we're gonna do the best we can to maintain it" (it being the .jar, not tests).
          Hide
          Robert Muir added a comment -

          Reopening for discussion: I'm not happy with the tradeoff that its harder for us
          to improve/maintain tests at the expense of the special jars.

          Show
          Robert Muir added a comment - Reopening for discussion: I'm not happy with the tradeoff that its harder for us to improve/maintain tests at the expense of the special jars.
          Hide
          Robert Muir added a comment -

          I don't know about the changes here guys... if I add a new test class
          and one of these test jars depends upon it, then suddenly this thing breaks?

          I think it should be the huge jar file, or no test jar file at all.

          otherwise this change is making it harder for us to improve tests.

          Show
          Robert Muir added a comment - I don't know about the changes here guys... if I add a new test class and one of these test jars depends upon it, then suddenly this thing breaks? I think it should be the huge jar file, or no test jar file at all. otherwise this change is making it harder for us to improve tests.
          Hide
          Shai Erera added a comment -

          Committed revision 1064066 (3x).
          Committed revision 1064068 (trunk) – added more files to testfiles that exist only in trunk.

          Show
          Shai Erera added a comment - Committed revision 1064066 (3x). Committed revision 1064068 (trunk) – added more files to testfiles that exist only in trunk.
          Hide
          Uwe Schindler added a comment -

          Commit it, was just a suggestion because I am anti-mixed-jars.

          Show
          Uwe Schindler added a comment - Commit it, was just a suggestion because I am anti-mixed-jars.
          Hide
          Shai Erera added a comment -

          I think two files for such a tiny .jar is an overkill. I don't mind splitting them up to test-src.zip and tests.jar if it matters much. Otherwise, I think I'll commit this and we can add more classes to the 'testfiles' as we go along.

          Show
          Shai Erera added a comment - I think two files for such a tiny .jar is an overkill. I don't mind splitting them up to test-src.zip and tests.jar if it matters much. Otherwise, I think I'll commit this and we can add more classes to the 'testfiles' as we go along.
          Hide
          Simon Willnauer added a comment -

          looks good to me!

          Show
          Simon Willnauer added a comment - looks good to me!
          Hide
          Uwe Schindler added a comment -

          +1
          That was exactly wht I had in mind. I would only prefer to have 2 jar files, tests-src.jar and tests.jar

          Show
          Uwe Schindler added a comment - +1 That was exactly wht I had in mind. I would only prefer to have 2 jar files, tests-src.jar and tests.jar
          Hide
          Shai Erera added a comment -
          • Moves jar-core-test to build.xml
          • Adds dev-tools/testjar/testfiles with a list of files (includes what Simon listed so far) – we can add more as we go
            • Both .java and .class are added.
          Show
          Shai Erera added a comment - Moves jar-core-test to build.xml Adds dev-tools/testjar/testfiles with a list of files (includes what Simon listed so far) – we can add more as we go Both .java and .class are added.
          Hide
          Simon Willnauer added a comment -

          Hey shai,

          I just collected some classes I would find useful for testing applications.

          /lucene/src/test/org/apache/lucene/util/_TestUtil.java
          /lucene/src/test/org/apache/lucene/util/LineFileDocs.java
          /lucene/src/test/org/apache/lucene/util/LuceneJUnitDividingSelector.java
          /lucene/src/test/org/apache/lucene/util/LuceneJUnitResultFormatter.java
          /lucene/src/test/org/apache/lucene/util/LuceneTestCase.java
          
          /lucene/src/test/org/apache/lucene/search/QueryUtils.java
          /lucene/src/test/org/apache/lucene/analysis/BaseTokenStreamTestCase.java
          /lucene/src/test/org/apache/lucene/analysis/MockAnalyzer.java
          /lucene/src/test/org/apache/lucene/analysis/MockPayloadAnalyzer.java
          /lucene/src/test/org/apache/lucene/analysis/MockTokenFilter.java
          /lucene/src/test/org/apache/lucene/analysis/MockTokenizer.java
          
          /lucene/src/test/org/apache/lucene/index/MockIndexInput.java
          /lucene/src/test/org/apache/lucene/index/RandomIndexWriter.java
          /lucene/src/test/org/apache/lucene/index/DocHelper.java
          
          /lucene/src/test/org/apache/lucene/codecs/preflexrw/PreFlexFieldsWriter.java
          /lucene/src/test/org/apache/lucene/codecs/preflexrw/PreFlexRWCodec.java
          /lucene/src/test/org/apache/lucene/codecs/preflexrw/TermInfosWriter.java
          /lucene/src/test/org/apache/lucene/codecs/mockrandom/MockRandomCodec.java
          
          /lucene/src/test/org/apache/lucene/store/_TestHelper.java
          /lucene/src/test/org/apache/lucene/store/MockDirectoryWrapper.java
          /lucene/src/test/org/apache/lucene/store/MockIndexInputWrapper.java
          /lucene/src/test/org/apache/lucene/store/MockIndexOutputWrapper.java
          
          /lucene/src/test/org/apache/lucene/util/automaton/AutomatonTestUtil.java
          

          Also, I think "jar-core-test" should be in build.xml and not common-build.xml - it should only be run from the root folder.

          +1

          Show
          Simon Willnauer added a comment - Hey shai, I just collected some classes I would find useful for testing applications. /lucene/src/test/org/apache/lucene/util/_TestUtil.java /lucene/src/test/org/apache/lucene/util/LineFileDocs.java /lucene/src/test/org/apache/lucene/util/LuceneJUnitDividingSelector.java /lucene/src/test/org/apache/lucene/util/LuceneJUnitResultFormatter.java /lucene/src/test/org/apache/lucene/util/LuceneTestCase.java /lucene/src/test/org/apache/lucene/search/QueryUtils.java /lucene/src/test/org/apache/lucene/analysis/BaseTokenStreamTestCase.java /lucene/src/test/org/apache/lucene/analysis/MockAnalyzer.java /lucene/src/test/org/apache/lucene/analysis/MockPayloadAnalyzer.java /lucene/src/test/org/apache/lucene/analysis/MockTokenFilter.java /lucene/src/test/org/apache/lucene/analysis/MockTokenizer.java /lucene/src/test/org/apache/lucene/index/MockIndexInput.java /lucene/src/test/org/apache/lucene/index/RandomIndexWriter.java /lucene/src/test/org/apache/lucene/index/DocHelper.java /lucene/src/test/org/apache/lucene/codecs/preflexrw/PreFlexFieldsWriter.java /lucene/src/test/org/apache/lucene/codecs/preflexrw/PreFlexRWCodec.java /lucene/src/test/org/apache/lucene/codecs/preflexrw/TermInfosWriter.java /lucene/src/test/org/apache/lucene/codecs/mockrandom/MockRandomCodec.java /lucene/src/test/org/apache/lucene/store/_TestHelper.java /lucene/src/test/org/apache/lucene/store/MockDirectoryWrapper.java /lucene/src/test/org/apache/lucene/store/MockIndexInputWrapper.java /lucene/src/test/org/apache/lucene/store/MockIndexOutputWrapper.java /lucene/src/test/org/apache/lucene/util/automaton/AutomatonTestUtil.java Also, I think "jar-core-test" should be in build.xml and not common-build.xml - it should only be run from the root folder. +1
          Hide
          Uwe Schindler added a comment -

          +1, the main problem with this JAR file is currently that it's useless as you cannot run the tests from it (mainly because lots of tests need the test indexes as real files in the classpath). Its only useful to get e.g. LuceneTestCase and Mock*.

          I was thinking of putting the whole test base classes into a separate folder and compile separate before the main task. The problem with selecting a subset of .class files from an already built tree is, that you cannot be sure that the extraction is self-contained (so there are lots of dependencies and all those anonymous inner classes).

          Show
          Uwe Schindler added a comment - +1, the main problem with this JAR file is currently that it's useless as you cannot run the tests from it (mainly because lots of tests need the test indexes as real files in the classpath). Its only useful to get e.g. LuceneTestCase and Mock*. I was thinking of putting the whole test base classes into a separate folder and compile separate before the main task. The problem with selecting a subset of .class files from an already built tree is, that you cannot be sure that the extraction is self-contained (so there are lots of dependencies and all those anonymous inner classes).
          Hide
          Shai Erera added a comment -

          The generated .jar is too big (7 MB) for someone to do something useful with it. Mostly because it contains the test indices and all the test classes. I think instead we should have a tiny .jar with few selected files that comprise our 'test framework'. I found a way to do that in Ant, so I'll add a patch shortly. Also, I think "jar-core-test" should be in build.xml and not common-build.xml – it should only be run from the root folder.

          Show
          Shai Erera added a comment - The generated .jar is too big (7 MB) for someone to do something useful with it. Mostly because it contains the test indices and all the test classes. I think instead we should have a tiny .jar with few selected files that comprise our 'test framework'. I found a way to do that in Ant, so I'll add a patch shortly. Also, I think "jar-core-test" should be in build.xml and not common-build.xml – it should only be run from the root folder.
          Hide
          Simon Willnauer added a comment -

          think it'll be more compelling to users, than a 7 MB .jar, no?

          I think this includes the testindices for bw. etc. too - I think Shai is right here - did you have any particular class in mind grant?

          simon

          Show
          Simon Willnauer added a comment - think it'll be more compelling to users, than a 7 MB .jar, no? I think this includes the testindices for bw. etc. too - I think Shai is right here - did you have any particular class in mind grant? simon
          Hide
          Shai Erera added a comment -

          Was the purpose of this issue to create a .jar with all test classes, or just the classes that comprise the framework, e.g. LuceneTestCase, MockAnalyzer, RandomIndexWriter etc.? I was thinking we want to publish just a select few of classes with perhaps a README which explains what each class does. I think it'll be more compelling to users, than a 7 MB .jar, no?

          Show
          Shai Erera added a comment - Was the purpose of this issue to create a .jar with all test classes, or just the classes that comprise the framework, e.g. LuceneTestCase, MockAnalyzer, RandomIndexWriter etc.? I was thinking we want to publish just a select few of classes with perhaps a README which explains what each class does. I think it'll be more compelling to users, than a 7 MB .jar, no?
          Hide
          Drew Farris added a comment -

          Grant, What version of maven-ant-tasks are you running? I recall having a similar problem until I updated to 2.1.1 (with ant 1.7.1)

          Show
          Drew Farris added a comment - Grant, What version of maven-ant-tasks are you running? I recall having a similar problem until I updated to 2.1.1 (with ant 1.7.1)
          Hide
          Grant Ingersoll added a comment -

          The issue is the artifact id, etc. are not being set. There is some Ant variable $

          {maven.final.build.name}

          or something that is not set, AFAICT.

          Show
          Grant Ingersoll added a comment - The issue is the artifact id, etc. are not being set. There is some Ant variable $ {maven.final.build.name} or something that is not set, AFAICT.
          Hide
          Grant Ingersoll added a comment -

          Both trunk and 3.x of Lucene.

          Show
          Grant Ingersoll added a comment - Both trunk and 3.x of Lucene.
          Hide
          Drew Farris added a comment -

          Grant, I'll take a look. So I can reproduce the issue you're running into, which directory are you executing 'ant generate-maven-artifacts' from, branch_3x or branch_3x/lucene?

          Show
          Drew Farris added a comment - Grant, I'll take a look. So I can reproduce the issue you're running into, which directory are you executing 'ant generate-maven-artifacts' from, branch_3x or branch_3x/lucene?
          Hide
          Grant Ingersoll added a comment -

          ant generate-maven-artifacts does not appear to work. I don't think it is the fault of this patch, but until it does, I can't test this.

          Show
          Grant Ingersoll added a comment - ant generate-maven-artifacts does not appear to work. I don't think it is the fault of this patch, but until it does, I can't test this.
          Hide
          Drew Farris added a comment -

          Grant, thanks for taking the time to look at this.

          The -tests jar is similar in nature to the -src and -javadoc jars. It gets pushed to the maven repo by virtue of attaching it to the core jar artifact. A separate pom is not needed in this case and the tests jar can be added as a dependency using something like the following:

              <dependency>
                <groupId>org.apache.lucene</groupId>
                <artifactId>lucene-core</artifactId>
                <version>${lucene.version}</version>
                <classifier>tests</classifier>
                <scope>test</scope>
              </dependency>
          

          Good point about including the -tests jar in the dist. This updated patch adds the -tests jar to the distribution. The core-javadoc and core-src, demo-javadoc and demo-src files were also not present in the distribution so I added these as well.

          Show
          Drew Farris added a comment - Grant, thanks for taking the time to look at this. The -tests jar is similar in nature to the -src and -javadoc jars. It gets pushed to the maven repo by virtue of attaching it to the core jar artifact. A separate pom is not needed in this case and the tests jar can be added as a dependency using something like the following: <dependency> <groupId>org.apache.lucene</groupId> <artifactId>lucene-core</artifactId> <version>${lucene.version}</version> <classifier>tests</classifier> <scope>test</scope> </dependency> Good point about including the -tests jar in the dist. This updated patch adds the -tests jar to the distribution. The core-javadoc and core-src, demo-javadoc and demo-src files were also not present in the distribution so I added these as well.
          Hide
          Grant Ingersoll added a comment -

          Drew,

          If you want this to be pub'd as a maven dependency, it's going to need a POM template for it. Also, I don't see the files actually included in the distribution (ant dist)

          -Grant

          Show
          Grant Ingersoll added a comment - Drew, If you want this to be pub'd as a maven dependency, it's going to need a POM template for it. Also, I don't see the files actually included in the distribution (ant dist) -Grant
          Hide
          Drew Farris added a comment -

          Here's the patch.

          Show
          Drew Farris added a comment - Here's the patch.

            People

            • Assignee:
              Steve Rowe
              Reporter:
              Drew Farris
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development