On Sun, Apr 10, 2011 at 10:07 AM, Dhruv Kumar <[email protected]> wrote:

> 1. Automatic and incremental build: Being new to maven, I'm a little
> confused. While updating the code, the Maven console in Eclipse reports
> either the auto build or the incremental build:
>
> 4/10/11 12:11:02 PM EDT: Maven Builder: AUTO_BUILD
> 4/10/11 12:11:02 PM EDT: Maven Builder: AUTO_BUILD
> 4/10/11 12:12:26 PM EDT: Maven Builder: AUTO_BUILD
> 4/10/11 12:13:02 PM EDT: Maven Builder: INCREMENTAL_BUILD
>
> These messages are triggered every time I make changes to the code. I
> looked
> into the pom.xml and it lists the 1.6 as the version of the Sun's javac to
> be used for compilation. As far as I know, the javac is not an incremental
> builder, however the Eclipse's compiler is. How is this possible? Also,
> what
> is the difference between AUTO_BUILD and INCREMENTAL_BUILD?
>

Sorry.  I can't help you here.  IntelliJ reads pom's directly and does
incremental compilation magically based on the project structure when I am
debugging.  It also supports executing maven tasks from the GUI so that when
I want a complete rebuild, I just use that.  For well structured projects a
maven rebuild without tests and without a clean only takes 10-30 seconds so
it isn't a big deal.  The intelliJ mediated builds typically take a second
or two.

The upshot is that the compile business fades into background noise and I
have pretty much lost all awareness of the details.

I like that.


> 2. Package location for Map Reduce HMM training. I noticed that the Map
> Reduce implementations of the different classifiers are located under
> different MapReduce packages (o.a.m.classifier.bayes.mapreduce.bayes,
> o.a.m.classifier.bayes.mapreduce.cbayes), whereas the Map Reduce classes of
> k-means clustering are lumped under the o.a.m.clustering and no separate
> Map
> Reduce package is introduced. What is the convention here? Keeping in mind
> extensibility in future and overall architecture of Mahout's code, where
> should I place the new HMM Baum Welch Map Reduce code:
> o.a.m.classifier.sequencelearning.hmm or
> o.a.m.classifier.sequencelearning.hmm.mapreduce or
> o.a.m.classifier.sequencelearning.hmm.mapreduce.baumwelch or somewhere
> else...
>

I don't think that we have a strong convention.

My own philosophy is that the key components of a single program should not
be scattered across multiple packages unless those components are candidates
for re-use.  Thus, I tend to put stuff in a single package until groupings
appear.  To my mind, mappers and reducers are not reasonable things to
separate since they are not germane to the problem so much as related to the
underlying mechanism.  As such, I keep them together.

YMMV

Reply via email to