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

Shai Erera commented on LUCENE-1591:
------------------------------------

That's strange ...
About the build.xml, I think the problem lies in line 110, where the classpath 
defines explicit jars. I changed it to:
{code}
    <path id="classpath">
        <pathelement path="${common.dir}/build/classes/java"/>
        <pathelement path="${common.dir}/build/classes/demo"/>
        <pathelement 
path="${common.dir}/build/contrib/highlighter/classes/java"/>
        <fileset dir="lib">
                <include name="**/*.jar"/>
        </fileset>
    </path>
{code}
and it compiled successfully. I think this change is good since it will prevent 
such problems in the future (in case more dependencies will be added).

About the test failures - they pass for me in eclipse however fail in Ant. I 
believe I know the reason - previously, WriteLineDocTask's ctor logic was in 
its setUp method. I moved it to ctor since setUp is called for every document, 
and the initialization there did not seem right to me. The "line.file.out' 
property is indeed mandatory, and hence the exception.
The reason it doesn't fail in eclipse is because this task is not explicitly 
defined in findTasks(), and I don't have the "tasks.dir" env variable defined. 
As soon as I add this line:
{code}
tsks.add(  " WriteLineDoc             "  );
{code}
to findTasks(), the test fails.

I see several ways to solve it:
* Make line.file.doc optional, and if not set create ByteArrayOutputStream, 
instead of FileOutputStream. This can also help the tests not create 
unnecessary files.
* Move the logic back to setup while checking a boolean if we've been 
initialized yet. I don't like it very much - I think setup and teardown should 
be reseved for per-doLogic call.
* Add INDENT+"line.file.out=test/line.file" + NEW_LINE to 
TestPerfTasksParse.propPart. I don't like it too since propPart is reserved for 
properties that are common for all tasks.
I like (1) most.


> Enable bzip compression in benchmark
> ------------------------------------
>
>                 Key: LUCENE-1591
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1591
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: contrib/benchmark
>            Reporter: Shai Erera
>             Fix For: 2.9
>
>         Attachments: commons-compress-dev20090413.jar, 
> commons-compress-dev20090413.jar, LUCENE-1591.patch, LUCENE-1591.patch, 
> LUCENE-1591.patch, LUCENE-1591.patch
>
>
> bzip compression can aid the benchmark package by not requiring extracting 
> bzip files (such as enwiki) in order to index them. The plan is to add a 
> config parameter bzip.compression=true/false and in the relevant tasks either 
> decompress the input file or compress the output file using the bzip streams.
> It will add a dependency on ant.jar which contains two classes similar to 
> GZIPOutputStream and GZIPInputStream which compress/decompress files using 
> the bzip algorithm.
> bzip is known to be superior in its compression performance to the gzip 
> algorithm (~20% better compression), although it does the 
> compression/decompression a bit slower.
> I wil post a patch which adds this parameter and implement it in 
> LineDocMaker, EnwikiDocMaker and WriteLineDoc task. Maybe even add the 
> capability to DocMaker or some of the super classes, so it can be inherited 
> by all sub-classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to