Re: Remove samples myphonebook and mytime?
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >> 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 La
Re: Remove samples myphonebook and mytime?
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Remove samples myphonebook and mytime?
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 <[EMAIL PROTECTED]> 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 co
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >> 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?
David Jencks 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. David, Thanks for the detailed response and pointing out the overlap again. I'll take a closer look at the overlaps you have pointed out. If it is truly 100% overlap (meaning both samples include the same level of detail) then I agree that we don't need multiple samples. However, it is really a very simple sample and a more complex sample then I think there is value in keeping the simple example. A user that just wants to understand the most fundamental concept without additional clutter could be confused by the more complex sample. On the other hand, I think it's good to have the more complex examples too since they are a little closer to real world scenarios even if they are very contrived. I was under the impression that this extremely simple vs. more complex scenarios were what we had in the samples that you pointed out. 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 All good enhancements. My only concern is to ensure that we have some very basic samples for those just starting out. If they truly are the most basic scenarios then it was my hope that there should be very little if any change from release to release and hence very low maintenance. 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. That sounds like a good split to me. 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. I hope to get back on this as soon as I catch up on email. 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 <[EMAIL PROTECTED]> 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?
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 <[EMAIL PROTECTED]> 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?
I would say the more the merrier. It can't hurt to have more than one sample about the same functionality. It is OK to have some overlap. I would definitively keep them Cheers! Hernan David Jencks 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? Am I missing something? thanks david jencks
Re: Remove samples myphonebook and mytime?
On Thu, Jun 12, 2008 at 2:18 AM, David Jencks <[EMAIL PROTECTED]> 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?
I don't see the harm in keeping them and there is value if we have a sample that matches a user scenario or question. So long as the aren't identical in the combination of features lists I don't see a reason to remove them. Smaller simple samples have a place and more complicated ones also have a place. Joe David Jencks 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? Am I missing something? thanks david jencks
Re: Remove samples myphonebook and mytime?
Isn't the point to provide as many samples to our users as possible, even if there is some overlap? When a simpler sample is all a user needs, why make them digest more complex ones like bank or daytrader -Donald David Jencks 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? Am I missing something? thanks david jencks smime.p7s Description: S/MIME Cryptographic Signature
Remove samples myphonebook and mytime?
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? Am I missing something? thanks david jencks
