You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Lin Sun <li...@gmail.com> on 2008/07/18 21:51:50 UTC
Re: Remove samples myphonebook and mytime?
I agree with David - if two samples are completely duplicate we need
to remove one, given the time we need to spend to maintain them in svn
and wiki and the fact that the duplicate sample doesn't provide any
extra usage.
We should divide samples by its functionalities. At the end, the
samples are used to demonstrate a particular function, and I don't
think 3 entities or 1 entities will make a difference in helping users
consume them. It will be annoying to the user if we release two
samples with duplicate functions but we fail to update one of them due
to lack of time/resource.
I looked at bank and myphonebook closely (both are stateless ejb, and
application managed persistence context with JPA) thus I think we
should remove one of them.
mytime and calculator (yes, we changed the name from
calculator-stateless-pojo to calculator) are mostly the same too (both
are stateless ejb). The only difference is that mytime web client
uses JNDI to look up the bean while calculator client uses @EJB
annotation to inject the session bean's interface. I don't know if
it is worthy to keep them because of the difference here?
Lin
On Thu, Jun 12, 2008 at 1:41 PM, David Jencks <da...@yahoo.com> wrote:
> I think you , joe, donald, and hernan are being completely unrealistic about
> the likelihood of these samples being maintained even if they get updated
> and the value they add and the potential for total confusion for users when
> they see a bunch of samples doing exactly the same thing.
>
> Before suggesting removing them I considered the overlap. Let me restate
> the extent of overlap:
>
> bank has 3 entities, myphonebook has one. To me this is 100% overlap
>
> mytime and calculator-stateless both demonstrate a stateless ejb with no
> connection to the outside world. Again to me this is 100% overlap.
>
> Rather than spending our non-existent energy maintaining a bunch of badly
> written samples that do exactly the same thing I'd rather see some faintly
> more realistic samples with a broader range such as an ejb that sends jms
> messages and a jsf sample. There's also a lot of room for improvements in
> the samples I think we should keep such as:
>
> - having the web client in a different war than the jaxws service in the
> jaxws example
> - having an ejb that sends messages in the jms example, probably in a
> different ejb jar.
> - actually saving the new users in the timereport jar. I'd recommend using
> jpa here. This would be an example of using jpa from the web tier,
> currently missing IIUC.
> - demonstrating switching datasources
>
> Although bank and customer-service are pretty similar, I haven't recommended
> removing one because I modified customer-service to demonstrate container
> managed persistence contexts and left bank demonstrating application managed
> persistence contexts.
>
> I am not going to work on these two samples so if you really want to keep
> them please divvy up the work and update them and their documentation. My
> understanding is that Joe would like to get the samples released fairly
> soon.
>
> thanks
> david jencks
>
> On Jun 11, 2008, at 11:52 PM, Jacek Laskowski wrote:
>
>> On Thu, Jun 12, 2008 at 2:18 AM, David Jencks <da...@yahoo.com>
>> wrote:
>>>
>>> I'd like to remove the myphonebook and mytime samples. AFAICT they
>>> duplicate functionality demonstrated in bank.
>>>
>>> mytime has a web app accessing a stateless ejb
>>> myphonebook has a web app accessing a stateless ejb that uses a single
>>> jpa
>>> entity (with an application managed persistence context)
>>>
>>> bank has a web app accessing a stateless ejb that uses 3 jpa entities
>>> (although they aren't implemented well) using application managed
>>> persistence context
>>> customer-service has a web app accessing a stateless ejb that uses one
>>> jpa
>>> entity using a container managed persistence context.
>>>
>>> Any objections?
>>
>> Yup! Let's keep them till they're fixed and once they are we could
>> notice their value (I know it sounds weird, but they're pretty small
>> to digest for novices and that's their major value). Let me take a
>> look at them, okey?
>>
>> Jacek
>>
>> --
>> Jacek Laskowski
>> http://www.JacekLaskowski.pl
>
>
Re: Remove samples myphonebook and mytime?
Posted by Lin Sun <li...@gmail.com>.
Joe,
I agree that users won't be annoyed by too many samples as long as
they are validated/updated. So I agree if you already validated these
two samples, we can go ahead and release them for 2.1.2.
On Fri, Jul 18, 2008 at 5:12 PM, Joe Bohn <jo...@earthlink.net> wrote:
> I don't think users have ever been annoyed because we provided too many
> samples. However, I agree that if we keep them we must ensure that they are
> functional and documented. Is there some issue with functionality/doc of
> the mytime or myphonebook samples? If they are updated and functional
> (which I have validated that they are) then I think we should go ahead and
> release them. If they do fall behind on a future release we can decide at
> that time if it is a better use of our time to remove them rather than
> update them. However, for 2.1.2 I think the maintenance issue is a moot
> argument.
I don't have a strong opinion as to removing the 3 entities or 1
entities, and I don't know the histories of these samples either. If
the samples are serving the exact functionality purpose, by removing
the duplicate one, we can save our time and energy to work on a new
sample that demonstrates a different functionality or something else.
Lin
> Ok, so if there isn't any difference between the 3 entities and 1 entity ...
> and we really want to eliminate duplication ... then let's remove the
> sample with 3 entities (bank). The original proposal here was to remove the
> sample with 1 entity (myphonebook). The sample with 1 entity was added as a
> "very simple" sample and, IIRC it was added after we had the 3 entity
> sample. So, it would seem there was already a case where a user was
> confused by 3 entities vs. 1 and hence the 1 entity sample was created.
> Also, it will be easier to maintain and update the sample with 1 entity in
> the future rather than 3 if your primary argument is the work involved in
> maintenance.
>
> One other thought on bank ... I wonder if it was envisioned as growing into
> a more complex sample and it just never "grew-up". If we somehow decide to
> keep bank but remove myphonebook then I hope we can put something in place
> to prevent a simple sample from growing too complex. The thing I like about
> myphonebook and mytime is that they were created with the idea of being very
> simple and nothing else.
>
> Here again, if we don't want to keep both, then let's remove the sample that
> is less common and/or more complex. I'm not sure which that is but the
> mytime sample was added long after calculator and the motivation for adding
> it was the need for a "very simple" example. Perhaps calculator has been
> simplified over time or perhaps it never grew-up either. But it seems that
> it didn't meet the need when mytime was first introduced. I wonder what has
> changed since then?
>
>>
>> Lin
>>
>>
>>
>> On Thu, Jun 12, 2008 at 1:41 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>>
>>> I think you , joe, donald, and hernan are being completely unrealistic
>>> about
>>> the likelihood of these samples being maintained even if they get updated
>>> and the value they add and the potential for total confusion for users
>>> when
>>> they see a bunch of samples doing exactly the same thing.
>>>
>>> Before suggesting removing them I considered the overlap. Let me restate
>>> the extent of overlap:
>>>
>>> bank has 3 entities, myphonebook has one. To me this is 100% overlap
>>>
>>> mytime and calculator-stateless both demonstrate a stateless ejb with no
>>> connection to the outside world. Again to me this is 100% overlap.
>>>
>>> Rather than spending our non-existent energy maintaining a bunch of badly
>>> written samples that do exactly the same thing I'd rather see some
>>> faintly
>>> more realistic samples with a broader range such as an ejb that sends jms
>>> messages and a jsf sample. There's also a lot of room for improvements
>>> in
>>> the samples I think we should keep such as:
>>>
>>> - having the web client in a different war than the jaxws service in the
>>> jaxws example
>>> - having an ejb that sends messages in the jms example, probably in a
>>> different ejb jar.
>>> - actually saving the new users in the timereport jar. I'd recommend
>>> using
>>> jpa here. This would be an example of using jpa from the web tier,
>>> currently missing IIUC.
>>> - demonstrating switching datasources
>>>
>>> Although bank and customer-service are pretty similar, I haven't
>>> recommended
>>> removing one because I modified customer-service to demonstrate container
>>> managed persistence contexts and left bank demonstrating application
>>> managed
>>> persistence contexts.
>>>
>>> I am not going to work on these two samples so if you really want to keep
>>> them please divvy up the work and update them and their documentation.
>>> My
>>> understanding is that Joe would like to get the samples released fairly
>>> soon.
>>>
>>> thanks
>>> david jencks
>>>
>>> On Jun 11, 2008, at 11:52 PM, Jacek Laskowski wrote:
>>>
>>>> On Thu, Jun 12, 2008 at 2:18 AM, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>>
>>>>> I'd like to remove the myphonebook and mytime samples. AFAICT they
>>>>> duplicate functionality demonstrated in bank.
>>>>>
>>>>> mytime has a web app accessing a stateless ejb
>>>>> myphonebook has a web app accessing a stateless ejb that uses a single
>>>>> jpa
>>>>> entity (with an application managed persistence context)
>>>>>
>>>>> bank has a web app accessing a stateless ejb that uses 3 jpa entities
>>>>> (although they aren't implemented well) using application managed
>>>>> persistence context
>>>>> customer-service has a web app accessing a stateless ejb that uses one
>>>>> jpa
>>>>> entity using a container managed persistence context.
>>>>>
>>>>> Any objections?
>>>>
>>>> Yup! Let's keep them till they're fixed and once they are we could
>>>> notice their value (I know it sounds weird, but they're pretty small
>>>> to digest for novices and that's their major value). Let me take a
>>>> look at them, okey?
>>>>
>>>> Jacek
>>>>
>>>> --
>>>> Jacek Laskowski
>>>> http://www.JacekLaskowski.pl
>>>
>>
>
>
Re: Remove samples myphonebook and mytime?
Posted by Joe Bohn <jo...@earthlink.net>.
Lin Sun wrote:
> I agree with David - if two samples are completely duplicate we need
> to remove one, given the time we need to spend to maintain them in svn
> and wiki and the fact that the duplicate sample doesn't provide any
> extra usage.
>
> We should divide samples by its functionalities. At the end, the
> samples are used to demonstrate a particular function, and I don't
> think 3 entities or 1 entities will make a difference in helping users
> consume them. It will be annoying to the user if we release two
> samples with duplicate functions but we fail to update one of them due
> to lack of time/resource.
I don't think users have ever been annoyed because we provided too many
samples. However, I agree that if we keep them we must ensure that they
are functional and documented. Is there some issue with
functionality/doc of the mytime or myphonebook samples? If they are
updated and functional (which I have validated that they are) then I
think we should go ahead and release them. If they do fall behind on a
future release we can decide at that time if it is a better use of our
time to remove them rather than update them. However, for 2.1.2 I think
the maintenance issue is a moot argument.
>
> I looked at bank and myphonebook closely (both are stateless ejb, and
> application managed persistence context with JPA) thus I think we
> should remove one of them.
Ok, so if there isn't any difference between the 3 entities and 1 entity
... and we really want to eliminate duplication ... then let's remove
the sample with 3 entities (bank). The original proposal here was to
remove the sample with 1 entity (myphonebook). The sample with 1 entity
was added as a "very simple" sample and, IIRC it was added after we had
the 3 entity sample. So, it would seem there was already a case where a
user was confused by 3 entities vs. 1 and hence the 1 entity sample was
created. Also, it will be easier to maintain and update the sample with
1 entity in the future rather than 3 if your primary argument is the
work involved in maintenance.
One other thought on bank ... I wonder if it was envisioned as growing
into a more complex sample and it just never "grew-up". If we somehow
decide to keep bank but remove myphonebook then I hope we can put
something in place to prevent a simple sample from growing too complex.
The thing I like about myphonebook and mytime is that they were created
with the idea of being very simple and nothing else.
>
> mytime and calculator (yes, we changed the name from
> calculator-stateless-pojo to calculator) are mostly the same too (both
> are stateless ejb). The only difference is that mytime web client
> uses JNDI to look up the bean while calculator client uses @EJB
> annotation to inject the session bean's interface. I don't know if
> it is worthy to keep them because of the difference here?
Here again, if we don't want to keep both, then let's remove the sample
that is less common and/or more complex. I'm not sure which that is but
the mytime sample was added long after calculator and the motivation for
adding it was the need for a "very simple" example. Perhaps calculator
has been simplified over time or perhaps it never grew-up either. But
it seems that it didn't meet the need when mytime was first introduced.
I wonder what has changed since then?
>
> Lin
>
>
>
> On Thu, Jun 12, 2008 at 1:41 PM, David Jencks <da...@yahoo.com> wrote:
>> I think you , joe, donald, and hernan are being completely unrealistic about
>> the likelihood of these samples being maintained even if they get updated
>> and the value they add and the potential for total confusion for users when
>> they see a bunch of samples doing exactly the same thing.
>>
>> Before suggesting removing them I considered the overlap. Let me restate
>> the extent of overlap:
>>
>> bank has 3 entities, myphonebook has one. To me this is 100% overlap
>>
>> mytime and calculator-stateless both demonstrate a stateless ejb with no
>> connection to the outside world. Again to me this is 100% overlap.
>>
>> Rather than spending our non-existent energy maintaining a bunch of badly
>> written samples that do exactly the same thing I'd rather see some faintly
>> more realistic samples with a broader range such as an ejb that sends jms
>> messages and a jsf sample. There's also a lot of room for improvements in
>> the samples I think we should keep such as:
>>
>> - having the web client in a different war than the jaxws service in the
>> jaxws example
>> - having an ejb that sends messages in the jms example, probably in a
>> different ejb jar.
>> - actually saving the new users in the timereport jar. I'd recommend using
>> jpa here. This would be an example of using jpa from the web tier,
>> currently missing IIUC.
>> - demonstrating switching datasources
>>
>> Although bank and customer-service are pretty similar, I haven't recommended
>> removing one because I modified customer-service to demonstrate container
>> managed persistence contexts and left bank demonstrating application managed
>> persistence contexts.
>>
>> I am not going to work on these two samples so if you really want to keep
>> them please divvy up the work and update them and their documentation. My
>> understanding is that Joe would like to get the samples released fairly
>> soon.
>>
>> thanks
>> david jencks
>>
>> On Jun 11, 2008, at 11:52 PM, Jacek Laskowski wrote:
>>
>>> On Thu, Jun 12, 2008 at 2:18 AM, David Jencks <da...@yahoo.com>
>>> wrote:
>>>> I'd like to remove the myphonebook and mytime samples. AFAICT they
>>>> duplicate functionality demonstrated in bank.
>>>>
>>>> mytime has a web app accessing a stateless ejb
>>>> myphonebook has a web app accessing a stateless ejb that uses a single
>>>> jpa
>>>> entity (with an application managed persistence context)
>>>>
>>>> bank has a web app accessing a stateless ejb that uses 3 jpa entities
>>>> (although they aren't implemented well) using application managed
>>>> persistence context
>>>> customer-service has a web app accessing a stateless ejb that uses one
>>>> jpa
>>>> entity using a container managed persistence context.
>>>>
>>>> Any objections?
>>> Yup! Let's keep them till they're fixed and once they are we could
>>> notice their value (I know it sounds weird, but they're pretty small
>>> to digest for novices and that's their major value). Let me take a
>>> look at them, okey?
>>>
>>> Jacek
>>>
>>> --
>>> Jacek Laskowski
>>> http://www.JacekLaskowski.pl
>>
>
Re: Remove samples myphonebook and mytime?
Posted by Donald Woods <dw...@apache.org>.
I think more samples are better, even if there are some overlap. Small
differences could be key to help users, who have different requirements
or are trying to port existing apps to Geronimo.
-Donald
Lin Sun wrote:
> I agree with David - if two samples are completely duplicate we need
> to remove one, given the time we need to spend to maintain them in svn
> and wiki and the fact that the duplicate sample doesn't provide any
> extra usage.
>
> We should divide samples by its functionalities. At the end, the
> samples are used to demonstrate a particular function, and I don't
> think 3 entities or 1 entities will make a difference in helping users
> consume them. It will be annoying to the user if we release two
> samples with duplicate functions but we fail to update one of them due
> to lack of time/resource.
>
> I looked at bank and myphonebook closely (both are stateless ejb, and
> application managed persistence context with JPA) thus I think we
> should remove one of them.
>
> mytime and calculator (yes, we changed the name from
> calculator-stateless-pojo to calculator) are mostly the same too (both
> are stateless ejb). The only difference is that mytime web client
> uses JNDI to look up the bean while calculator client uses @EJB
> annotation to inject the session bean's interface. I don't know if
> it is worthy to keep them because of the difference here?
>
> Lin
>
>
>
> On Thu, Jun 12, 2008 at 1:41 PM, David Jencks <da...@yahoo.com> wrote:
>> I think you , joe, donald, and hernan are being completely unrealistic about
>> the likelihood of these samples being maintained even if they get updated
>> and the value they add and the potential for total confusion for users when
>> they see a bunch of samples doing exactly the same thing.
>>
>> Before suggesting removing them I considered the overlap. Let me restate
>> the extent of overlap:
>>
>> bank has 3 entities, myphonebook has one. To me this is 100% overlap
>>
>> mytime and calculator-stateless both demonstrate a stateless ejb with no
>> connection to the outside world. Again to me this is 100% overlap.
>>
>> Rather than spending our non-existent energy maintaining a bunch of badly
>> written samples that do exactly the same thing I'd rather see some faintly
>> more realistic samples with a broader range such as an ejb that sends jms
>> messages and a jsf sample. There's also a lot of room for improvements in
>> the samples I think we should keep such as:
>>
>> - having the web client in a different war than the jaxws service in the
>> jaxws example
>> - having an ejb that sends messages in the jms example, probably in a
>> different ejb jar.
>> - actually saving the new users in the timereport jar. I'd recommend using
>> jpa here. This would be an example of using jpa from the web tier,
>> currently missing IIUC.
>> - demonstrating switching datasources
>>
>> Although bank and customer-service are pretty similar, I haven't recommended
>> removing one because I modified customer-service to demonstrate container
>> managed persistence contexts and left bank demonstrating application managed
>> persistence contexts.
>>
>> I am not going to work on these two samples so if you really want to keep
>> them please divvy up the work and update them and their documentation. My
>> understanding is that Joe would like to get the samples released fairly
>> soon.
>>
>> thanks
>> david jencks
>>
>> On Jun 11, 2008, at 11:52 PM, Jacek Laskowski wrote:
>>
>>> On Thu, Jun 12, 2008 at 2:18 AM, David Jencks <da...@yahoo.com>
>>> wrote:
>>>> I'd like to remove the myphonebook and mytime samples. AFAICT they
>>>> duplicate functionality demonstrated in bank.
>>>>
>>>> mytime has a web app accessing a stateless ejb
>>>> myphonebook has a web app accessing a stateless ejb that uses a single
>>>> jpa
>>>> entity (with an application managed persistence context)
>>>>
>>>> bank has a web app accessing a stateless ejb that uses 3 jpa entities
>>>> (although they aren't implemented well) using application managed
>>>> persistence context
>>>> customer-service has a web app accessing a stateless ejb that uses one
>>>> jpa
>>>> entity using a container managed persistence context.
>>>>
>>>> Any objections?
>>> Yup! Let's keep them till they're fixed and once they are we could
>>> notice their value (I know it sounds weird, but they're pretty small
>>> to digest for novices and that's their major value). Let me take a
>>> look at them, okey?
>>>
>>> Jacek
>>>
>>> --
>>> Jacek Laskowski
>>> http://www.JacekLaskowski.pl
>>
>