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 <[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. > > > > > > > > Deepak
signature.asc
Description: This is a digitally signed message part
