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]
