Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of lightguard.jp@gmail.com
 designates 209.85.215.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <0B03998D-68BB-44E1-BDBA-F25E15C5F269@redhat.com>
References: <1333615444.52719.YahooMailNeo@web171503.mail.ir2.yahoo.com>
 <52C4D6E4-DFD5-4B81-B816-9EA2652CDCA9@redhat.com>
 <1333632031.33693.YahooMailNeo@web171501.mail.ir2.yahoo.com>
 <0B03998D-68BB-44E1-BDBA-F25E15C5F269@redhat.com>
From: Jason Porter <lightguard.jp@gmail.com>
Date: Thu, 5 Apr 2012 08:02:24 -0600
Message-ID: 
 <CAF9TksPpxWuZyoMhBGABqV7_e48jreBa0qeMPBFLweGZO7bznA@mail.gmail.com>
Subject: Re: [DISCUSS] Modularity for reusable parts
To: deltaspike-dev@incubator.apache.org
Cc: Mark Struberg <struberg@yahoo.de>
Content-Type: multipart/alternative; boundary=f46d04088d8b8556ad04bceefecd

--f46d04088d8b8556ad04bceefecd
Content-Type: text/plain; charset=UTF-8

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

--f46d04088d8b8556ad04bceefecd--