continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Gruber" <>
Subject Re: Project module granularity
Date Sun, 18 May 2014 16:37:06 GMT
As an effective outsider (haven't really dealt with continuum or archive 
in a long time) I can back up this suggestion from my own experience 
with maven modules.  I have found that artifact divisions on component 
lines can be useful, but overkill, and a public API, (if relevant) SPI 
for extenders, and internal implementation artifacts are a useful 
division that balances things out and makes builds faster, etc.

It is also useful that artifacts split on major boundaries of 
cohesion/coupling where reuse is desired. That is, if something is 
realistically suitable for re-use in other projects, it's reasonable to 
have an artifact on it - but at that point it really becomes another 
project.  When to do that is really an art.  But I tend to try to 
reserve such extraction to really highly valuable libraries where the 
bang-for-buck ratio is high enough to justify the extra overhead 
(conceptual and computational in the build).

/shrug - sorry to bike shed, but I think the idea has merit and no one 
was really responding to Brent.


On 17 May 2014, at 10:02, Brent Atkinson wrote:

> Hi,
> This is mainly a background question, but is prompted by observations 
> I
> have had while working in the code base. The general question is, can 
> the
> project be simpler to work on and the build speed improved by removing 
> or
> redrawing module boundaries?
> An example of this is what has been undertaken in Archiva recently, 
> where
> redback has been pulled up into the project. This essentially makes 
> redback
> part of the project so there it can more easily track with the 
> project.
> This was something I didn't appreciate until we had to consider 
> reworking
> all of the Struts 2 actions, etc. to update it for security reasons. 
> It
> would be nice to just replace what redback was doing with spring 
> security,
> but moving incrementally is more difficult with redback as a separate
> project.
> Another example is whether the degree to which project modules make 
> sense
> as modules. In the extreme, we might consider regrouping the existing
> classes into external API, internal API, core implementation, and 
> maybe a
> few more. The goal would be to reduce the number of independent 
> modules to
> as close to 1 as possible. I'm curious about this because it seems the
> coarser granularity could simplify the project considerably and 
> possibly
> speed up the compile/test cycle. I tried looking through the archive 
> for
> similar conversations and couldn't find any.
> Have these been considered? Thoughts?

Christian Gruber -

View raw message