My implementation plan is described in this JIRA issue. Step 2) is where I am now, that is defining the Annotation types. Also note that step 3) is pretty much what has been discussed on other posts in terms of Keith's notes on extending the reflection support in Castor XML to recognise Annotations.
http://jira.codehaus.org/browse/CASTOR-1104 The above JIRA issue actually refers to Castor XML and not Castor JDO. Architectural the two do share a common set of classes, for example the ClassDescriptor and FieldDescriptor classes. As such to some degree I will be providing some support for Castor JDO in terms of the parts that overlap today. As for the doing the rest to make Annotations available to do the same job as the current Castor JDO mapping files, I'd hoped other developers would extend. :-) So Bruce is correct in saying we are both at similar points, in terms of deciding what the Annotations will look like. As far as I can see for the Castor XML Annotations we have two options, create Castor specific Annotation classes (based loosely around the requirements of our existing XMLClassDewscriptor and XMLFieldDescriptor classes) or look at using the JAXB ones. Does anyone have any thoughts on this? https://jaxb.dev.java.net/nonav/jaxb20-pr/api/javax/xml/bind/annotation/ package-summary.html Andrew. -----Original Message----- From: Bruce Snyder [mailto:[EMAIL PROTECTED] Sent: 15 July 2005 23:18 To: Nick Stuart Cc: dev@castor.codehaus.org Subject: Re: [castor-dev] Runtime addition of classes... On 7/15/05, Nick Stuart <[EMAIL PROTECTED]> wrote: > > So what are your thoughts on the work that Andrew is doing in the > > Castor code base? > > > > I think annotations could add a lot to how things are configured. I > guess, since my CodeGeneration experince is limited I'm still trying > to wrap my head around what exactly Andrew accomplishing with his > work. Are their any test cases/examples that are available that I > could look at see whats 'supposed' to be happening Andrew? I *highly* encourage you to work with Andrew on this stuff. I'm confident that he can get you up to speed in understanding what he's doing exactly. Also, because you're not familiar with it, you're the perfect person to be writing tests for what he's doing. This would kill two birds with one stone in that it would provide tests for the work and it would help you understand things. > I think eventually we both will be at a point where we have a lot of > the similar stuff going on, and at the point it would be a good idea > to see where we can consolidate things. I agree, but why wait? Understand what each other is doing and meet in the middle. Don't expend the energy to perform double work that someone else is already doing. Also, having two sets of eyes on everything is far more beneficial than simply one person sitting in a corner working on it alone. > > > The other is to integrate it into the Castor code base and start > > > adding to that to do what I'm looking for. Bonus that everything is > > > already included when a user downloads Castor. Not so bonus that we > > > have to add yet MORE stuff to Castor that has the potential of > > > breaking, and not everyone would use it, but be forced to d/l and be > > > aware of it. > > > > Exactly! What about people that don't want it? Asking users to go > > through a matrix of things to download is too much. E.g., if you don't > > want annotations, download X, but if you do, download Y, etc. This > > could very quickly turn into a maintenance nightmare. > > > > Agreed, having more jars to deal with is never a good thug. One way to > handle this would be to keep the Annotation additions as separate as > possible so they along could be packed up into one 'optional' jar that > a user could then add and use. But having two or more different > 'castor' main jars, one with annotations, one with out, etc would be a > nightmare. > > If anyone here uses Tapestry, this is the approach Howard has used in > 4.0. Annotations are kept separate for people who still need 1.3, 1.4 > JRE compatibility. Yeah, that's not a bad idea until you have so many things that reside in the optional.jar that it too is a hog. But getting back to my previous comments, working together with Andrew would allow the work to get done faster and into the communities hands quicker too. I hope you'll at least consider doing this. BTW, I'm friends with Howard. He's a very good guy. Bruce -- perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/ ------------------------------------------------- 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. ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
