deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject Re: [DISCUSS] Modularity for reusable parts
Date Thu, 05 Apr 2012 13:20:31 GMT
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.


----- Original Message -----
> From: Pete Muir <>
> To:; Mark Struberg <>
> 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

View raw message