On Nov 2, 2006, at 7:35 AM, Jeff Genender wrote:
I originally wrote the persistence.xml parser for openejb3 and used
the
jaxb plugin to produce that. It was later decided to just generate
the
code once and save it in the repo instead of having it generate on
each
build. This has some advantages, but it has one big disadvantage,
which
is that the code will change based upon spec/code changes from Sun,
and
will likely obsolete itself. Well...this happened.
I would like to heavily advocate that we go back to the
generation. Sun
has made some big changes in the code for JAXB and has (not
deprecated)
removed some annotations. This means our code is likely obsoleted
based
on the latest Sun jars. I noticed this when upgrading the Sun jars to
the latest stable (2.0.3) of Jaxb when working with gcache. If we
generate them on builds, I think we won't have to be concerned about
this issue when Sun upgrades the jars.
Comments?
I updated us to 2.0.3 and nothing broke for us at least -- guess
gcache wasn't so lucky.
Regardless, I'm cool talking about other ways to manage this.
My biggest concern is not wanting a deployment system written
entirely against a set of objects that change based on spec/code
changes from Sun. I had thought that JAXB2 offered a nice middle
ground where it can marshall into an object tree that you can "own"
and changes in your tree or the JAXB marshaller don't cause any
breakage as long as everyone stays spec compliant. If JAXB can't
deliver on that maybe we need to reduce our investment in JAXB?
Thoughts?
-David
