On 09/05/2011 11:25 AM, Benson Margulies wrote:
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.
Every class is way too much.
Separating business functions from utilities is a good place to start.
Moving to SOA and breaking the business processes into services is a
"good thing".
This hides datastructure details from many levels and isolates
processing into services that are shared.
Functional changes start to have smaller scope and it becomes easier to
identify the modules that are affected.
Ron
On Mon, May 9, 2011 at 11:10 AM, Ron Wheeler
<rwhee...@artifact-software.com> 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: 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
---------------------------------------------------------------------
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
