[ 
https://issues.apache.org/jira/browse/MAHOUT-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Drew Farris updated MAHOUT-301:
-------------------------------

    Attachment: MAHOUT-301-drew.patch

Did some testing, here's a patch to clean some of these things up + a couple 
questions: 

Could we load the default driver.classes.props from the classpath? If it was 
loaded that way the default would work regardless of where the mahout script is 
run from (it currently only works if ./bin/mahout is run, not ./mahout for 
example) and regardless of whether we're running from a binary release or the 
dev environment. (included in patch)

Something else I noticed is that the 'mahout' script doesn't add the classes in 
$MAHOUT_HOME/lib/*.jar to the classpath. This breakes the binary release in 
that it can't run anything, e.g:

{code}
./mahout vectordump
Exception in thread "main" java.lang.NoClassDefFoundError: 
org/apache/commons/cli2/OptionException
Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.cli2.OptionException
{code}
(fixed in patch)

Using -core in the context of a dev build should work properly, but leaving out 
-core will cause the script to error unless run in the context of a release -- 
this is the way it should work, right?

Also wondering what the purpose of adding the job jars to the classpath is? 
(removed in patch)

Also added a help message for the 'run' argument.

Does executing './mahout run --help' hang for anyone else or is it something 
specific to my environment? (didn't track this one down)

> Improve command-line shell script by allowing default properties files
> ----------------------------------------------------------------------
>
>                 Key: MAHOUT-301
>                 URL: https://issues.apache.org/jira/browse/MAHOUT-301
>             Project: Mahout
>          Issue Type: New Feature
>          Components: Utils
>    Affects Versions: 0.3
>            Reporter: Jake Mannix
>            Assignee: Jake Mannix
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: MAHOUT-301-drew.patch, MAHOUT-301.patch, 
> MAHOUT-301.patch, MAHOUT-301.patch
>
>
> Snippet from javadoc gives the idea:
> {code}
> /**
>  * General-purpose driver class for Mahout programs.  Utilizes 
> org.apache.hadoop.util.ProgramDriver to run
>  * main methods of other classes, but first loads up default properties from 
> a properties file.
>  *
>  * Usage: run on Hadoop like so:
>  *
>  * $HADOOP_HOME/bin/hadoop -jar path/to/job 
> org.apache.mahout.driver.MahoutDriver [classes.props file] shortJobName \
>  *   [default.props file for this class] [over-ride options, all specified in 
> long form: --input, --jarFile, etc]
>  *
>  * TODO: set the Main-Class to just be MahoutDriver, so that this option 
> isn't needed?
>  *
>  * (note: using the current shell scipt, this could be modified to be just 
>  * $MAHOUT_HOME/bin/mahout [classes.props file] shortJobName [default.props 
> file] [over-ride options]
>  * )
>  *
>  * Works like this: by default, the file 
> "core/src/main/resources/driver.classes.prop" is loaded, which
>  * defines a mapping between short names like "VectorDumper" and fully 
> qualified class names.  This file may
>  * instead be overridden on the command line by having the first argument be 
> some string of the form *classes.props.
>  *
>  * The next argument to the Driver is supposed to be the short name of the 
> class to be run (as defined in the
>  * driver.classes.props file).  After this, if the next argument ends in 
> ".props" / ".properties", it is taken to
>  * be the file to use as the default properties file for this execution, and 
> key-value pairs are built up from that:
>  * if the file contains
>  *
>  * input=/path/to/my/input
>  * output=/path/to/my/output
>  *
>  * Then the class which will be run will have it's main called with
>  *
>  *   main(new String[] { "--input", "/path/to/my/input", "--output", 
> "/path/to/my/output" });
>  *
>  * After all the "default" properties are loaded from the file, any further 
> command-line arguments are taken in,
>  * and over-ride the defaults.
>  */
> {code}
> Could be cleaned up, as it's kinda ugly with the whole "file named in 
> .props", but gives the idea.  Really helps cut down on repetitive long 
> command lines, lets defaults be put props files instead of locked into the 
> code also.

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

Reply via email to