I did some investigation on that matter and first
of all, I would like to say that there is two different
aspects to consider. It is important to make a
differentiation between two hierarchical structures:
- A package structure (java packaging)
- A file system structure.
The issues regarding where to put the deployment
descriptors are tackled by defining the second
structure, not the first one.
I personally really appreciate the 1.1.2 petstore
package structure.
PetStore identified components (customer, shoppincart)
and a petstore.control layer where you put classes that
glue your components together and map to your project
use cases.
Inside each component package they identified an ejb and
a model package. The model package contains your value
objects and the ejb one the enterprise bean corresponding
to the component.
Defining root packages like client or server is the approach
to avoid. A package structure needs to reinforce the model
dependencies so that, when changes need to be applied, one
can work on an identified unit of work.
Defining a package structure that also avoid cyclic dependencies
is also a high priority.
Now, having specific sub-packages to separate exceptions or daos,
is, I think, specific to each project, knowing that one needs to be
consistent across
all domains but that having a package for a single or a couple of
classes is usually useless and cumbersome.
I would like also to say that I personally prefer to rely on the make files
to pick up my component interfaces and do not see any added value
in separating them in two different packages.
Lo�c
-----Original Message-----
From: Avi Kivity [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 02, 2001 17:16
To: [EMAIL PROTECTED]
Subject: Re: each ejb having its own package
Very rarely. In fact, I don't follow my own recommendation all the time. If
I have 1-2 beans, I usually put everything in a single package (which I'll
proably regret when I add more beans).
The separation's purpose is not to allow multiple implementations, but to
present the smallest possible footprint to the client (and I mean reducing
human memory load, not machine memory load, here).
- Avi
--
This signature intentionally left blank.
> -----Original Message-----
> From: Tinou Bao [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 02, 2001 18:07
> To: [EMAIL PROTECTED]
> Subject: Re: each ejb having its own package
>
>
> I would like to be convinced of this too...I can see how this
> is appropriate
> when your interface is backed by various implementations and the
> implementation is complicated so maybe you'll put it in its own
> package...how often do your beans have different
> implementations for the
> home/remote interfaces?
>
> --
> Tinou Bao
> www.tinou.com
>
>
> ----- Original Message -----
> From: "Tony K. Lawrence" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 02, 2001 10:43 AM
> Subject: Re: [EJB-INT] each ejb having its own package
>
>
> > To me this one is interesting.
> >
> > I have seen about (and in many books) that the seperation
> of interfaces
> > and implementations of beans is a good thing. To me this
> is a little
> > odd that for a given bean you need 2 packages. I guess I
> would like to
> > be convinced of the advantages of doing this as it seems a popular
> > choice,
> >
> > Tony
> >
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Avi Kivity
> > Sent: 02 July 2001 15:26
> > To: [EMAIL PROTECTED]
> > Subject: Re: each ejb having its own package
> >
> >
> > I recommend placing the the external interfaces (home,
> remote, exposed
> > dependants) in one package, and the implementation (bean class,
> > deployment descriptors, unexposed dependants) in another.
> This makes the
> > client view much simpler - import one package, and you may
> use anything
> > you find there.
> >
> > So you would have
> >
> > com.whatever.something.A
> > com.whatever.something.AHome
> > com.whatever.something.B
> > com.whatever.something.BHome
> > com.whatever.something.C
> > com.whatever.something.CHome
> > com.whatever.something.beans.ABean
> > com.whatever.something.beans.A-ejb-jar.xml
> > com.whatever.something.beans.A-vendor-ejb-jar.xml
> > com.whatever.something.beans.etc...
> >
> > - Avi
> > --
> > This signature intentionally left blank.
> >
> > > -----Original Message-----
> > > From: Krishnan Subramanian [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, July 02, 2001 16:39
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: each ejb having its own package
> > >
> > >
> > > tinou,
> > >
> > > on the contrary, i would recommend (other opinions?)
> > > grouping EJBs into packages based on functionality of
> > > your application domain rather than anything else. that
> > > is entire point of package names - is it not? of course
> > > you might append a "session" or "entity" package at
> > > the very end if you so prefer - but much of it is upto
> > > you - the bean provider.
> > >
> > > and of course it should make life easier for the
> developers in your
> > > team as well other teams.
> > >
> > > -krish
> > >
> > > ----- Original Message -----
> > > From: "Tinou Bao" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Monday, July 02, 2001 3:24 PM
> > > Subject: each ejb having its own package
> > >
> > >
> > > > what are people's options of this? is it practical for
> > > large projects with
> > > > lots of ejbs? examples always have each ejb in it's own
> > > package, as does the
> > > > blueprint petstore example. i can see how it maybe easier
> > > for packaging into
> > > > jar files and building, but at some point doesn't it become
> > > cumbersome to
> > > > have so many packages.
> > > >
> > > > thanks.
> > >
> > > ==============================================================
> > > =============
> > > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the
> >
> > > body of the message "signoff EJB-INTEREST". For general help,
> > > send email to
> > > [EMAIL PROTECTED] and include in the body of the
> message "help".
> > >
> >
> >
> ==============================================================
> ==========
> > ===
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the
> > body
> > of the message "signoff EJB-INTEREST". For general help,
> send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
> ==============================================================
> =============
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the
> body
> > of the message "signoff EJB-INTEREST". For general help,
> send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Visit us at http://www.clearstream.com
IMPORTANT MESSAGE
Internet communications are not secure and therefore Clearstream International does not
accept legal responsibility for the contents of this message.
The information contained in this e-mail is confidential and may be legally
privileged. It is
intended solely for the addressee. If you are not the intended recipient, any
disclosure,
copying, distribution or any action taken or omitted to be taken in reliance on it, is
prohibited and may be unlawful. Any views expressed in this e-mail are those of the
individual sender, except where the sender specifically states them to be the views of
Clearstream International or of any of its affiliates or subsidiaries.
END OF DISCLAIMER
==========================================================================To
unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
