Hi Jon, we are also aware of the advatages of the common mapping for XML and database side. The idea for the mapping is that we will define a MappingLoader interface layer with various implementations:
- current mapping syntax (for XML and database) - JPA (EJB 3.0) XML mapping (database only) - JPA (EJB 3.0) annotations mapping (database only) - JAXB 2 annotations mapping ( XML only) As far as I can see at the moment the MappingLoader interface layer will reside in core module. We do not know yet if we create separate modules for the MappingLoader implementations or if they will go into one of the modules outlined below. Even if it would be interesting to use JPA and JAXB annotations together, for those using both parts, it's ways to early to tell you if this can be achived. Having said that apart of the mapping there aren't much areas that are shared between both parts. At least as far as I know ;-) In addition we know that there are users that prefer to have one castor.jar that contains all that belongs to castor. Therefor we will still keep distributing the full castor.jar even if this prevents independend releases of the modules. As always any thoughts, ideas and contribution is very welcome Ralf Jon Wilmoth schrieb: > As a user who does use both sides of the project I would hope the synergies > that exist now (i.e. being able to use one mapping file for both) will > continue to exist with independent modules. Castor is the only project I > know of that offers the ability to model a domain in multiple persistence > technologies. I would hate to see Castor lose this point of differentiation. > > Jon > > ----- Original Message ---- > From: Ralf Joachim <[EMAIL PROTECTED]> > To: [email protected] > Sent: Thursday, May 4, 2006 7:59:08 AM > Subject: Re: [castor-user] Project Question > > > Hi Chris, > > thanks for the laud and also for your comment. We have discussed about > the same issue some time ago and have come to a similar conclusion. > Beside fixing bugs and adding new features we are refactoring Castor to > split it into independed modules. Castor will still be one project but > it will consist of a number of different modules that are distributed in > separate jar's. The modules propably will not have indipendend releases. > As far as we know at the moment we'll create following modules: > > core > jpa (database part called JDO at the moment) > xml > srcgen > > In addition we defined JPA (EJB 3.0) compatibility as target for > database part and support for JAXB 2.0 on the XML side. > > I hope this goes into the direction you thought of > Ralf > > > ELVART, CHRISTOPHER (SBCSI) schrieb: > >>I have been using Castor XML for a while now and think it's great. Hats >>off to the developers. >> >>I have one general question, and I hope nobody will be offended because >>it is not meant as a personal criticism. >> >>Why is Castor one project and not two? It seems to me like there are >>people who use it for XML and other people who use it for JDO, but most >>don't do both. These also seem like different functional areas to me >>that are not really joined logically. You have different team members >>responsible for both projects. The code seems to be split into separate >>packages. Would it make sense to separate these projects or do they >>really share too much logic? It seems to me that the XML project could >>stand on its own and that the JDO could have the XML project as a >>dependency. >> >>In my company Castor is the standard for XML binding but we must use >>Hibernate for persistence if we don't want to use standard JDBC code. >> >>Thanks, >>Chris Elvart >>AT&T >> >>------------------------------------------------- >>If you wish to unsubscribe from this list, please >>send an empty message to the following address: >> >>[EMAIL PROTECTED] >>------------------------------------------------- > > -- Syscon Ingenieurbüro für Meß- und Datentechnik GmbH Ralf Joachim Raiffeisenstraße 11 D-72127 Kusterdingen Germany Tel. +49 7071 3690 52 Mobil: +49 173 9630135 Fax +49 7071 3690 98 Email: [EMAIL PROTECTED] Web: www.syscon-world.de ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
