[Xdoclet-user] xdoclet ejb tasks a la carte?

[Ben J. <dea...@ya...>]

Hello,

I'm a new user to xdoclet, figuring I'll jump straight into the new version
instead of ejbdoclet.  The project looks like it could really help out our
team.  We've got 1.2M of bmp ejb source code, and it's virtually
undocumented.  We have a lull in development, and doing some documentation
seems like a good idea.  I really like the idea of integrating configuration
elements normally maintained in ejb-jar.xml with the .java.  Enter xdoclet.

From what I can tell, there's no way to use ejbdoclet "a la carte."  I'm
most interested in using the <deploymentdescriptor> element, but that seems
to presume <remoteinterface>, <homeinterface> and <entitypk> subtasks so
that it can fillout the ejb-jar.xml file's <entity> nodes.

Is there a way (or plan) to add something like @ejb:remote-name as a
parameter so that we're not forced into using <remoteinterface> ?

With a large codebase, I'm sure you can understand my reluctance to chuck
all our Remotes and Homes into the bit bucket.  I'll save that battle for
another day.  Conceptually, I buy it, but right now, I don't want to dig a
hole that is difficult to get out of.

However, the biggest issue is with the PK.  We've utilized an extreme amount
of inheritance among our beans, and one side effect is that we have a single
PK class for all our entity beans.  I can't have xdoclet generating a slew
of pk classes with different names.  (Don't ask...  It's just the way our
beans are archictected.  With single pk, we write one ejbFindByPrimaryKey
method and all the Bean classes inherit it.  With multiple pk classes, you
need to keep re-writing those standard methods.)

Thoughts?  Is it too far out from the paradigm ejbdoclet is based on?  I may
be willing to sign up as a developer to make it happen.

Thanks,

-benJ



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com