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.
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 >> >
