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]
