You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Shiva Kumar H R <sh...@gmail.com> on 2008/03/04 09:41:15 UTC
Re: [Discuss] Model for deployment plans in GEP - Move from EMF to XMLBeans or JAXB?
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.xmlin
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 <sh...@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 <da...@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 <sh...@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
> >
> >
> >
>
Re: [Discuss] Model for deployment plans in GEP - Move from EMF to XMLBeans or JAXB?
Posted by Shiva Kumar H R <sh...@gmail.com>.
Ok Thanks :)
On Wed, Mar 12, 2008 at 8:16 AM, Tim McConnell <ti...@gmail.com>
wrote:
> 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
> > <ma...@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
> > <ma...@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
> > <ma...@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 <ma...@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
>
Re: [Discuss] Model for deployment plans in GEP - Move from EMF to
XMLBeans or JAXB?
Posted by Tim McConnell <ti...@gmail.com>.
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
> <ma...@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
> <ma...@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
> <ma...@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 <ma...@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
Re: [Discuss] Model for deployment plans in GEP - Move from EMF to XMLBeans or JAXB?
Posted by Shiva Kumar H R <sh...@gmail.com>.
EMF plug-ins are now redundant and have been deleted (GERONIMODEVTOOLS-294).
This led to a lot of GEP dependencies going redundant (GERONIMODEVTOOLS-295)
and those have also been deleted. (Please see the JIRA comments for detailed
information)
GEP has become Surprisingly Thinner - Just 5.4MB!! (down from 12.6MB -
nearly 55% reduction in weight). She is becoming more & more attractive each
day ;)
--
Thanks,
Shiva
On Tue, Mar 11, 2008 at 11:48 PM, Shiva Kumar H R <sh...@gmail.com> wrote:
> The remaining two modules (v20.core & v20.ui) have also been ported to an
> extent. Thanks again Yun Feng for the patch (you seem to be super fast!).
>
> Entire GEP builds successfully now. However there is still a lot more
> porting to be done.
>
> --
> Thanks,
> Shiva
>
> On Thu, Mar 6, 2008 at 3:31 PM, Shiva Kumar H R <sh...@gmail.com> wrote:
>
> > I have committed Yun Feng's patch into GEP trunk. Thanks very much Yun
> > Feng.
> >
> > Build is successful, except for below two modules:
> > <module>org.apache.geronimo.st.v20.core</module>
> > <module>org.apache.geronimo.st.v20.ui</module>
> >
> > Once those two modules are also ported onto JAXB, complete build would
> > be successful.
> >
> > --
> > Thanks,
> > Shiva
> >
> > On Wed, Mar 5, 2008 at 10:44 PM, Shiva Kumar H R <sh...@gmail.com>
> > wrote:
> >
> > > Perfect. Thanks Tim. I will concentrate on the various ui packages.
> > >
> > > Yun Feng,
> > > Would you like to explore handling multiple schema versions?
> > >
> > > --
> > > Thanks,
> > > Shiva
> > >
> > > On Wed, Mar 5, 2008 at 10:18 PM, Tim McConnell <ti...@gmail.com>
> > > wrote:
> > >
> > > > Shiva, with your current experience with the deployment plan portal,
> > > > is it safe
> > > > to assume you will again concentrate on the visual aspects of the
> > > > refactoring
> > > > (deployment plan editors, etc..??) If that is the case, I will
> > > > concentrate on
> > > > the various version specific
> > > > server tool cores (e.g., org.apache.geronimo.st.core, etc)....
> > > >
> > > > Tim McConnell wrote:
> > > > > Hi Shiva, thanks for the update. I will review Yun Feng's patches
> > > > today
> > > > > as well, and start on the refactoring effort as well.....
> > > > >
> > > > > 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
> > > > >> <ma...@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
> > > > >> <ma...@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
> > > > >> <ma...@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 <ma...@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
> > > >
> > >
> > >
> > >
> >
>
Re: [Discuss] Model for deployment plans in GEP - Move from EMF to XMLBeans or JAXB?
Posted by Shiva Kumar H R <sh...@gmail.com>.
The remaining two modules (v20.core & v20.ui) have also been ported to an
extent. Thanks again Yun Feng for the patch (you seem to be super fast!).
Entire GEP builds successfully now. However there is still a lot more
porting to be done.
--
Thanks,
Shiva
On Thu, Mar 6, 2008 at 3:31 PM, Shiva Kumar H R <sh...@gmail.com> wrote:
> I have committed Yun Feng's patch into GEP trunk. Thanks very much Yun
> Feng.
>
> Build is successful, except for below two modules:
> <module>org.apache.geronimo.st.v20.core</module>
> <module>org.apache.geronimo.st.v20.ui</module>
>
> Once those two modules are also ported onto JAXB, complete build would be
> successful.
>
> --
> Thanks,
> Shiva
>
> On Wed, Mar 5, 2008 at 10:44 PM, Shiva Kumar H R <sh...@gmail.com>
> wrote:
>
> > Perfect. Thanks Tim. I will concentrate on the various ui packages.
> >
> > Yun Feng,
> > Would you like to explore handling multiple schema versions?
> >
> > --
> > Thanks,
> > Shiva
> >
> > On Wed, Mar 5, 2008 at 10:18 PM, Tim McConnell <ti...@gmail.com>
> > wrote:
> >
> > > Shiva, with your current experience with the deployment plan portal,
> > > is it safe
> > > to assume you will again concentrate on the visual aspects of the
> > > refactoring
> > > (deployment plan editors, etc..??) If that is the case, I will
> > > concentrate on
> > > the various version specific
> > > server tool cores (e.g., org.apache.geronimo.st.core, etc)....
> > >
> > > Tim McConnell wrote:
> > > > Hi Shiva, thanks for the update. I will review Yun Feng's patches
> > > today
> > > > as well, and start on the refactoring effort as well.....
> > > >
> > > > 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.jaxbmodeland
> > > >> 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
> > > >> <ma...@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
> > > >> <ma...@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
> > > >> <ma...@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 <ma...@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
> > >
> >
> >
> >
>
Re: [Discuss] Model for deployment plans in GEP - Move from EMF to XMLBeans or JAXB?
Posted by Shiva Kumar H R <sh...@gmail.com>.
I have committed Yun Feng's patch into GEP trunk. Thanks very much Yun Feng.
Build is successful, except for below two modules:
<module>org.apache.geronimo.st.v20.core</module>
<module>org.apache.geronimo.st.v20.ui</module>
Once those two modules are also ported onto JAXB, complete build would be
successful.
--
Thanks,
Shiva
On Wed, Mar 5, 2008 at 10:44 PM, Shiva Kumar H R <sh...@gmail.com> wrote:
> Perfect. Thanks Tim. I will concentrate on the various ui packages.
>
> Yun Feng,
> Would you like to explore handling multiple schema versions?
>
> --
> Thanks,
> Shiva
>
> On Wed, Mar 5, 2008 at 10:18 PM, Tim McConnell <ti...@gmail.com>
> wrote:
>
> > Shiva, with your current experience with the deployment plan portal, is
> > it safe
> > to assume you will again concentrate on the visual aspects of the
> > refactoring
> > (deployment plan editors, etc..??) If that is the case, I will
> > concentrate on
> > the various version specific
> > server tool cores (e.g., org.apache.geronimo.st.core, etc)....
> >
> > Tim McConnell wrote:
> > > Hi Shiva, thanks for the update. I will review Yun Feng's patches
> > today
> > > as well, and start on the refactoring effort as well.....
> > >
> > > 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.jaxbmodeland
> > >> 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
> > >> <ma...@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
> > >> <ma...@gmail.com>> wrote:
> > >>
> > >> Please see 11-Feb IRC chat btw djencks, shivahr & mcconne
> > >> http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20080211for
> > >> 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
> > >> <ma...@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 <ma...@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
> >
>
>
>
Re: [Discuss] Model for deployment plans in GEP - Move from EMF to XMLBeans or JAXB?
Posted by Shiva Kumar H R <sh...@gmail.com>.
Perfect. Thanks Tim. I will concentrate on the various ui packages.
Yun Feng,
Would you like to explore handling multiple schema versions?
--
Thanks,
Shiva
On Wed, Mar 5, 2008 at 10:18 PM, Tim McConnell <ti...@gmail.com>
wrote:
> Shiva, with your current experience with the deployment plan portal, is it
> safe
> to assume you will again concentrate on the visual aspects of the
> refactoring
> (deployment plan editors, etc..??) If that is the case, I will concentrate
> on
> the various version specific
> server tool cores (e.g., org.apache.geronimo.st.core, etc)....
>
> Tim McConnell wrote:
> > Hi Shiva, thanks for the update. I will review Yun Feng's patches today
> > as well, and start on the refactoring effort as well.....
> >
> > 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
> >> <ma...@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
> >> <ma...@gmail.com>> wrote:
> >>
> >> Please see 11-Feb IRC chat btw djencks, shivahr & mcconne
> >> http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20080211for
> >> 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
> >> <ma...@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 <ma...@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
>
Re: [Discuss] Model for deployment plans in GEP - Move from EMF to
XMLBeans or JAXB?
Posted by Tim McConnell <ti...@gmail.com>.
Shiva, with your current experience with the deployment plan portal, is it safe
to assume you will again concentrate on the visual aspects of the refactoring
(deployment plan editors, etc..??) If that is the case, I will concentrate on
the various version specific
server tool cores (e.g., org.apache.geronimo.st.core, etc)....
Tim McConnell wrote:
> Hi Shiva, thanks for the update. I will review Yun Feng's patches today
> as well, and start on the refactoring effort as well.....
>
> 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
>> <ma...@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
>> <ma...@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
>> <ma...@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 <ma...@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
Re: [Discuss] Model for deployment plans in GEP - Move from EMF to
XMLBeans or JAXB?
Posted by Tim McConnell <ti...@gmail.com>.
Hi Shiva, thanks for the update. I will review Yun Feng's patches today as well,
and start on the refactoring effort as well.....
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
> <ma...@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
> <ma...@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
> <ma...@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 <ma...@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
Re: [Discuss] Model for deployment plans in GEP - Move from EMF to XMLBeans or JAXB?
Posted by Shiva Kumar H R <sh...@gmail.com>.
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 <sh...@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 <sh...@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 <da...@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 <sh...@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
> > >
> > >
> > >
> >
>