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