deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: [DISCUSS] Modularity for reusable parts
Date Thu, 05 Apr 2012 14:02:24 GMT
I'm fine for either way really. i18n and catch I believe would be
relatively small (I know Catch is).

On Thu, Apr 5, 2012 at 07:24, Pete Muir <pmuir@redhat.com> wrote:

> 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 <pmuir@redhat.com>
> >> To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> struberg@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
> >>>
> >>
>
>


-- 
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message