A good step would be for Guillaume to submit his work involving JCA as a contribution to Apache so that we can use it in Apache Scout. Then the customer will have the choice of plug and play.
--- Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Guillaume, > > If you sign up for the additional work :) then you > can have it :) :) > Seriously, am looking forward to improving both > projects AND looking > forward to more participation from redhat and > objectweb. > > -- dims > > > On 8/18/05, Steve Viens <[EMAIL PROTECTED]> wrote: > > Initially we developed Scout on top of jUDDI in > order to quickly produce a > > type 0 JAXR provider. Type 0 (zero) providers > support accessing UDDI > > registries only. The goal however is for Scout to > become a type 1 provider > > which would include support for both UDDI and > ebXML registries. > > > > As you would probably expect, there are no plans > for jUDDI to support ebXML. > > If a move to an XMLBeans would enable Scout to > support both UDDI and ebXML > > (a type 1 provider) then I'm in favor of a move to > XMLBeans and eliminating > > Scout's dependency on jUDDI. > > > > Steve > > > > > > On 8/18/05, Fernando Nasser <[EMAIL PROTECTED]> > wrote: > > > Davanum Srinivas wrote: > > > > Fernando, > > > > > > > > Please include everyone's view point. If > people who use juddi want to > > > > use scout they should not have to include > xmlbeans jars (EXACTLY the > > > > way you don't want to use juddi jars). So best > case scenario here is > > > > to have a pluggable way in scout to do either > xmlbeans or juddi types. > > > > No one is going to complain that way. Please > let me know if this is ok > > > > for you. > > > > > > > > > > It actually seems that the types used by jUDDI > are unrelated (i.e. they > > > should be) to the ones used by Scout (except for > some JARX types to UDDI > > > or ebXML mapping defined by the JAXR spec). > > > > > > Scout and jUDDI should only communicate using > SOAP messages and be > > > completely independent code-wise. > > > > > > So jUDDI can continue to use its own types (UDDI > types?) and Scout can > > > switch to the more independent XMLBeans, as it > should not be using any > > > UDDI or ebXML type internally. > > > > > > Does that make sense? > > > > > > > > > > > > > -- dims > > > > > > > > On 8/18/05, Fernando Nasser < > [EMAIL PROTECTED]> wrote: > > > > > > > >>Hi Anil, > > > >> > > > >>Anil Saldhana wrote: > > > >> > > > >>>Scout 0.5 release will be done the way it is. > > > >>> > > > >> > > > >>0.5 ? > > > >> > > > >>But your trunk/etc/project.xml already says > > > >> > > > >><currentVersion>1.0-SNAPSHOT</currentVersion> > > > >> > > > >>As a result Apache Geronimo and ObjectWeb > JOnAS, as well as Red Hat > > > >>RHAPS and the JPackage.org RPM of Scout have > all been labeled > > > >>1.0-SNAPSHOT (+date). > > > >> > > > >>Going back to anything less then 1.0 now will > break everybody's > > > >>dependency checks. > > > >> > > > >>Can't you continue to use 1.0-SNAPSHOT until > you are ready for 1.0? > > > >> > > > >> > > > >> > > > >>>Once we add the asynchronous feature > required by the > > > >>>JAXR 1.0 spec, we will do the Scout 1.0 > release. > > > >>> > > > >>>Before we do the 1.0 release, we can see if > there is > > > >>>really any major incentive in removing the > juddi data > > > >>>types and bringing in XMLBeans. > > > >>> > > > >> > > > >>A major incentive: not bringing the juddi jar > into the classloader space > > > >>of anyone who wants to use Scout, perhaps even > with some other Directory > > > >>service different from jUDDI. > > > >> > > > >>I was talking to Guillaume on irc and we think > that a complete > > > >>separation between Scout and jUDDI would be > ideal. > > > >> > > > >> > > > >> > > > >>>At Scout and jUDDI, we have always fostered > pluggable > > > >>>deployments. > > > >>> > > > >> > > > >>But in this specific case, there doesn't seem > to be any advantage at all > > > >>in providing pluggable _internal_ types. > > > >> > > > >> > > > >> > > > >>>Using juddi data types is an internal > implementation > > > >>>detail of Scout. So there are no issues with > using > > > >>>XMLBeans as an internal implementation > detail. But we > > > >>>need to investigate and test. > > > >>> > > > >> > > > >>Right. We would be willing to help changing > the types if everyone is in > > > >>accordance with that. > > > >> > > > >> > > > >> > > > >>>I will have to look at XMLBeans a bit > further. > > > >>> > > > >> > > > >>Thank you. > > > >> > > > >> > > > >>Best regards, > > > >>Fernando > > > >> > > > >> > > > >> > > > >> > > > >> > > > >>>--- Fernando Nasser < [EMAIL PROTECTED]> > wrote: > > > >>> > > > >>> > > > >>> > > > >>>>Davanum Srinivas wrote: > > > >>>> > > > >>>> > > > >>>>>Fernando, > > > >>>>> > > > >>>>>then folks who primarily use juddi and want > to use > > > >>>> > > > >>>>scout on the client > > > >>>> > > > >>>> > > > >>>>>will have one less library to deal with :) > > > >>>>> > > > >>>> > > > >>>>Are you saying that you agree with using > XMLBeans > > > >>>>and dropping the jUDDI > > > >>>>types (on both sides, Scout and jUDDI of > course)? > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>>-- dims > > > >>>>> > > > >>>>>On 8/17/05, Fernando Nasser < > [EMAIL PROTECTED]> > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
