I am not wedded to changing or not changing a convention -- both strike me as equally valid. The question is what works of course.
My understanding is that the dependency is definitely in lib/, but still isn't working. That was my experience too. So I am not sure if it's a question of having the right thing in there? I'm maybe being dense but what is the way forward then? I have one answer on the table FWIW. On Mon, May 9, 2011 at 2:30 PM, Benson Margulies <[email protected]> wrote: > I see no reason to stop using the 'lib/' convention in our jobs. > > There are apparently plenty of people out there who don't know > anything about the distributed cache. If we require it's use to run > simple jobs, we're going to be up to our ears in support email. > > I favor the following strategy: > > 1) Make sure that the split between 'libs/' and unpacked classes in > our job jars is *correct* so that all the operations of the mahout > command work out of the box. > > 2) post 0.5, act on the proposed refactoring so that none of our code > is calling setJarFromClass in a way that forces users to do complex > re-shading for themselves. That's the 'bean' proposal, in which each > of our jobs is a bean, and a user who wants to combine ours and theirs > can make their own call to setJar/setJarFromClass appropriately. >
