We talked about this face to face amongst the various people who
attended the barcamp last weekend and I thought that we had at least
some common understanding for the "describing groups of function" part
of this puzzle. But in off list conversations that still seems not to
be the case.
I really think that, in order to cut the 2.0 Beta RC, we need an
easily stated and clear approach to describing how our users create a
"classpath" from our binary distro in all of the situations they are
likely to need to do so. My personal motivation is to have the users
always think about describing a base jar alongside whatever extensions
they want to use. So here's me compromising on what I'd really like
and making another attempt to pull this all together.
Inputs (from our source tree)
=====================
/modules - contains a mixture of core and extension jars.
You spot extensions as they start binding/implementation etc and
end in runtime-*
You create a maven dependency on a extension by creating an
dependency on its runtime jar
/features - describe collections of extensions or other jars
all - describes all the jars.
Currently a combination of other features and individual jars
I'd like this to be a list of base + extensions rather
than referring generally to other features
base - describes the core jars and enough extensions to get
impl.java scenarios working
We can include a shade plugin here to generate the base jar
we don't use any other features at the moment so we should weed
any that aren't wanted
/samples
I would like these to refer, via maven, to base + extensions as
appropriate, i.e take the base feature and then
any extension runtimes that are required
/distribution
/all - refers to the all feature at present + some other arbitrary jars.
we either need to tidy up the all feature and clean up
the reference to it or remove the feature and
include the list of base + extensions here. What do
people want to do?
Outputs (in the binary distro)
=====================
/modules
all of the Tuscany jars and dependency jars layed out as they are at present
/extensions
/ binding.ws
dependencies - a human readable file that lists the jars, in
modules, that this extension depends on
in case someone wants to pull those files out either
manually or by writing a script
+ any other meta-data derived files that we wish to ship based
on each extension , e.g.
a manifest file (as we have at the moment)
an ant build path file (as we have at the moment)
a bundle repo config file (just thinking aloud)
/features
/all
as extensions +
a PDE target (as we have at the moment)
an OSGI config.ini file (as we have at the moment)
/base
as extensions +
a shaded jar
a PDE target (not sure about this as you will likely need
extensions also)
an OSGI config.ini file (not sure about this as you will
likely need extensions also)
/samples
maven = dependencies as per input
ant = dependencies exploit base + extension approach (based on
generated build path files)
I still don't necessarily think this completely ticks the "is it clear
and easily stated" box but I could live with it for the Beta RC where
we can take a step back a get a feel for it in action. Can we jiggle
this around until we get something we are generally prepared to live
with?
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
