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
--------------------------------------------------
From: "Simon Nash" <[EMAIL PROTECTED]>
Sent: Wednesday, June 11, 2008 12:33 PM
To: <tuscany-dev@ws.apache.org>
Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Comments inline.
Simon
Rajini Sivaram wrote:
On 6/10/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
ant elder wrote:
On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:
Simon Nash wrote:
ant elder wrote:
On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
I'd like to discuss the following: "What distro Zips are we
building
and
what do they contain?"
I think we could improve our distro scheme to provide:
- smaller packages
- easier for people to find what they need
I was thinking about the following binary distro zips:
- tuscany-core.zip - The base that everybody needs.
core assembly model and runtime
Java APIs, Java components
- tuscany-web.zip - For WS and Web developers
WS binding, Web 2.0 bindings, Scripting components, Widget
components
- tuscany-jee.zip - For JEE app integration
EJB, RMI and JMS bindings, Spring components
- tuscany-process.zip - For process development
BPEL and XQuery components
- tuscany-all.zip - all of the above
Note that I'm not trying to tackle release cycles and the
potential
for
releasing the above zips independently in this discussion and I'm
assuming
that we release all of the above together.
I'm also assuming that the relevant samples are included in each
zip.
This email was from 1/22/08, generated a lot of discussion for
about
3
weeks, lots of opinions, no conclusion, no commits :)
No commits as we haven't found much consensus yet.
I still think the same as what I had posted then, plus additional
ideas:
- Use OSGi exports/imports to export clean SPIs, hide internals,
and
refine
the contents of the distros and their dependencies.
Disclaimer - Please don't get me wrong I'm not saying that one
distro
==
one
OSGi bundle, as I've already said several times on the list that the
big-OSGi-bundle approach didn't make sense to me :) I just think
that
declaring and enforcing clean dependencies using OSGi will help us
refine
the contents of each distro.
The term "enforcing" seems to suggest that there might be an OSGi
dependency for the Tuscany runtime. I don't know if this was
intended. I think the right approach is to have a Tuscany+OSGi
runtime (as we are building in itest\osgi-tuscany) which would
actually do enforcement, and a non-OSGi Tuscany runtime in which
the exports/imports are present in the jars but not enforced.
Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
environment...
What would be the granularity of these OSGi bundles? If the bundles
are the current maven modules, I think we will find a number of
classes that need to be exported even though these classes are not
considered part of the SPI or API that the module provides.
To resolve this I see the following options:
a) Export more than we really believe is correct. This
leaves us in the current unsatisfactory position of exposing
unwanted implementation internals.
b) Combine multiple maven modules with a close implementation
affinity into a single OSGi bundle, and only expose true
APIs or SPIs from these bundles.
c) Refactor the code to remove dependencies on internals of other
modules, and create new SPIs or APIs when this isn't possible.
I believe a combination of b) and c) is the best approach.
We've already rehashed this (and disagreed on this) in several other
threads, where I've already given my opinion:
- 1 bundle per module
- clean API/SPI imports/exports
By "1 bundle per module" do you mean any sort bundled jar combining
multiple
of our tuscany/java/sca/module jars is not worth pursuing?
...ant
I think that the right design is one bundle per maven module.
From an OSGi point of view I would like to ensure that we will continue
to
have one bundle per 3rd party jar and that these will not be aggregated
regardless of how the distribution is zipped up.
As for one bundle per maven module, I think there are pros and cons for
finely grained and coarsely grained bundles, and it is really just a
matter
of preference. Since we anyway have nearly 150 3rd party bundles/jars
anyway, I personally dont see any problem with one bundle per module.
I have a different view on this. See below.
I don't think that aggregating multiple modules into a single bundle
makes
much sense, or they should be aggregated in a single Maven module in the
first place.
IMHO modularizing Tuscany is about code quality and maintenance -
something
internal benefitting Tuscany developers. So we have 100 "modules" based
on
the developer's view of Tuscany internals. That does not necessarily mean
that end users have to deal with 100 bundles. If 20 core modules are very
tightly coupled together and will only operate with each other, as far as
an
end user is concerned, this could as well be one bundle. Can a Tuscany
user
combine assembly-xml version 1.3.0 with assembly version 1.3.1? Or even
implementation-java with implementation-java-runtime of a different
version?
The answer is probably "no". But that does not necessarily mean that
these
should be combined into a single maven module. In some cases the
splitting
of modules does have a point beyond versioning - eg. separating models
and
runtimes like you have been doing. Now that is good reason to define
different bundles for these two - enabling bundles to be used
independently
of each other. But I dont believe that we have 100 different entities in
Tuscany that can be separately versioned or used independently.
I agree and I think this is the key factor that needs to be considered.
In some cases existing Tuscany maven modules would make excellent OSGi
bundles, for example binding-ws-axis2, host-tomcat, implementation-osgi
and interface-wsdl.
But what about the 10 contribution-xxx maven modules? Can they be
separately versioned or used independently? Can databinding be used
independently from core-databinding, or vice versa? Can core do
anything useful without core-databinding? Can anyone use interface
without assembly? When maven modules don't pass the test of being
separately versionable or usable independently, they either need to be
aggregated into a single bundle or merged into a single maven module.
If we look at the total Tuscany distribution including Tuscany modules
and
3rd party libraries, aggregating Tuscany modules doesn't add much value
unless 3rd party libs that go with these modules are also combined
together
with the Tuscany modules in a "bundle". And that to me is completely
impractical. If we are anyway going to require a "launcher" of some form,
wouldn't it be just as easy to maintain one-bundle-per-module?
I don't think this follows at all. The Tuscany bundles should reflect
the independently usable and/or versionable elements of Tuscany, and
the current maven module split doesn't achieve this. It isn't necessary
or even desirable IMO to combine Tuscany bundles with their third-party
dependencies in order to achieve the benefits of a better structure for
Tuscany itself.
Simon
--
Jean-Sebastien
