David Blevins wrote: > > I updated us to 2.0.3 and nothing broke for us at least -- guess gcache > wasn't so lucky.
I was building against 2EA3 and I blew up on the jump to 2.0.3. So maybe that was my problem building against early access stuff, and using current jars...which leads to my answer below...and my overall concern. > > 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? > I think out of all of the APIs, JAXB is the way to go as it seems to have the simplest access and cleanest API, not to mention it will be a heavy standard moving forward. I think we made the right choice with this one. Regarding the jars, the only thing that changed was the internal annotations which should not affect our code that is utilizing it. But not regenerating will cause problems when we move ahead in jar version w/o regenerating the code. That was what I ran into and it seemed to me that the generating against the current jar set is the least cost way of having problems. My point here is that is we go to another 2.0.x version, our old generated objects may not compile (as happened to me), and we may need to regen. I think using a maven plugin to regen on build will prevent us from future headaches. Just my .02. Jeff > Thoughts? > > -David
