geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: [Discuss] Moving JAXB classes from GEP to G (was Shifting from xmlbean to JAXB in PlanCreator)
Date Tue, 29 Jul 2008 18:15:40 GMT

On Jul 29, 2008, at 10:15 AM, Shiva Kumar H R wrote:

> I too am +1 to moving JAXB classes from Geronimo Eclipse Plug-in  
> (GEP) to Geronimo (G). That way in addition to GEP, G's deployment  
> system in future, Plan Creator and may be some others too will reap  
> the benefits of JAXB.
> One concern however is about "where should the JAXB classes be moved  
> to?" I see two ways for this (please correct me if I am wrong here):
> A) Move JAXB code into server (

> ) as a new module or plug-in and release it along with server.
> B) Move JAXB code into specs (

> ) and release it whenever the schema changes. (for ex. I see  
> geronimo-application-2.0.xsd has not changed across G 2.0, 2.1 &  
> 2.2, however G2.0 had plugins-1.2.xsd, while G2.1 & G2.2 have  
> plugins-1.3.xsd).
> And below is my reasoning to consider Approach-B:
> i) GEP has traditionally supported previous releases of G too. For.  
> ex. in addition to current G2.1 (and its minor versions), GEP also  
> supports G2.0. A major reason behind this I think is to allow easier  
> porting of applications from one version to another.
> ii) Now, if we move away JAXB classes from GEP and put it into G  
> server (approach-A), then these JAXB classes will only be available  
> starting from G2.2 onwards and will probably support only latest  
> version of G schemas. So how should GEP support previous versions of  
> G servers and G schemas?
> iii) If however, we move JAXB classes into G specs and release a new  
> spec-jar everytime a new version of G schema comes up, then GEP will  
> easily be able to support multiple versions of G server & G schemas.

Hi Shiva,
Can you point us to the JAXB classes that you are referring to?

geronimo/specs contain our EE specs. I'm having trouble imagining why  
we would start including non-EE artifacts in specs. Doesn't mean that  
we can't achieve desired results from a different location.

Possible that this work could be associated with migrating to use CDDL  
licensed deployment descriptor xsd's (and not use comment-removed  
xsd's generated from tck).


View raw message