Hi Venkat, For TUSCANY-535, we can commit the patch as is, for now, and then look at alternative implementations later. But if you are willing to consider reimplementing it right away, that would be even better. I wanted to start a discussion on the issue of dependencies anyway because I believe it's a general problem that we need to figure out how to handle. For example, who knows, even if you do look at implementing it with existing dependencies, it might still turn out that adding the new dependencies is a better way to do it. We really need to figure out what the dependency rules should be, so I'd be happy to hear suggestions from everyone.
Thanks, Frank. P.S. EMF's XMLResource has a save() method to save to DOM, that you could use, but SDO 2.1 is going to introduce new methods to hide it: XMLDocument load(Source inputSource, String locationURI, Object options) throws IOException; void save(XMLDocument xmlDocument, Result outputResult, Object options) throws IOException; The Source can be StreamSource, DOMSource, SAXSource, StAXSource while the Result can be StreamResult, DOMResult, SAXResult and StAXResult. So it might be good to go ahead and implement that right away :-) It's also possible that with the EMF XMLSchema model, you can add your annotations directly to the model, so you might not need the DOM tree. Maybe we should talk about the alternative impl of TUSCANY-535 on another thread. "Venkata Krishnan" <[EMAIL PROTECTED]> wrote on 07/24/2006 01:16:02 PM: > Frank, > I must fully agree with your standpoint on not flooding Tuscany with > dependencies especially if they are duplicating functionality already > present. I don't think it is a right approach to oversee this just for the > sake of encouraging community participation. > > If there is a competing dependency that wishes to stay, then it must clearly > win over the others in terms of functionality (being a superset) and in > terms of other quality characteristics such as performance, extensibility, > foot print etc. However I do not know what should be approach if the two > were equal or if both of them had a delta functionality that did not > overlap. > > I do not claim ws-commons XmlSchema to be better than its EMF counterpart. > Here are the simple reasons why I brought in those dependencies > - I was more familiar with Xml Schema model classes from ws-commons than > with its counterpart in EMF. > - I did peer into the EMF classes for XSD but could not figure out an API > for serializing the XSD into a DOM. > - I needed the DOM for the XSD in order to add the SDO Annotations. Here > again the XmlSchema classes and the EMF classes for XSD did not have an > obvious API to add additional attributes for SDO Annotations, into the XML > schema types and elements. Hence I took an approach of adding the SDO > annotations after serializing the schema into a DOM and working with the DOM > elements. Here is where the Axiom dependencies creeped in. > - Finally the commons-logging was an indirect dependency that came in. > > If the community can help me with some alternate approaches or point me to > the relevant EMF class libraries that can help me do these I shall, most > willingly modify this patch rightaway and resubmit it. I shall not be > discouraged by this. On the contrary I would feel encouraged about being > able to grow with this community :-) > > - Venkat > > On 7/24/06, Frank Budinsky <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > A recent patch, provided for TUSCANY-535, has raised the issue of how will > > we control project dependencies and make sure that Tuscany doesn't become > > a mess - a "kitchen sink" of dependencies and technology. The specific > > issue with TUSCANY-535, is that It introduces several new dependencies to > > the SDO project. What's worse is that these new dependencies are > > duplicates of equivalent function provided in existing EMF-based > > dependencies (e.g., a different XML Schema model). If we generally accept > > this kind of change, I think that Tuscany will soon become a mess. On the > > other hand, rejecting patches contributed by the community will not help > > the project to succeed at Apache. > > > > So the question is, what are the rules? > > > > 1) At what point do we add a new dependency vs. duplicate the function in > > Tuscany? > > 2) How do we decide which, of possibly many competing, components to use > > as a dependency? > > 3) Once we have a dependency that implements a particular function, can we > > introduce another different dependency, providing similar/same function? > > 4) Are there good ways to break these things out into replaceable > > alternative implementations? > > 5) Does anyone know if and how these issues are handled in other Apache > > projects? > > > > Thanks, > > Frank. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
