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]
