Thanks for affirming this Ron. By the way, how do you ensure that all those projects depend on the same set of external dependences without duplicating the information for each POM?
Cheers, Behrang Saeedzadeh http://www.behrang.org On Tue, Sep 27, 2011 at 2:17 AM, Ron Wheeler <rwhee...@artifact-software.com> wrote: > I agree. > > 4- better visibility into the project for the manager. You know which > modules are being changed and which ones are supposed to remain unchanged. > You also get a bit of a warning about scope issues or potential problems > when a new module gets added to the list of things that need changing after > the development plan has been set. > > 5- more sense of responsibility for testing and the deploying of new > SNAPSHOTs and releases. The functional definition of the module tends to be > clearer if it is deployed to the team even if it is only a SNAPSHOT. The > team expects a personal guaranty to go with a deploy. > This tends to make programmers more careful about testing and documenting > functionality of stubs and SNAPSHOTs with partial functionality as well as > fully functional modules. > > Ron > > On 26/09/2011 11:48 AM, Behrang Saeedzadeh wrote: >> >> Hi, >> >> For large projects, wouldn't multiple single module projects work better >> than one multi-module project, because: >> >> 1- when using a dvcs, the repositories tend to become very large and when >> the project is divided into multiple single module projects, each project >> can have a small dvcs repository compared to one large monolithic repo. >> 2- new developers can be exposed only to the subset of projects that they >> need to work with >> 3- finer grained security over which developers can see which parts of the >> project >> >> Thanks in advance, >> Behrang >> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
