This one time, at band camp, Daniel Shriver said:
DS>-----Original Message-----
DS>From: tek1 [mailto:[EMAIL PROTECTED]]
DS>Sent: Wednesday, February 05, 2003 3:12 AM
DS>To: [EMAIL PROTECTED]
DS>Subject: Re: [castor-dev] Code for auto-generating CUSTOM castor mapping
DS>files
DS>
DS>>do you mean that you want to automatically generate the mapping.xml file
DS>>based on your .java classes?
DS>
DS>Yes that is EXACTLY what I mean.
DS>
DS>>have you checked out xdoclet's exolab/castor module?
DS>
DS>Ok, maybe I don't understand their module correctly but from what I saw one
DS>has
DS>to mark up their code (with xdoclet "comment" tags) for it to work
DS>correctly. What I want is a solution that requires NO touching of the code
DS>we
DS>want to generate mappings for (and I mean NO alterations, including
DS>comments).
DS>There is nothing impossible about me pitching that we should recomment all
DS>code
DS>with xdoclet metadata- but I'm not even sure I like the idea. Why: 1)
DS>if I require people to put in this metadata I add another layer of writing,
DS>testing,
DS>and debugging (not at all popular) 2) our work builds on other products (as
DS>does most
DS>software these days), it would be VERY unpleasant to have to edit & test all
DS>the
DS>third party stuff each time we did an upgrade of it.
DS>
DS>To put it another way- I am one of the few people who care and bother about
DS>the
DS>format and versioning of the data. The other people are (and should remain)
DS>simply
DS>consumers of that data, and when they are writing logic why should they
DS>bother with
DS>serialization details?
DS>
DS>I want something exactly like xdoclet except that it does not require
DS>metadata-
The statement above quells this entire argument. There is nothing currently
available that will accomplish this task. It is certainly doable, but it is
quite complex because it would require, at a minimum, some type of rules file
(or something similar) because the mapping provides the basis for an
integration of the object model with the data model. Because an object model
is almost never a one-to-one reflection of the data model, odd situations
will arise and you need a way to deal with them.
DS>it just scans classes and generates mappings on the fly. This isn't an
DS>impossible
DS>task, but (in looking at what is involved) it is much more difficult than I
DS>naively
DS>first guessed. It is really too bad that Java doesn't include methods for
DS>querying the compiler, after all the compiler has to reliably parse the
DS>*.java
DS>files so it would both already have some of the info I want and would have
DS>the other
DS>info reliably packed away in neat datastructures.
You could certainly use a parser generator like JavaCC or ANTLR to parse the
Java file and write out to a file based on the rules established in the
grammar file. However, like I said above, you would need to establish rules
to handle odd situations.
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
