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.
christian.
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 - christianedwardgru...@gmail.com
