Hi,
I took Grant's advice (Fernando, I would say just go ahead and put your
patch up against core for now and we'll work this out. This discussion
shouldn't derail you from putting up a reasonable first patch based on the
current structure -- i.e. put the model where all the other impl. models are
Of course. I agree about JDBC. In practice, since JDBC APIs are a part of
core Java, not JavaEE, it doesn't really do any harm dependency-wise to
leave it in core. But it can move too indeed just for theoretical reasons.
On Wed, May 18, 2011 at 2:54 PM, Grant Ingersoll wrote:
>
> One person's core
On May 18, 2011, at 9:32 AM, Sean Owen wrote:
> On Wed, May 18, 2011 at 12:58 PM, Grant Ingersoll wrote:
>
>>
>> Actually, I think it is core at this point, since we moved the
>> Vectorization stuff to core. Unfortunately, we need Lucene core in order to
>> get the baseline definitions of Toke
On Wed, May 18, 2011 at 12:58 PM, Grant Ingersoll wrote:
>
> Actually, I think it is core at this point, since we moved the
> Vectorization stuff to core. Unfortunately, we need Lucene core in order to
> get the baseline definitions of TokenStreams for Vectorization.
>
Scratch that, yeah it's re
On May 18, 2011, at 6:58 AM, Sean Owen wrote:
> The reasoning that led to 'taste-webapp' is what leads to create an expanded
> 'mahout-integration'.
>
> When I contributed my code, some folks asked, hmm, could we toss your EJB
> and web services integration, because it seems unfortunate to make
The reasoning that led to 'taste-webapp' is what leads to create an expanded
'mahout-integration'.
When I contributed my code, some folks asked, hmm, could we toss your EJB
and web services integration, because it seems unfortunate to make the whole
build depend on the EJB APIs and the Axis servic
(Fernando, I would say just go ahead and put your patch up against core for now
and we'll work this out. This discussion shouldn't derail you from putting up
a reasonable first patch based on the current structure -- i.e. put the model
where all the other impl. models are for now)
On May 18, 2
Plausible.
On Wed, May 18, 2011 at 3:31 AM, Sean Owen wrote:
> It happens that this, and the one thing that lives in taste-webapp, concern
> one part of Mahout. There are many other things that can live in such a
> module, and I don't see why we'd restrict it? For example, think about
> integrat
It happens that this, and the one thing that lives in taste-webapp, concern
one part of Mahout. There are many other things that can live in such a
module, and I don't see why we'd restrict it? For example, think about
integration points with Lucene from examples. They really aren't "examples"
but
But this is really totally focussed on integration of taste, isn't it? What
other integration is there?
On Wed, May 18, 2011 at 2:53 AM, Sean Owen wrote:
> Just make it more general still to expand its purpose to something more
> reasonable: mahout-integration. I think some stuff from examples
Just make it more general still to expand its purpose to something more
reasonable: mahout-integration. I think some stuff from examples can move
over there, those things which are really utilities for connecting to some
other system or project. It is something different from examples; it is
non-co
+1 on something like "taste-integration" as a module instead of the poorly
named thing we have now.
On May 18, 2011, at 2:19 AM, Sean Owen wrote:
> There's no web app in here, it's just code that imports MongoDB
> classes. Yes it can be made 'provider' scope; it still means a lesser
> overhead o
Yeah, maybe I explained bad. I attached on this email just the DataModel.
The rest of the email, REST service, console, recommender etc, are related
to this file http://dl.dropbox.com/u/17178183/Recommender.zip. That was for
testing the DataModel and see a real example of MongoDataModel running
There's no web app in here, it's just code that imports MongoDB
classes. Yes it can be made 'provider' scope; it still means a lesser
overhead of downloading the dependency. (kfs has been removed BTW.) I
think we have the answer of farming this out to an 'integration'
module that was have already u
I don't see a problem with an extra module if the webapp can somehow resolve
the reference at run-time.
And if the artifacts are in Maven, how bad is it to include them as
dependencies? If these could be made optional dependencies with "provided"
scope, then anybody who doesn't use them wouldn't
Weird as it sounds, I think the best place is mahout-taste-webapp.
Once the module is renamed it'll make more sense. But if you make a
patch against that module with the right pom.xml changes it ought to
be 99.9% what is needed.
On Tue, May 17, 2011 at 10:23 PM, Fernando Tapia Rico
wrote:
> yep,
yep, I completely understand your concerns. So...What should I do? cos
I guess that I need to know where to place this to open the JIRA
ticket. I don't have any rush, I can wait until you guys decide what
is the best option for this DataModel.
On Tuesday, May 17, 2011, Sean Owen wrote:
> I'm talk
I'm talking about the DataModel -- there isn't a Recommender, is
there? (Haven't looked at the code.)
No, I mean that we don't want to introduce a dependency on MongoDB
across the whole project just for this, but it could fit into an
optional sub-module.
On Tue, May 17, 2011 at 10:10 PM, Fernando
Thanks for the good responses. I will open a JIRA ticket, but...reading the
thread...where should I put this DataModel?
And, Sean, when you say "I would commit this to mahout-examples/ in a
heartbeat except that I'm
wondering about the issue of dependencies", are you talking about the
Recommender o
It probably belongs in a renamed "mahout-taste-webapp" which is where
we put the one similar thing in the project already. That can be
"mahout-integration" or something.
(Separately I'm conscious of an explosion of Maven modules... this
isn't adding a new one, but, getting to be a lot of them.)
O
Hmm, the license is AGPL, but then the drivers are ASL for MongoDB. What does
this patch require?
I suspect we will have other DataModels. I have heard interest in adding a
Cassandra DataModel as well. Not sure if they belong in examples, but also
agree they aren't "core" per se. Thoughts
Agree, that's the process, and agree this is cool.
I would commit this to mahout-examples/ in a heartbeat except that I'm
wondering about the issue of dependencies. It introduces a dependency
on MongoDB in Maven just for this. Is that fine for examples, we
think? It's not for core.
On Tue, May 17
; with the community (and be a Mahout contributor). I'm attaching the java
> source, and here is a taste recommender using this DataModel
> (http://dl.dropbox.com/u/17178183/Recommender.zip). This project contains
> some unit tests src/test/TestMongoDataModel for the MongoDataMode
ntributor). I'm attaching
the java source, and here is a taste recommender using this DataModel (
http://dl.dropbox.com/u/17178183/Recommender.zip). This project contains
some unit tests *src/test/TestMongoDataModel* for the MongoDataModel. It
also includes a test console in *src/TestStarter. *
**An
24 matches
Mail list logo
