Maybe we should take a conservative approach initially (and this is
probably something similar to #3, #4). As long as milestones are not
too infrequent then I think we can release the three subprojects on the
same schedule. Users should be able to easily pull SCA , SDO and DAS
components independently from a distribution.
Also, it does not seem too much an inconvenience for those interested in
working from the head to pull and build the entire project.
--Kevin
Rick wrote:
In theory I like what you're saying Jeremy, but in reality I'm kinding
of siding with Ant concerns. Not sure how it will scale as we add may
extensions and all the possible combinations. Also all the distros
add administration, documentation, issue tracking etc. I certainly can
see a separate SDO and possibly a separate DAS distro as I can see the
use case for that and it easily explained to the end user why they are
a separate distro for them. With regard to SCA I think a goal of
building them separately is good, having some test that just run with
each extension is good. But maybe for the SCA distro it would be
easier to have the full always the full distro and some how configure
to only deploy and run the pieces and parts the user wants? ant elder
wrote:
I like proposals 3 and 4 - it should be easy to build a distribution
and we
need to test it properly - +1! And having some sort of daily build
would be
great whatever ends up happening here.
In general the idea of having something more than a single monolithic
distribution sounds good, I've a few concerns (version
incompatibilities,
hard for newbies to choose a distribution, some things may become 2nd
class
parts of the Tuscany) which I'll leave till there's more detail, but
one big
problem I can see is that having lots of separate module/distribution
releases is will make it _really_ hard to get all the release votes
through
the incubator PMC. Wont that be a bit unworkable while we're still
incubating?
...ant
On 7/29/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
We've talked about this in the past on several threads but I would
like to bring this to conclusion. We've had a couple of issues
recently where bits of the build were failing due to environmental
issues (e.g. java.net repo availability, xerces versions on some JRE)
and we are about to start adding more dependencies with the
integration of the Axis2 module, the JSON modules, web containers,
etc. which will make this worse. I want to try and sum up here where
we are at and make some proposals for going forward.
==========
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).
==========
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.
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).
==========
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.
What this means: In the root of the sca project, the pom file will
contain profiles that contain all the modules needed for a particular
distribution. Each profile will build and package everything that
needs to go into the distribution bundle - the runtime, all bundled
extensions and the actual distribution bundle.
==========
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.
What this means: Each distribution has a test suite that tests the
kind of things that a user would do with it (based on what its
purpose was). The suite works by taking a distribution package,
installing it, installing test applications and exercising them. We
run these tests in the kind of environments that users have.
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.
This is essentially an enhanced version of the old testing/tomcat
environment - one that gets run frequently, automatically and in
multiple environments.
==========
I realize these are high-level proposals - more a statement of
principles really - but I wanted to capture the thinking behind the
proposal. If we think this is the right way to go then we can dig
into the detail needed to make it happen.
--
Jeremy
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
