Ciao guys, reporting some quick thoughts (sory to be a bit silent but I am fully absorbed by non-geo* work :-) )
On Wed, Jun 25, 2008 at 4:50 PM, Adrian Custer <[EMAIL PROTECTED]> wrote: > On Wed, 2008-06-25 at 10:23 -0400, Chris Holmes wrote: >> if we're just talking about bringing in yet >> another XML then I think we need to seriously consider the downside of >> requiring our users to learn another technology. > > > As I understand Martin's vision, users are not forced to even think > about the annotations, which users can happily ignore. They are > annotations, not code, and invisible in the javadoc. My main concern with using JAXB and its annotations is that it make hard if not impossible to use others technologies like hibernate which can use annotations themselves. I am not sure we can use JAXB with xml mapping files like we can do with hibernate since the few times I have used it it was by exploiting annotations. Anyway, if this is possible I would recommend this approach. If this is not possible, I would not be happy with extending JAXB annotation usage any farther than where we aree now now. Most people still don't use JAXB and adding its annotations to our code is not, IMHO, following a standard but imposing an implementation, even if it is the SUN implementation. Btw, IMHO, using as an argument to motivated a decision that something has been created by SUN may not be a well thought decision all the time. There are many cases in which SUN implementations are worst than third party libraries, therefore before saying "this one is better than this other" I would suggest at least an honest comparison. Second concern I have it towards file size increase. I use geotools in webstart apps where size is an issue, hence I would like to avoid anything that make the esize of the lib growt, at least the size of the core parts or it. To summarise I agree with jody and aaime here and I would rather see this work, which I am not debatin > > 1) The modules which wish to add the annotations which they want but > commit to cover their whole module with those annotations targeting one > particular specification version. > This gives users who wish to use those annotations access to > them. For JAXB, annotated modules, this means those modules can > be serialized to one particular format. The rest of the world > can ignore them. > > 2) Those who wish to target or support multiple formats have more work > and will have to use either Justin's parser work or write code following > Jody's suggested DTO work. Both will work happily against the annotated > base class. > > > So the Java code works for everyone, there are two approaches for highly > complex parsing of different formats, and one default for the lazy > mortals that need one serializable format and are willing to settle for > "whatever SUN cooked up for us". > > > hope that helps explain things, > --adrian > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- ------------------------------------------------------- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it ------------------------------------------------------- ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
