Re: Scout v1.0 Changes

Fri, 17 Mar 2006 01:59:36 -0800 

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 <[EMAIL PROTECTED]>/* 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.




begin:vcard
fn:Guillaume Sauthier
n:Sauthier;Guillaume
org:<a href="http://www.objectweb.org";><img title="Objectweb" alt="Objectweb" border="0" src="http://www.objectweb.org/media/interface/logoow3.gif"; /></a> Open Source Middleware
adr:;;;;;;France
email;internet:[EMAIL PROTECTED]
title:<a href="http://jonas.objectweb.org";>JOnAS Application Server</a>
x-mozilla-html:FALSE
url:http://jonas.objectweb.org
version:2.1
end:vcard



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





















					Reply via email to