It sounds good, but there's a medium size in which it doesn't quite work out this way. You can't create a new maven module for every single class. Thus, in my experience, we have ended up with some sort of 'common' component that (a) gets a lot of changes and (b) has many things that depend on it -- at least in the early phases of building out a large system. Over time, that component slows down, or even splits up.
On Mon, May 9, 2011 at 11:10 AM, Ron Wheeler <[email protected]> wrote: > On 09/05/2011 10:42 AM, Wayne Fay wrote: >>> >>> As far as I can tell, Option 1 is only practical once the velocity of >>> change slows down to the point where at least some components sit >>> unchanged for a good long time -- that is, for more than one >>> development iteration. It's only useful to 'use a version with a >> >> But it seems like a good (best?) practice to break modules up into >> functional components such that parts which have no reason to change >> for a given release are not changed. If you find it annoying that a >> small change in a small piece of code that is wrapped up inside a much >> larger library means the entire library has to bump a version, you may >> want to consider breaking the smaller bits out into its own >> independent module. Especially if the velocity of change in those >> small bits is significantly greater than the velocity of the rest of >> the bits. >> >> This does mean that you may end up with 150 modules rather than 70. >> Suddenly your processes which were OK at 70 modules are really not >> working with 150, so you may need to be willing to adjust your >> processes etc as well. > > +1 > More robust structure > Easier to assure that small functional modules are working correctly > Easier to test libraries than applications - usually. > Increases likeliness of sharing of code. > > Lots of other good reasons to do this. > > Maven and Nexus makes it easy to manage this. > > Ron >> >> Wayne >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
