No not generating the annotations types themselves, these will be fixed in one of the Castor packages. My goal in respect to Annotations is to make the generated code (from an .xsd) use them. In effect merge the MyClass.java and MyClassDescriptor.java source files together using annotations. I also want to make more use of Java 5 Generics instead of generating type safe collection classes as it currently does.
-----Original Message----- From: Nick Stuart [mailto:[EMAIL PROTECTED] Sent: 13 July 2005 16:36 To: Andrew Fawcett; dev@castor.codehaus.org Subject: Re: [castor-dev] Castor Annotations Well you can take a look at my list of current annotations here: https://castor-annotations.dev.java.net/source/browse/castor-annotations /src/org/moss/castor/annotations/ I've basically made each element type an annotation. This is the simple way out, but also makes sense for how Castor is setup. I also made each attribute a part of the Annotation and where I could, (believe any xsd:choice elements) I made the attributes Enums for ease of use/access. So, to make sure I understand where you are headed, you are looking to have the source generator to be able to generate the annotations defined by the developer of the xsd? And in turn, generating the Annotations as well? -Nick On 7/13/05, Andrew Fawcett <[EMAIL PROTECTED]> wrote: > Hi Nick, > > You might be interested in the Java 5 work I've been doing in the main > Castor code base. It's described in more detail under this JIRA entry. > > http://jira.codehaus.org/browse/CASTOR-1104 > > So far I've added support for Annotations into the org.exolab.javasource > package for producing Java source (ultimately from the Castor Source > Generator) with Java 5 Annotations and Enumerations in it. > > http://cvs.castor.codehaus.org/viewrep/castor/castor/src/main/org/exolab > /javasource > > My next step is to define the actual Annotations required, then have a > new Annotation aware ClassDescriptior impl. use them and finally have > the Source Generator output source with them present. > > So in respect to deciding Annotations, it looks like we are at roughly > the same point, care to swap notes on the Annotations required? Maybe at > least on those required between Castor JDO and Castor XML? I've also > been studying the .Net XML Attributes for ideas; I think this is also a > good source for input. > > Andy. > > > -----Original Message----- > From: Nick Stuart [mailto:[EMAIL PROTECTED] > Sent: 13 July 2005 14:57 > To: dev@castor.codehaus.org > Subject: [castor-dev] Castor Annotations > > Ok, so the project was approved...YEAH! :) > > Anyways, be warned that it is still very rough, but functional for > what I sought to do at the time. Willing to change anything and > everything if there is a better way to do it. > > Jeremy already brought up a point that I will taking on, and thats to > be able to use annotated classes directly instead of marshalling out > to an XML file. We'll see what can be done with that with as few, or > no changes to the Castor codebase. > > Check it out at: > https://castor-annotations.dev.java.net/ > > -Nick > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > > > > The information in this message is confidential and may be legally privileged. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message in error, please advise us immediately. Internet emails are not necessarily secure. CODA does not accept responsibility for changes to any email which occur after the email has been sent. Attachments to this email may contain software viruses, which could damage your systems. CODA has checked the attachments for viruses before sending, but you should virus-check them before opening. > > The information in this message is confidential and may be legally privileged. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message in error, please advise us immediately. Internet emails are not necessarily secure. CODA does not accept responsibility for changes to any email which occur after the email has been sent. Attachments to this email may contain software viruses, which could damage your systems. CODA has checked the attachments for viruses before sending, but you should virus-check them before opening. ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
