<lurker-comment>
Is this just a small utility to help people get started or are there any
plans to grow this into a major code generation tool? If it's the latter
I'd like to make a few comments you may or may not use in taking this a
step further. About a year ago we (my company) saw the possibilities in
generating entity bean code from java bean classes and deploymen t
descriptors (for JOnAS at the time) because it's so obvious and easy to
do (we did it with reflection, the javadoc way is better, of course) and
saves tons of time and unnecessary bugs. When that was done it became
obvous that what we we're really doing was generate code from a model with
relationships (we implemented bean relationships using the lazy loading
pattern (thanks again for your tip, rickard, worked great ;-) based on
minformation in our bean classes. once you have that model you see that you
can use that for so much more (generating sql if you don't have that
already, generate a swing ui with treeviews and JLists for n-m and 1-n
relationship editing, generate session bean facades as a service layer to
the entity beans etc.). we came up with a dtd that described the model and
specified the model in xml and went so far that once you had your model in
place you started the code generation process and the result was a
deployable j2ee test application with a running swing client that
communicates via a rmi-http-tunneling with the service layer. based on that
we implemented a number of projects and still are very happy with that
approach (currently using orion as our j2ee platform). for code generation
we use webmacro as a template language because we felt that the ability to
do some amount of java-based scripting in the templates is really handy and
very powerful (if used carefully enough to not screw up maintainability).
as a model to describe the data we decided on an ER-Model because it's
quite simple and we always work with RDBMSs anyway.
my point is, that what you're doing with your doclet is really generating
code from a model which can be used in a more powerful way, if not doing it
too EJB-centric.
the code we produced is not clean enough or general purpose to make it open
source (typical in house under pressure rapid prototyping stuff). just
thought the experience we made with this type of approach might be worth
taking into consideration as we have brought a few real world projects in
production with that. at the moment we are reimplementing a cleaner version
of this (using a schema a more modular architecture and some better coding
practices). If this sound interesting to you we may have something to take
a look at a few weeks from now. however, if you think that your very useful
piece of code was never meant to start a subproject or this kind of
discussion, never mind ;-).
</lurker-comment>
regards,
robert
>That would be seriously cool I think, since it would allow *zero-effort*
>translation of existing database tables into EntityBeans!!
>
>What do you think? Interested? :-)))
>
>regards,
> Rickard
>
>--
>Rickard �berg
>
>Email: [EMAIL PROTECTED]
>http://www.telkel.com
>http://www.jboss.org
>http://www.dreambean.com
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Problems?: [EMAIL PROTECTED]
(-) Robert Kr�ger
(-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
(-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
