geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McConnell <tim.mcco...@gmail.com>
Subject Re: [Discuss] Model for deployment plans in GEP - Move from EMF to XMLBeans or JAXB?
Date Wed, 12 Mar 2008 02:46:26 GMT
HI Shiva, just for your information, I have finally deleted the V1/V1.0/V10 
features, plugins, and runtime. So if you are keeping track we have now eliminated:

-- org.apache.geronimo.v10.feature
-- org.apache.geronimo.deployment.model
-- org.apache.geronimo.deployment.model.edit
-- org.apache.geronimo.runtime.v1
-- org.apache.geronimo.st.v1.core
-- org.apache.geronimo.st.v1.ui


Shiva Kumar H R wrote:
> I will be committing Yun Feng's patch today, to kick start GEP 
> refactoring :)
> 
> This patch adds two new directories under plugins: 
> org.apache.geronimo.deployment.v11.jaxbmodel, and 
> org.apache.geronimo.deployment.v21.jaxbmodel
> which contain JAXB generated classes for our G plans. The patch has also 
> refactored some part of GEP code to use these JAXB model classes instead 
> of EMF.
> 
> We need to continue refactoring rest of GEP code and eventually get rid 
> of following EMF modules:
> org.apache.geronimo.deployment.model
> org.apache.geronimo.deployment.model.edit
> org.apache.geronimo.v11.deployment.model
> org.apache.geronimo.v11.deployment.model.edit
> 
> And further, once we figure out how to handle multiple schemas, we must 
> be able to merge org.apache.geronimo.deployment.v11.jaxbmodel and 
> org.apache.geronimo.deployment.v21.jaxbmodel into *one*
> 
> Once we have such single model which can handle multiple schemas, I am 
> hoping that we could merge these as well:
> org.apache.geronimo.st.ui,
> org.apache.geronimo.st.v1.ui,
> org.apache.geronimo.st.v11.ui,
> org.apache.geronimo.st.v20.ui, and
> org.apache.geronimo.st.v21.ui
> 
> Just in case we mess up things ;) we have taken backup of existing GEP 
> trunk under branches/2.1/ . We will be committing all new code under trunk.
> 
> And trunk builds might fail for sometime until this refactoring is complete.
> 
> -- 
> Thanks,
> Shiva
> 
> On Tue, Mar 4, 2008 at 2:11 PM, Shiva Kumar H R <shivahr@gmail.com 
> <mailto:shivahr@gmail.com>> wrote:
> 
>     There have been further discussions on this in IRC and in JIRA. As
>     recommended in
>     http://mail-archives.apache.org/mod_mbox/geronimo-dev/200802.mbox/%3c5da94e5a0802212321m4b282128q89add861e150c64f@mail.gmail.com%3e
>     I am summarizing those discussions below:
>     (Tim, DJencks, DBlevins & Yun Feng - Please correct if am wrong)
> 
>     1) JAXB/XMLBeans/DConfigBeans:
>     a) On a further discussion about XMLBeans and JAXB, we saw that
>     writing deployment code might turn out be much easier by using JAXB
>     rather than XMLBeans.
> 
>     b) On a discussion about whether GEP should ideally be using JSR-88
>     DConfigBeans, we wondered if JSR-88 DConfigBeans are a dead idea &
>     should be left alone, because No One other than Geronimo even thinks
>     about trying to implement them.
> 
>     So we concluded that it is worth experimenting with JAXB.
> 
>     2) Hints from OpenEJB about using JAXB:
>     a) On a discussion about how OpenEJB uses JAXB, it seems schemas are
>     compiled only once (instead of compiling during every build as is
>     currently done both in Geronimo and GEP) and checked in to the
>     source stream.
>     I too don't see any point in compiling G schemas during every build
>     of GEP, and the one time compilation & check in approach of OpenEJB
>     looks ideal to me for GEP also. This would lead to significant
>     savings in build time. Please point out if I am missing something.
> 
>     b) It seems that the real beauty (& ease of use) of JAXB comes from
>     the ability to customize JAXB generated classes (like (i) adding
>     interfaces, (ii) removing all their wrappers for simple types like
>     string, int, boolean etc, (iii) using Maps instead of Lists for auto
>     indexing things that can be keyed, etc). OpenEJB uses those
>     customizations. To keep the Customized JAXB classes and Schema in
>     sync, OpenEJB has unit tests that read in xml documents, write them
>     out again, then compare the results. A similar approach could be
>     used in GEP also.
> 
>     3) Handling multiple schema versions
>     I guess JAXB could help us better with multiple version of schemas.
>     (I mean a single set of JAXB classes being able to read/write say
>     geronimo-web.xml in v1.1, v2.0, v2.0.1 etc). We need to explore this
>     more.
> 
>     Tim, Yun Feng and myself are looking at completing this refactoring
>     at the earliest so that we could then focus on other JIRAs/features
>     & release GEP 2.1. Yun Feng already has a patch that has ported good
>     amount of GEP onto JAXB and I am looking at committing it tomorrow.
> 
>     If you forsee any concerns with the approaches above, kindly reply.
> 
>     -- 
>     Thanks,
>     Shiva
> 
> 
>     On Tue, Feb 12, 2008 at 2:16 PM, Shiva Kumar H R <shivahr@gmail.com
>     <mailto:shivahr@gmail.com>> wrote:
> 
>         Please see 11-Feb IRC chat btw djencks, shivahr & mcconne
>         http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20080211 for
>         further discussions on this.
> 
>         As recommended by DJencks we will experiment using JAXB in GEP 2.1.
> 
>         -- 
>         Thanks,
>         Shiva
> 
> 
>         On Feb 11, 2008 9:22 PM, David Jencks <david_jencks@yahoo.com
>         <mailto:david_jencks@yahoo.com>> wrote:
> 
> 
>             On Feb 11, 2008, at 7:16 AM, Shiva Kumar H R wrote:
> 
>>             I went through following tutorials of JAXB & XMLBeans:
>>               a) Java Architecture for XML Binding (JAXB)
>>              
>>             http://java.sun.com/developer/technicalArticles/WebServices/jaxb/
>>               b) Tutorial: First Steps with XMLBeans
>>              
>>             http://xmlbeans.apache.org/documentation/tutorial_getstarted.html
>>
>>             Also searched for comparisons btw them. Latest one I could
>>             find is the following blog from Jan'2005:
>>             http://technology.amis.nl/blog/?p=321
>>
>>             I am yet to see the value add JAXB brings over XMLBeans.
>>             Am I missing something?
> 
>             My $0.02:
> 
>             xmlbeans is a complete and accurate representation of the
>             xml infoset.  As a result, you can easily manipulate the
>             xml, but you get a slightly peculiar java object model that
>             exactly represents the schema and cannot be modified.
> 
>             jaxb is focussed on the java pojos and lets you modify the
>             pojos considerably from the xml while still providing
>             accurate mapping.  This can be much more convenient for
>             directly constructing a pojo tree from xml suitable for
>             configuring server components.  It provides fewer validity
>             checks than xmlbeans.
> 
>             Openejb is using jaxb and I think their deployment code is
>             pretty simple for the complexity they have to deal with.
> 
>             thanks
>             david jencks
> 
>>
>>
>>
>>             On Feb 11, 2008 4:44 PM, Shiva Kumar H R
>>             <shivahr@gmail.com <mailto:shivahr@gmail.com>> wrote:
>>
>>
>>
>>                     Despite my liking for xmlbeans and its unique
>>                     strengths I think a very strong argument can be
>>                     made for moving the deployer code to jaxb.
>>
>>                 Interesting!! Let me do some quick learning of jaxb
>>                 and start a separate thread on this.
>>                  
>>
>>
>>                     thanks
>>                     david jencks
>>
>>                     On Feb 8, 2008, at 12:30 AM, Shiva Kumar H R wrote:
>>
>>>                     2) Geronimo Eclipse Plug-in (GEP):
>>>                         a) Model framework for Geronimo deployment plans:
>>>                     Currently it is EMF (Eclipse Modeling Framework).
>>>                     With every update to Geronimo deployment schema,
>>>                     it's a major pain to generate new EMF classes. If
>>>                     however, GEP uses the same model framework as
>>>                     that of Geronimo server (XMLBeans), then at least
>>>                     this problem would be solved. IIUC JSR-88
>>>                     DConfigBeans would be the ideal model framework
>>>                     for GEP - in that case even if the model
>>>                     framework of server changes in future, GEP would
>>>                     be unaffected.
>>>
>>>                     -- 
>>>                     Thanks,
>>>                     Shiva
>>
>>
>>
>>
>>                 -- 
>>                 Thanks,
>>                 Shiva 
>>
>>
>>
>>
>>             -- 
>>             Thanks,
>>             Shiva
> 
> 
> 
> 
> 

-- 
Thanks,
Tim McConnell

Mime
View raw message