ws-scout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Bhole <dbh...@redhat.com>
Subject Re: Scout v1.0 Changes
Date Fri, 17 Mar 2006 15:01:04 GMT

Hi Guillaume,

To answer a couple of your queries:

On Fri, 2006-03-17 at 10:59 +0100, Guillaume Sauthier wrote:
> Anil Saldhana wrote:
> 
> > The moral of the story is:
> > a) I had asked for the XMLBeans data types for juddi to be integrated 
> > into Scout. Not to bring in a dependency on xmlbeans.
> 
> AFAIK, If you're using using XMLBeans, you add a compile time deps (when 
> you geenrate your object classes) AND a runtime deps (because theses 
> generated objects needs XMLBeans Runtime - XMLObject ?).
> 

Right. xmlbeans is needed at run time as well, since it handles
serialization/deserialization and other generic things (e.g validation).

> 
> And the support of ebXML ?
> Is it based on XMLBeans too ?
> If this is the case, dropping xmlbeans, will drop ebxml too :'(
> 

ebXMLrr uses castor, not xmlbeans. But it too will be needed at run
time.

> >
> > Juddi data types are stable and do not change. What is the guarantee 
> > that xmlbeans will generate the right types over time? There will be 
> > bugs in either juddi data types or xmlbeans generated types and we are 
> > here to fix them.
> 
> True, we're here to correct bugs :)
> Anyway, I still think that copying java classes into Scout is not the 
> right solution.
> Adding a dependency (and changing package name) is cleaner...
> 
> >
> > JUddi has the juddi proxy jar which just contains the datatypes and 
> > the proxy code.  Are you guys ok with that or you have CL issues also 
> > with that?  If you are ok with that, then that is what we have in 
> > Scout v0.5
> 
> We're not OK with reusing juddi datatypes 'as is'.
> I think it's a good compromise to have a deps on juddi proxy.jar AND 
> changing the package name.
> So there is no code duplication, if there is a fix in juddi datatypes, 
> we just have to take the next version of the proxy.jar. package names 
> change should be integrated in the build process ...
> 
> Guillaume
> 
> >
> >
> > */Guillaume Sauthier <Guillaume.Sauthier@objectweb.org>/* wrote:
> >
> >     So if I sum up :
> >     * You don't want an XMLBeans dependency for Scout
> >     * We don't want to use jUDDI datatypes 'as is' because of some
> >     obscure
> >     ClassLoader issue
> >     * You propose to copy the jUDDI datatypes into Scout
> >
> >     Here are my comments :
> >     * XMLBeans integration is something started a long time ago... Why
> >     didn't you have any reactions about that integration sooner ?
> >     * Copying jUDDI datatypes as is (ie not changing package name)
> >     will not
> >     solve our ClassLoader issue
> >     * If there is a fix in jUDDI datatypes (jUDDI seems pretty stable,
> >     but a
> >     bug can be found at anytime), Scout developpers has to manually
> >     update
> >     their own codebase. This is error prone :'(
> >     * Moreover, that solution is not very elegant, don't you think ?
> >     Seems
> >     like "Quick and dirty" ...
> >
> >     And my proposition :
> >     * separate cleanly jUDDI datatypes from jUDDI (aka having a separate
> >     project ?)
> >     * jUDDI w ill declare a dependency on juddi-datatypes.jar
> >     * Scout can reuse that shared codebase if scout build process
> >     includes
> >     something like JarJar (http://tonicsystems.com/products/jarjar/) that
> >     will change package names from org.apache.juddi.datatypes to
> >     org.apache.scout.uddi.v2
> >     => So at runtime, Scout will use it's own repackaged classes,
> >     resolving
> >     our CloassLoader issue, their will be no deps on XMLBeans, and
> >     there is
> >     a clean separation between jUDDI, datatypes and Scout ...
> >
> >     Notes :
> >     JarJar is used in cglib to provide a cglib-nodep jar file for ASM
> >     (suppress ClassLoader issues with ASM versionning)
> >
> >     Thoughts ?
> >
> >     Regards
> >     Guillaume
> >
> >     Anil Saldhana wrote:
> >
> >     > As much as I like XMLBeans. Even though it is an Apache project
> >     (good
> >     > for us). But the XML Binding space is in flux now- JAXB is the only
> >     > standard that is available IMO. I do not want to introduce a
> >     > dependence on a xml binding library into Scout.
> >     >
> >     > You can clearly see the introduction of xmlbeans library
> >     dependence in
> >     > Scout: *http://tinyurl.com/mp7r7
> >     > *
> >     > Scout is anyway required to carry the uddi types. So we may as well
> >     > have it borrowed from the juddi project. As per the additional
> >     juddi
> >     > stuff that gets pulled into Scout, it is still fine because we
> >     remove
> >     > the dependence on both juddi and xmlbeans. As we move forward,
> >     we can
> >     > remove the additional baggage.
> >     >
> >     > When we do uddiv3, we will have its datatypes in Scout - no problem
> >     > with that.
> >     >
> >     >
> >

Deepak

Mime
View raw message