+1 for guidelines mentioned by Jeremy on this thread, I also think we should consider these guidelines not only for new code, but to review and evaluate existing dependencies in current code. We should also look for multiple dependencies/multiple implementation of same dependency (e.g TUSCANY-564)<http://issues.apache.org/jira/browse/TUSCANY-564>and try to cleanup those.
- Luciano On 7/24/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
I'd like to focus on dependencies in general rather than those from this patch. IMO whether we add an additional dependency comes down to what value does doing so provide to a user and at what cost. Some of that value comes in the form of additional functionality. Using someone else's implementation often leads to more function being delivered at better quality and in quicker time. After all, if someone who is a specialist in a area is going to write something they will probably do a better job than you. Add in, people who are volunteers often want to get something done in the best yet simplest way possible and letting someone else do the heavy lifting is a simple and easy way of doing something. However, dependencies come at a price. They may provide too much functionality, resulting in too large a footprint or too much complexity; or they may not be rich enough. They may have slightly different design goals leading to a impedance mismatch, or be from a community not receptive to your input. They may be so specialized that no-one else on the project can figure out what is going on. There is also the addition of dependency management - keeping control not only of our dependencies but also of all the downstream ones. Experience has shown that the "shove everything on the classpath" model does not scale. We may not need all the import/export mechanisms that OSGi provides, but we should work in that environment and should provide some form of dependency management in standalone environments. Taking that into account, I'd suggest the following guidelines: * We should use standard APIs wherever practical with no dependency on the actual implementation. * We should not require users to supply dependencies that are not actually used. For example, API classes should be structured so that they do not require dependencies to be present just to allow the class to be defined. * Tuscany distributions should be as modular as possible with a few dependencies in the core as possible. * Adding a dependency to the core should be viewed with skepticism and require review. * Adding a dependency to a extension module should be localized to that module and be "no big deal" * Modules may often use different implementations of the same function; again "no big deal" * We must support multiple versions of a dependency wherever possible. For example, two extension modules that require different versions of a common dependency should both be loadable. * We should avoid dependencies that are mismatched with the function needed. For example, there was a recent proposal to use commons-codec to encode a URL; given the stability of the encoder implementation, it may make more sense to copy in the source code (preserving licensing, copyright etc.) than pull in a dependency that had 100 times more stuff than we needed. Better still is to provide feedback to commons-codec to help improve their modularity. Finally, in terms of how other projects handle it, there is a natural tendency for Apache projects to use other Apache projects or other license-compatible projects in general. If something can be improved then there is a sense of community in making things better for all. Modularity, dependency management and good judgement keep the "kitchen-sink" mess under control. -- Jeremy On Jul 24, 2006, at 7:48 AM, Frank Budinsky 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]
-- ----------------------------------------------------- Luciano Resende SOA Opensource - Apache Tuscany -----------------------------------------------------
