Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/23/2006 02:02:00 PM:

> I think we need to be careful to distinguish the needs we have for 
> loading our configurations from the needs users have of SDO in general. 
> I think the SCA schemas have things in them that are atypical: lots of 
> extensibility, many namespaces, custom data types, few 
> attributes/properties and so forth. 
That's what I initially thought until Sebastien pointed me at the model - 
which I finally spent more than 2 minutes looking at :-) I think that 
aside from the wildcard extensibility hooks, the model is, itself, quite 
reasonably structured. 

> On the other hand, our use case 
> doesn't need things like change tracking or streaming that SDO provides.
My main point is that this IS a very common general use case. We need to 
support it well.

> 
> We need a good SDO implementation, we need a loading mechanism that can 
> handle our configurations; the two don't have to be the same. If they 
> are, that is good; if they aren't, that's not bad.
True ... but if we can make them the same, I think we should.

Frank.

> 
> --
> Jeremy
> 
> Jean-Sebastien Delfino wrote:
> > Raymond Feng wrote:
> >> Hi, Frank.
> >>
> >> I think I fully agree with you. An efficient databinding is what 
we're 
> >> looking for.
> >>
> >> Ideally, if SDO later on supports lazy-loading (create the DataObject 

> >> skeleton first and pull in properties as they're assessed) from 
> >> XMLStreamReader, I assume we'll take advantage of the benifits 
> >> advocated by both camps (Databinding vs. StAX).
> >>
> >> Raymond
> >>
> >> ----- Original Message ----- From: "Frank Budinsky" 
<[EMAIL PROTECTED]>
> >> To: <[email protected]>
> >> Sent: Thursday, March 23, 2006 9:37 AM
> >> Subject: Re: Framework for StAX-based model loading
> >>
> >>
> >>> I stand by my statement that the EMF problem is short term pain for 
long
> >>> term gain :-) I think that in the long term using the SDO generator 
will
> >>> be the best and easiest way to do this. Yes I am biased, but I've 
> >>> seen it
> >>> before - avoiding reuse/dependencies works nicely at first, but as 
> >>> things
> >>> grow/change and get more comlicated, the amount of 
reworking/reinventing
> >>> becomes quite a nightmare. The opposite problem, which I think we're
> >>> suffering from here, is that the reusable component that we are 
> >>> trying to
> >>> leverage isn't as nice and clean and a perfect fit as we'd like, so 
it
> >>> really looks undesirable. Since we have control of all the pieces, 
in 
> >>> this
> >>> case, I think we have a great opportunity to make it a clean fit. 
And 
> >>> like
> >>> I said in my reply to Jeremy, earlier, I really strongly feel that 
the
> >>> problems that we're identifying here are not unique to SCA, so 
fixing 
> >>> them
> >>> is really in our best interest.
> >>>
> >>> Frank.
> >>>
> >>> "ant elder" <[EMAIL PROTECTED]> wrote on 03/23/2006 10:13:24 AM:
> >>>
> >>>> On 3/23/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>> <snip/>
> >>>>
> >>>>  As the binding itself uses JAXB2 (though it may change in
> >>>> > the future), I have to include all eclipse dependencies and SDO 
> >>>> stuff,
> >>>> > just to load the system configuration files :(
> >>>>
> >>>>
> >>>> From the discussion I'm starting to be persuaded by some of the
> >>> arguments
> >>>> for the SDO approach, but this EMF dependency seems a draw back. If
> >>> we're
> >>>> going to support alternate data bindings for the WS binding its not
> >>> great to
> >>>> still be dragging in EMF to run the thing. And I'd guess it would 
be
> >>> much
> >>>> easier to sell SDO to say the Axis2 guys to use instead of XmlBeans 
if
> >>> there
> >>>> was a pure Java SDO impl. Any Axis2 guys listening who'd comment on
> >>> this?
> >>>>
> >>>> As another comparison look at Axis2, they have their own very 
simple
> >>> Axis
> >>>> Data Binding (ADB) which supports simple XSDs, and they use 
XmlBeans 
> >>>> for
> >>> all
> >>>> the complicated stuff. They don't use XmlBeans all the time because 

> >>>> lots
> >>> of
> >>>> things don't need the complexity a full blown data binding brings. 
And
> >>> as
> >>>> Guillaume points out, the SCA binding schema are usually pretty 
simple.
> >>>>
> >>>>    ...ant
> >>>
> >>
> >>
> > Raymond,
> > 
> > That's a very good point, I agree.
> > 
> > I think that this whole discussion thread is very useful as it helps 
us 
> > identify requirements and areas of improvement for our SDO databinding 

> > and codegen story. For example, Guillaume mentioned that it would be 
> > great to have a Maven 1 SDO codegen plugin, as ServiceMix is still 
built 
> > with Maven 1 at the moment (and I guess a number of other projects out 

> > there still use Maven 1 as well). I can spend some time in the next 
few 
> > days and work with anybody who would like to volunteer and try to wrap 

> > the code generator in a Maven 1 plugin, if it helps. Guillaume, are 
you 
> > using Ant at all? or just Maven 1?
> > 
> 
> 

Reply via email to