ws-scout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Sauthier <Guillaume.Sauth...@objectweb.org>
Subject Re: Scout v1.0 Changes
Date Fri, 17 Mar 2006 09:59:16 GMT
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 ?).

> Even then, all these proposed changes were prototypical and not 
> finalized.

The XMLBeans Scout was tested within JOnAS test suite and was working well.

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

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

>
> 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.
>     >
>     >
>
>
> ------------------------------------------------------------------------
> Yahoo! Mail
> Use Photomail 
> <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=38867/*http://photomail.mail.yahoo.com>

> to share photos without annoying attachments.



Mime
View raw message