On Aug 1, 2006, at 6:07 PM, Ken Tam wrote:
Proposal 1: Support independent build and distributions at the top
level
Rationale: Users interested in different technologies such as SCA and
SDO do not want to have to build all of them together. This also
gives a false impression that there are strong dependencies between
them.
What this means: Structure the build such that someone can check out
any directory under "java" and build it on its own. For example, if I
check out just "sdo" I would expect the build to work from that
directory. All dependencies (e.g. on spec) would be resolved through
the mvn repository.
This will require each technology to upload unstable artifacts (aka
SNAPSHOTs) to the mvn repository on some periodic basis. These are
not releases and do not need to be voted on.
Each technology will produce their own distribution. This may be a
user-installable distro (e.g. for sca or sdo) or may just be a set of
jars to be published in the mvn repo (e.g. for spec).
+1 on independent top-level build/distros, we already have no small
amount of confusion in the community at large regarding dependencies
between SCA & SDO.
Proposal 2: Break sca down into runtime libraries, distributions and
extensions
Rationale: SCA involves a lot of different technologies and runs in a
large set of environments that are not applicable to all users. We
will not be able to keep all of this in sync all the time.
What this means: The runtime is structured as a set of libraries that
provide the fabric for wiring services together. These libraries are
used by a number of host environments to create running SCA
containers (e.g. the launcher uses them to provide a command-line
client environment, the servlet launcher uses them to provide a
webapp based environment, the test harness provides an environment
around JUnit, ...). The interface to those libraries is defined by
the spi and proposed api modules. Modifications to the implementation
of those libraries should not be visible to the hosts or extensions
that use them. We can build and distribute (through mvn) these
libraries separately from the things that are using them.
In principal I think I agree with the intentions here, but I'm not so
clear on what it really means in practice. For example:
The interface to those libraries is defined by
the spi and proposed api modules. Modifications to the implementation
of those libraries should not be visible to the hosts or extensions
that use them.
As I understand it, today this is definitely not true -- hosts such as
the Launcher and SCATestCase are strongly coupled to implementation
classes coming out of the runtime libraries via their system.scdls.
It seems like changing this would imply that the the runtime libraries
would include a "core" set of system SCDL definitions that would be
leveraged by all hosts, and any host that wanted finer-grained control
would continue to remain tightly coupled?
I'm not sure there is an easy way around this. Most of the
dependencies are on things like loaders and builders. If we keep
these in system composite scdls, there is at least some level of
loose coupling since the dependency is on the composite component and
not its implementation (i.e. loaders and builders). I think we want
to keep things as flexible as possible since a custom launcher may
just want to prune everything down, perhaps not even having loaders
and instead using some other config mechanism.
That said, I still think we leak classes from core into some of the
extension modules (particularly around wires) so we may want to keep
an eye on that and create some kind of test harness for extension
builders to stop this from happening.
Also not sure how this would work for extensions -- since so many of
the SPI elements are abstract classes and not just interfaces, it
seems it would be hard to keep impl changes in such classes from being
visible to extensions.
Users want distributions to be something that they can download,
install and use for some purpose. We will build distributions with
such a purpose in mind and include within them everything that a user
would need to achieve it. For example, one purpose might be a client-
side install so we would include within that the minimal runtime plus
commonly used client bindings (e.g. web services); another purpose
might be for building web applications so we would produce a
distribution aimed to support web server functions (which may or may
not include a server platform); another might be as a service
intermediary which may have a very rich set of bindings.
All distributions will support some form of extension mechanism that
allows users to add functionality by installing extension modules.
These modules will be released and distributed separately. Some may
be included by default in some distributions (e.g. web services).
+1 to this philosophy of distros. In particular, I think we want to
have a system where getting and installing extensions is super-easy a
la maven plugins or ant tasks -- no one really worries about whether
extensions to those programs "ship" with the default distro, since
it's so easy to add them afterwards. Ant's earlier concern that not
being in a distro might make an extension "2nd class" is definitely
something we want to avoid, but I think the right way to do that is to
make post-facto inclusion really easy rather than including more
extensions by default.
Yea, I think this is really key. Something like Eclipse plugins. As
we expand the number of extensions, the resulting combinations will
make having distributions for every one unmanageable. Having an easy
mechanism to download on demand will provide a good solution to this.
Taking Eclipse as an example again, I think the risk of making
something second class may be attenuated by a having a small core
distro with a good download system and good documentation/publicity
for the extension. For example, WTP is not in the Eclipse core but
doesn't seem second class.
I'm also concerned about forcing users to deal with a technology
monolith. It's really important we allow choice with Tuscany and
allow people progressively "buy into" whatever combination of
technologies they need. Spring has been really successful with this
approach. You can mix and match different pieces, including parts of
Spring itself, and they don't force users to disable things they
don't want. With Spring, people can use Spring WebFlow or they can
use whatever other UI technology such as Struts, WebWork, or
Tapestry. Likewise for the data tier, people can use Spring's JDBC
abstraction layer or Hibernate, iBatis, or Kodo.
Regarding Tuscany, someone may want to use DAS in a J2EE web app
without SCA. Or someone may want to use Celtix, JAXB and JPA with SCA
as opposed to Axis, SDO and DAS. They shouldn't be forced to download
and disable the pieces they do not need.
Proposal 3: It should be easy to build a distribution (including
everything that is in it).
Rationale: We want to be able to build these things easily.
+1, how can anyone argue with "making something easy" :) I need to
spend more time understanding what's possible here before I have a lot
more to say..
Proposal 4: We need a test suite for each distribution that mirrors
user experience
Rationale: When a user installs a distribution it's helpful if it
works.
...
We can't do this every time we build as not everyone will have access
to every environment. Instead we use a CI framework such as Continuum
that can build or download a distro and exercise it on a variety of
platforms. Any failures get converted to high-priority JIRA issues.
Last time I was involved in this sort of thing around Beehive, the ASF
did not really support any kind of CI infrastructure for its projects.
Has that changed? Might we persuade a company or two to pony up a
machine on the internet? I really like CI, though most of my
experience is with cruise control rather than continuum.
I thought they may have added this. There's also TeamCity - OpenJPA
is using this, hosted by BEA, and it looks pretty cool. Maybe we
could check into this?
---------------------------------------------------------------------
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]
