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 <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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/[EMAIL 
PROTECTED]
    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 <[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> 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 <[EMAIL PROTECTED]
        <mailto:[EMAIL PROTECTED]>> 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
            <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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

Reply via email to