On Sun, Apr 10, 2011 at 5:15 PM, Benson Margulies <[email protected]>wrote:
> Dhruv is using the maven eclipse plugin, which is a very immature > item. I use it. I even created (mostly) working connectors to it for > checkstyle and pmd. However, its notions of when to build and how much > to build are pretty opaque and don't shed that much light on the > fundamentals of either Eclipse or Maven. > > Yes, Eclipse + Maven (using m2eclipse) is slightly beyond my comprehension at this point too. The scattered documentation does not help much either. However, the combination "does the job", and I've been successful at all my simple unit tests against the mock driver, mapper, combiner and reducer class stubs. On the issue of package naming for training HMM using BW, I'll be putting all my classes under o.a.m.classifier.sequencelearning.hmm.mapreduce. This should allow a tight compartment for all the Map Reduce related HMM training functionality, as pointed out by everyone in this thread. Thanks for all the great feedback, Dhruv > Plenty of people still use the maven-eclipse-plugin and leave the > building in the hands of eclipse when using eclipse. > > As for package usage, my experience is that the existing of 'default' > access is a powerful reason to keep things in one package. If all the > code for some purpose is in one package, then the only things that > have to be 'public' are truly public. As soon as you split up into > multiple packages, you end up with 'public' stuff which is public only > to allow inter-package communications. So the minor notational or > grouping value of many packages is, for me, overwhelmed by the > destruction of 'public' as a meaningful indication of an 'open for > business to the outside world' API. > > On Sun, Apr 10, 2011 at 4:36 PM, Sean Owen <[email protected]> wrote: > > There is no strong convention -- do what you prefer. I would like to > > say that there's a convention to at least make Mappers and Reducers > > top-level classes. I tend to want to put Mappers and Reducers together > > in a subpackage -- I like to use packages freely. But that is a matter > > of taste. > > > > On Sun, Apr 10, 2011 at 8:36 PM, Ted Dunning <[email protected]> > wrote: > >> 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 > >> > > >
