On Jul 29, 2008, at 11:26 AM, Shiva Kumar H R wrote:
On Tue, Jul 29, 2008 at 11:45 PM, Kevan Miller
<[EMAIL PROTECTED]> wrote:
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 (https://svn.apache.org/repos/asf/geronimo/server/trunk/
) as a new module or plug-in and release it along with server.
B) Move JAXB code into specs (https://svn.apache.org/repos/asf/geronimo/specs/trunk/
) 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?
Thanks Kevan for looking into this. Here it is:
https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.jee.v21.jaxbmodel/src/main/java/org/apache/geronimo/jee/
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).
--kevan
I still haven't really figured out if these are for the jee deployment
descriptors or the geronimo plans.
I think the ones for the ee dds should be in a single module, possibly
in specs or somewhere in server.
I think the ones for geronimo plans should be with the builders or in
related modules, i.e. one jar per builder. I'm going to look into
converting the jetty7 builder (in sandbox) to using jaxb (and actually
sxc).
thanks
david jencks
--
Thanks,
Shiva
