deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Muir <>
Subject Re: [DISCUSS] Modularity for reusable parts
Date Thu, 05 Apr 2012 12:30:05 GMT
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