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 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
