however, with no @tags in the source, there is no way for the generator to know which fields should have which attributes (i.e. which fields should be NOT NULL and which can allow nulls), as it is not possible to describe this a field declaration in java. also, without the @tags, there is no way to have database table and table field names that are different from the class and class's fields.
in other words, java itself needs to be able to describe *everything* that needs to appear in the mapping.xml file. that is not possible and thus the raison d'etre for xdoclet.
At 11:21 03/02/05 -0500, you wrote:
Ok, maybe I don't understand their module correctly but from what I saw one has----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
to mark up their code (with xdoclet "comment" tags) for it to work
correctly. What I want is a solution that requires NO touching of the code we
want to generate mappings for (and I mean NO alterations, including comments).
There is nothing impossible about me pitching that we should recomment all code
with xdoclet metadata- but I'm not even sure I like the idea. Why: 1)
if I require people to put in this metadata I add another layer of writing, testing,
and debugging (not at all popular) 2) our work builds on other products (as does most
software these days), it would be VERY unpleasant to have to edit & test all the
third party stuff each time we did an upgrade of it.
To put it another way- I am one of the few people who care and bother about the
format and versioning of the data. The other people are (and should remain) simply
consumers of that data, and when they are writing logic why should they bother with
serialization details?
I want something exactly like xdoclet except that it does not require metadata-
it just scans classes and generates mappings on the fly. This isn't an impossible
task, but (in looking at what is involved) it is much more difficult than I naively
first guessed. It is really too bad that Java doesn't include methods for
querying the compiler, after all the compiler has to reliably parse the *.java
files so it would both already have some of the info I want and would have the other
info reliably packed away in neat datastructures.
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
