Did a little thinking about this, how about extending generate? Something
like:
generate="false" <- generate nothing, treat the bean as an abstract base
class
generate="dd" <- generate deployment descriptors only, ignoring _all_
other tasks unless the individual task explicity
is set to generate="true" (effectively the
equivalent of deployable="true")
generate="true" <- (default) generate everything unless instructed not
to in other tags
seems a lot simpler to me. thoughts? Or am I missing something
obvious... its been one of those days, so that's entirely possible (o:
cheers
dim
On Tue, 30 Oct 2001, Ara Abrahamian wrote:
> This discussion is interesting.
>
> One thing xdoclet inherited from old ejbdoclet was generating stuff by
> default, we then added switches to turn off those you don't want. But
> let's face it guys: it better to turn many things off by default! And to
> apply some defaults by default!
>
> For example the usefulness of data-objects declined in ejb2 because of
> local interfaces (though I'm a firm believer in dataobject even in ejb
> 2!). So having to put generate="false" in source code is a pain.
>
> I guess we should change some things:
> - A deployable="true|false" (or deploy as you call it, I prefer
> deployable) for specifying whether the bean is a real bean you want to
> use or an abstract one. Assuming that we'll also implement the logic for
> turning off some subtasks if desired (say you don't want <session/> or
> <entitycmp/>), this parameter is only applicable if you have
> entitycmp/bmp defined. So we should write an isDeplyable tag impl in
> EjbTagsHandler. Another interesting thins we can do is to search for
> abstract methods, if there's one then the bean is an abstract bean, of
> course we omit persistent getter/setter methods and get/setData. Another
> useful default is to guess session bean type: if implementing
> SessionSynchronization then it's stateful, if has a single ejbCreate()
> method then stateless and things like that, of course if user does not
> override it by putting a @tag.
> - The same is true for generate="true|false" in regard to entitycmp/etc.
> - All subtasks should be optional. If you don't declare <entitycmp/> you
> don't get the subclassed class. If you declare <deploymentdesciptor/>
> and nothing more it means you don't need more, probably because you have
> legacy code, so you don't want it in general.
> - Something we still don't provide: useful defaults. For example you
> should be able to pass a bean source that has no @ejb: tags and get
> everything generated. Some defaults should apply, for example there's no
> ejb:bean name param, so classname should be used, same for jndi name and
> so on. This gives a much better jumpstart to a newbie and we can even
> write a tutorial that way: first show a normal class, run xdoclet, see
> what happened, then try to control the output by adding @tags. I also
> think each *doclet task should have a tutorial like the one I talked
> about here, "here is entitybmp it generates this and that, we run it
> now, here is the result".
>
> Dmitri, if you could make the optional subtasks happen we could get rid
> of many of those requests saying they only want deployment descriptor or
> they don't like the auto-generated cmp class and so on :o)
>
> Ara.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:xdoclet-devel-
> > [EMAIL PROTECTED]] On Behalf Of Dmitri Colebatch
> > Sent: Tuesday, October 30, 2001 4:33 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Xdoclet-devel] CVS update: 'xdoclet/core/src/xdoclet/ejb
> >
> > On Tue, 30 Oct 2001, Andrew Stevens wrote:
> >
> > > > which other files?
> > >
> > > PK, data object, home & remote interfaces. In practise, if you
> don't
> > want
> > > the BMP/CMP/Session class generated you probably wouldn't want those
> > done
> > > either, but I assumed the @ejb:pk etc. had their own generate
> parameter
> > to
> > > control that. I must admit I didn't check those, though, it was
> only
> > the
> > > @ejb:bean one I tested.
> >
> > yep - so we want pk to check for ejb:pk generate=false || (ejb:bean
> > generate=false && ejb:pk generate != true)? makes sense
> >
> > > It is a good thing; it means one of the bugs is sorted. There is
> still
> > a
> > > problem with the ejb-jar.xml, but that was the other one :-) It
> doesn't
> > > reference the non-existent BMP class any more, unfortunately it
> doesn't
> > > reference anything...
> >
> > hehe... well its not broken (o: I dont know I really gave it the time
> it
> > deserves... see how we go this week (o:
> >
> > > > hmmm.. yeah, so we have two scenarios:
> > > > 1) I have a base class that I have some common functionality in
> -
> > this
> > > > shouldn't have a subclass generated, and should not be in the dd
> > > > 2) I have a bmp entity that I done want a subclass generated for
> -
> > > > this shouldn't have a subclass generated, but should be in the dd.
> > > >
> > > > so you're proposing something like:
> > > >
> > > > @ejb:bean generate="false" deploy="true"
> > > >
> > > > what should deploy default to if generate is false and deploy is
> > absent?
> > >
> > > Depends whether you think it's more common for people to be using an
> > > abstract base EJB than to be using existing concrete EJBs and just
> > wanting
> > > XDoclet to generate the DD. On the whole, I'd probably go with
> > defaulting
> > > to true, but I'm biased - I don't have any abstract base EJBs, but
> > others
> > > here are developing EJBs with other tools so there's a mixture of
> > > XDoclet-generated and concrete hand-coded beans.
> >
> > I'm with you... the idea of using XDoclet is that you dont need the
> > abstract base classes. There is always the possibility that someone
> is
> > using the base classes, so I think we should provide for it.
> >
> > cheers
> > dim
> >
> >
> > _______________________________________________
> > Xdoclet-devel mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
