ws-scout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anil Saldhana <>
Subject Re: Scout v1.0 Changes
Date Thu, 16 Mar 2006 15:48:54 GMT
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. Even then, all these proposed changes were prototypical and not
b) We have brought in enough complexity into the Scout dev process, just to accomodate your
juddi classloading issue. All this is basically delaying our dev.

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.

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

Guillaume Sauthier <> 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 will declare a dependency on juddi-datatypes.jar
* Scout can reuse that shared codebase if scout build process includes 
something like JarJar ( that 
will change package names from org.apache.juddi.datatypes to 
=> 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 ?


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: *
> *
> 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.

 Yahoo! Mail
 Use Photomail to share photos without annoying attachments.
View raw message