You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mahout.apache.org by Jake Mannix <ja...@gmail.com> on 2013/07/05 10:23:19 UTC

--libjars deployment?

I forget, I know our "default" deployment is via the shaded monojar, but do
we also have an option somewhere to allow running with --libjars instead?
 Much more rsync-friendly for rapid prototyping (esp. when on slooooow
remote connections).

-- 

  -jake

Re: --libjars deployment?

Posted by Ted Dunning <te...@gmail.com>.
Ahh... that is a fine feature.

Have you considered filing a JIRA?

(smirk)


On Fri, Jul 5, 2013 at 9:06 AM, Jake Mannix <ja...@gmail.com> wrote:

> We basically *do* build both kinds, but I was just referring to our helper
> bin/mahout script - it would be nice if it had a simple way to launch jobs
> collecting the $MAHOUT_HOME/lib/*.jar elements, and adding them directly to
> a -libjars line.
>
> Nothing rocket science - it's easy enough to leave to the user, but making
> it really easy to just take your mahout install, then drop some extra jars
> in $MAHOUT_HOME/lib, and then $MAHOUT_HOME/bin/mahout ... will just pick
> these up and use them in any job that they want to run.
>
>
> On Fri, Jul 5, 2013 at 8:47 AM, Ted Dunning <te...@gmail.com> wrote:
>
> > On Fri, Jul 5, 2013 at 7:19 AM, Jake Mannix <ja...@gmail.com>
> wrote:
> >
> > > But also: Monster Jars Considered Harmful, so I should dredge up a
> deploy
> > > flag or something which allows us to run seamlessly with small jar +
> > > libjars instead (so people [incl. me] can tack on their own jars by
> > > modifying the libjar classpath instead of having to modify the build
> > > itself).
> > >
> >
> > I don't think we need a flag.  We can build both kinds always (according
> to
> > me and nobody else just yet).
> >
>
>
>
> --
>
>   -jake
>

Re: --libjars deployment?

Posted by Jake Mannix <ja...@gmail.com>.
We basically *do* build both kinds, but I was just referring to our helper
bin/mahout script - it would be nice if it had a simple way to launch jobs
collecting the $MAHOUT_HOME/lib/*.jar elements, and adding them directly to
a -libjars line.

Nothing rocket science - it's easy enough to leave to the user, but making
it really easy to just take your mahout install, then drop some extra jars
in $MAHOUT_HOME/lib, and then $MAHOUT_HOME/bin/mahout ... will just pick
these up and use them in any job that they want to run.


On Fri, Jul 5, 2013 at 8:47 AM, Ted Dunning <te...@gmail.com> wrote:

> On Fri, Jul 5, 2013 at 7:19 AM, Jake Mannix <ja...@gmail.com> wrote:
>
> > But also: Monster Jars Considered Harmful, so I should dredge up a deploy
> > flag or something which allows us to run seamlessly with small jar +
> > libjars instead (so people [incl. me] can tack on their own jars by
> > modifying the libjar classpath instead of having to modify the build
> > itself).
> >
>
> I don't think we need a flag.  We can build both kinds always (according to
> me and nobody else just yet).
>



-- 

  -jake

Re: --libjars deployment?

Posted by Ted Dunning <te...@gmail.com>.
On Fri, Jul 5, 2013 at 7:19 AM, Jake Mannix <ja...@gmail.com> wrote:

> But also: Monster Jars Considered Harmful, so I should dredge up a deploy
> flag or something which allows us to run seamlessly with small jar +
> libjars instead (so people [incl. me] can tack on their own jars by
> modifying the libjar classpath instead of having to modify the build
> itself).
>

I don't think we need a flag.  We can build both kinds always (according to
me and nobody else just yet).

Re: --libjars deployment?

Posted by Jake Mannix <ja...@gmail.com>.
Yeah, I remember that now, will resume using that trick.

But also: Monster Jars Considered Harmful, so I should dredge up a deploy
flag or something which allows us to run seamlessly with small jar +
libjars instead (so people [incl. me] can tack on their own jars by
modifying the libjar classpath instead of having to modify the build
itself).


On Fri, Jul 5, 2013 at 1:29 AM, Ted Dunning <te...@gmail.com> wrote:

> I find that rsync -zav does wonders on sending monster jars.  It seems to
> understand small changes in the jar and only sends a small amount of data.
>
> Never have dug into why.  It just seems unreasonably efficient to be
> otherwise.
>
>
> On Fri, Jul 5, 2013 at 1:23 AM, Jake Mannix <ja...@gmail.com> wrote:
>
> > I forget, I know our "default" deployment is via the shaded monojar, but
> do
> > we also have an option somewhere to allow running with --libjars instead?
> >  Much more rsync-friendly for rapid prototyping (esp. when on slooooow
> > remote connections).
> >
> > --
> >
> >   -jake
> >
>



-- 

  -jake

Re: --libjars deployment?

Posted by Ted Dunning <te...@gmail.com>.
I find that rsync -zav does wonders on sending monster jars.  It seems to
understand small changes in the jar and only sends a small amount of data.

Never have dug into why.  It just seems unreasonably efficient to be
otherwise.


On Fri, Jul 5, 2013 at 1:23 AM, Jake Mannix <ja...@gmail.com> wrote:

> I forget, I know our "default" deployment is via the shaded monojar, but do
> we also have an option somewhere to allow running with --libjars instead?
>  Much more rsync-friendly for rapid prototyping (esp. when on slooooow
> remote connections).
>
> --
>
>   -jake
>