Agree with what has been said here, and thanks for raising the topic. I don't think there's been an explicit discussion about it within Continuum, and I think your observations are correct - many modules have gone well over the deep end in being split up, while there are things like continuum-core that contain the kitchen sink (and then some :) There are other problems too - like a lot of code duplication out of core into the build agents, and some tests that are slow due to using network or SCM operations.
The split is always a trade off. I think it's good to consolidate along the lines you described, though I'd still make special purpose code (particularly with external dependencies) separate - things like the notifier implementations, and release code. Did you want to draft a module hierarchy that we can talk through? - Brett On 19 May 2014, at 4:38 am, Brent Atkinson <brent.atkin...@gmail.com> wrote: > Christian, > > 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. > > Brent > > > On Sun, May 18, 2014 at 12:37 PM, Christian Gruber <cgru...@israfil.net>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 - christianedwardgru...@gmail.com >>
