IMO the key deciding factor is "what dependencies does it drag in". I don't think anyone is going to care if DS core is 100k or 1MB. However they don't want it dragging in the world and his wife ;-)
On 5 Apr 2012, at 14:20, Mark Struberg wrote: > Well THIS would be a real argument: any stuff which needs an additional > dependency must get it's own module in any case! > I didn't explicitly mention this in my first mail as it seems so fundamental > to me ;) > > The question is where we say: let's make an own module out of it because it's > not used that often/too large, etc. And what the corner stones of such a > decision are. > > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Pete Muir <pm...@redhat.com> >> To: deltaspike-dev@incubator.apache.org; Mark Struberg <strub...@yahoo.de> >> Cc: >> Sent: Thursday, April 5, 2012 2:30 PM >> Subject: Re: [DISCUSS] Modularity for reusable parts >> >> We also split this out originally in Seam 3 (catch from Solder, i8ln from >> Solder), and we found it was too much split. We merged catch back into core. >> >> I would say we should put both in core, assuming there is no JSF dependency >> introduced. >> >> OT: Is the message name final? I prefer i8ln as the module name, message >> makes >> me thing of JMS/messaging. i8ln is more clear. >> >> On 5 Apr 2012, at 09:44, Mark Struberg wrote: >> >>> Hi! >>> >>> This is about a quick discussion we had about how to treat small blocks of >> code which can be used in core. >>> >>> >>> The basic question is: when do we split out functionality into a new module >> and when do we add this functionality to the core? >>> >>> The current candidates are >>> >>> * catch >>> * message (i18n) >>> >>> >>> I cannot say much about catch, but for messaging here is the ham: >>> >>> In CODI, our messaging consisted of a core-message jar which contained the >> integration agnostic parts (~30 mostly simple classes). All the formatting, >> etc. >> In codi-jsf and codi-jsf2 we used those core-message parts and extended the >> functionality with the JSF integration. E.g to easily use it to create JSF >> user >> notifications. >>> >>> While the message stuff in CODI was a separate module in core, it is always >> required in codi-jsf and codi-jsf2. After thinking about it this feels >> messy. >> Either we split it into codi-jsf and message-jsf or we also merge it in core. >>> >>> That's basically the same discussion we need to have now in DeltaSpike >> as well! >>> >>> Having a bad separation is, well bad. But having too much separation and >> tons of different jars is otoh also not good. >>> >>> >>> Feel free to add more discussion points. >>> >>> LieGrue, >>> strub >>> >>
