continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Atkinson <brent.atkin...@gmail.com>
Subject Project module granularity
Date Sat, 17 May 2014 17:02:38 GMT
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?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message