What we're moving to on the "other side" is something like:
SCA Kernel
SCA XXX Distribution
SCA Maven Plugin for XXX
SCA Extension for XXX
It sounds like the C++ structure is evolving the same way with a
kernel, multiple distributions, extensions etc. In some ways I think
you have more infrastructure generally available with package
managers such as yum that allow users to easily install packages and
their dependencies. IMO that would allow you to get the advantages of
modular packaging without inconveniencing users (although you might
need to provide metadata for the different managers).
On the Java side we're moving to a model where users don't need to
manually install extensions - they can automatically be installed by
the runtime based on the SCDL content. For example, if we see
<impl.ruby> we'd automatically install the ruby extension where it
was needed. Could the "native" runtime do the same thing?
We're also distributing the samples separately so that users can pick
them up independently of the packages and vice versa. Samples in "non-
native" programming languages such as Ruby should run on both
"native" and Java runtimes - perhaps we should have one set?
Perhaps we should go even further and make the extensions top-level
modules. So (picking ruby as an example), instead of java/ruby and
cpp/ruby, have a single ruby module with java and cpp sub-modules.
Then the people working on ruby would be able to ensure consistency
for their users across both runtimes.
--
Jeremy
On Jan 26, 2007, at 2:23 AM, Andrew Borley wrote:
On 1/24/07, Oisin Hurley <[EMAIL PROTECTED]> wrote:
On 23 Jan 2007, at 10:55, Pete Robbins wrote:
> I was wondering whether we should package a Tuscany C++ kernel,
> which is
> the core runtime and cpp language extension, and have a separate
> package for
> scripting extensions ??
+1
--oh
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
OK, so we have a split vote here - some people preferring "Tuscany SCA
Native" and others preferring to split out the distributions into
something along the following lines:
"Tuscany SCA for C++" - contains kernel, C++ extension and C++ samples
"Tuscany SCA for Scripting" - contains Python, Ruby, PHP extensions
and samples, requires Tuscany C++
"Tuscany SCA for C++ Bindings" - contains WS (Axis2C), REST and SCA
binding extensions and samples, requires Tuscany C++
Alternatively, we could split these up even further, into a separate
package for each extension.
+ves for "Tuscany SCA Native": single downloadable package, no
languages named (avoids confusion), unified documentation.
-ves for "Tuscany SCA Native": requires lots of other packages to
build it (some of which aren't available, e.g. axis on Mac), includes
function that users may not need/want
+ves for separated packages: User downloads what they want to use or
what is available on their platform. Packages clearly say what is
inside them.
-ves for separated packages: More work to generate and test the
combinations of packages, possibility of packages getting out-of-sync
with each other (would need some versioning scheme?).
We could, of course, offer a single package containing everything as
well as the separated packages.
Thoughts, further votes, etc appreciated.
Andy
---------------------------------------------------------------------
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]
