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 >
