continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Atkinson <>
Subject Re: Project module granularity
Date Sun, 18 May 2014 18:38:35 GMT

Thank you for chiming in. I wanted to raise this for general feedback, and
I think we're somewhat safe from Parkinson's law of triviality. I don't
think we run too great a risk of bogging down in discussion about this,
especially with this list's volume at the moment.

>From my point of view, it helps to know that someone's experience agrees
with this in concept, even if it isn't based on direct experience with
Continuum or Archiva.  In my opinion the number of modules makes
development more cumbersome all around, from building to IDE integration,
to developing content.

I also raised it hoping someone with more direct experience than I have
might be able to offer insight into what value this would have, and maybe
suggest how it might make sense to tackle. I'd be very interesting in
tackling something like this myself if it makes sense.


On Sun, May 18, 2014 at 12:37 PM, Christian Gruber <>wrote:

> 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 -

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