ant elder wrote:
On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
Raymond Feng wrote:
Hi,
There are a few patterns we use to determine if a maven module is
required. Let's take the contribution stuff as an example.
1) contribution contains the interfaces for the contribution model and
default implementation classes, SPIs and extension points
2) contribution-xml deals with the reading/writing the xml document for
the sca-contribution.xml
3) contribution-java, contribution-namspace, contribution-resource deal
with a specific perspective of the contribution, for example, namespace,
java, resource
4) contribution-osgi, contribution-groovy support specific packaging
schemes of the SCA contributions.
Please note there is a tree-like dependency graph. I don't think it makes
sense to merge the siblings into one module. Since an ancestor (for example
contribution) are shared by mulitple children (-xml, -osgi, etc), it also
not desirable to merge the common ancestor with other modules.
For databinding related modules, we have a similar strcuture:
1) databinding: The base model, SPIs and transformers for various XML
technologies
2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The
individual databinding technologies
3) core-databinding: A set of hook code that leverage the databinding
framework in the invocation chains (data transformation interceptors)
We can use 1 as the data transformation utility in binding/implementation
or even 3rd party code without 3. We can also pick one or more modules from
2.
What I'm trying to point out is that our maven module structure reflects
the nature of the feature units and dependencies fairly well. IMO, each
module maps well into an OSGi bundle. IMHO, both the maven module and OSGi
bundle follow the same principles and the results should be consistent.
Thanks,
Raymond
+1 to all that, makes a lot of sense to me!
Sorry, but it doesn't make sense to me. If there is no user scenario
that can pull in contribution-java but not contribution-resource,
or vice versa, I don't see why we would choose to expose these in
our distro as separate bundles. For the databindings, there are
user scenarios in which a subset would be needed by different users,
so things like databinding-jaxb and databinding-sdo should be in
separate bundles. However, core-databinding and databinding would
always be used together, so should be in the same bundle.
There might be a reason for keeping these modules separate in the
maven build, to reflect an internal functional split. This internal
structure is not relevant to Tuscany users and should not be exposed
to them.
I think our distro should have a bundle for a minimal basic core and
bunldes for additional optional components that can be used in
different combinations. The granularity of these bundles should be
determined by what possible combinations make sense for people using
the binary distro.
Simon
I do also agree with this despite what i just posted about how if we use the
launcher approach then the actual module jars don't matter to users :)
One group of "users" we want for Tuscany are those embedding Tuscany in
other products, so having some aggregated jars that group modules by
functionality would make it easier for them - eg an aggregated jar that
contains the minimal Tuscany core runtime modules, another jar with all the
web services related modules etc. Its really hard for an outsider (or even
insider for that mater) working out what modules are needed for what, look
at the tuscany-geronimo integration code which has never managed to keep up
with Tuscany changes.
I think we could do both, if we go for a new launcher approach and OSGi'ify
everything then it might even make it easier to get the aggregated jars
working well and its not so much overhead for us to maintain both sets of
jars and use which ever are appropriate depending on the circumstances. The
key thing will be to get _consensus_ on it so we're all working together
instead of what we have now which seems to be we each focus on the bits
we're interested in sometimes to the detriment of what other are trying to
do.
Actually this isn't quite what I was saying. (Sorry that I wasn't clear.)
I'm talking about the lowest level components that we distribute as
binaries, not about larger groupings that are created from these components
to provide convenient aggregations of functionality. These groupings
might be useful as well, as you are suggesting here and Graham suggested
in his recent post.
So back to the basic components. I see no value at this level in breaking
things down any lower than a unit of functionality that might be included
or excluded as a whole from some valid scenario. To give an example,
I wouldn't put "everything related to Web services" in a single basic
component, because some users might want to create a minimal Web services
configuration without Web services security and/or Web services policy.
I also wouldn't put assembly and core in the same basic component,
because some users might just want the Tuscany model without the
Tuscany runtime. But I would put interface and assembly together in the
same basic component, because there are no cases where one would be used
without the other, and I would put core, core-databinding and databinding
together in the same basic component for the same reason.
Simon
...ant
