You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Mark Struberg <st...@yahoo.de> on 2012/04/05 10:44:04 UTC
[DISCUSS] Modularity for reusable parts
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
Re: [DISCUSS] Modularity for reusable parts
Posted by Mark Struberg <st...@yahoo.de>.
yup +1
LieGrue,
strub
>________________________________
> From: Jason Porter <li...@gmail.com>
>To: deltaspike-dev@incubator.apache.org
>Cc: Mark Struberg <st...@yahoo.de>
>Sent: Thursday, April 5, 2012 4:02 PM
>Subject: Re: [DISCUSS] Modularity for reusable parts
>
>
>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 <pm...@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 <pm...@redhat.com>
>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@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
>
>
>
Re: [DISCUSS] Modularity for reusable parts
Posted by Jason Porter <li...@gmail.com>.
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 <pm...@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 <pm...@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
Re: [DISCUSS] Modularity for reusable parts
Posted by Pete Muir <pm...@redhat.com>.
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 <pm...@redhat.com>
>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@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
>>>
>>
Re: [DISCUSS] Modularity for reusable parts
Posted by Mark Struberg <st...@yahoo.de>.
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 <pm...@redhat.com>
> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@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
>>
>
Re: [DISCUSS] Modularity for reusable parts
Posted by Pete Muir <pm...@redhat.com>.
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
>
Re: [DISCUSS] Modularity for reusable parts
Posted by Gerhard Petracek <ge...@gmail.com>.
+1 for fine-grained modules
we have to provide bundles to be compatible with some application servers
(in any case)
-> if users don't like the fine-grained modules, they can use the bundles.
regards,
gerhard
2012/4/5 Mark Struberg <st...@yahoo.de>
> 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
>
>