Rajini Sivaram wrote:
On 2/22/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
Great to see a *test* case for cycles, but my question was: Do you
have a *use* case for cycles and partial packages right now or can
it >> be fixed later?
Rajini Sivaram wrote:
No, I dont have an use-case, at least not an SCA one. But there are
plenty
of them in OSGi - eg. Tuscany modules cannot run in OSGi without support
for
split-packages. Of course you can fix it later.
I'm not arguing for or against fixing it now or later, I'm trying to get
the real use case to make a decision based on concrete grounds. Can you
point me to your OSGi use cases, or help me understand "Tuscany modules
cannot run in OSGi without support for split packages"?
Tuscany node and domain code are split into three modules each for API, SPI
and Implementation eg. tuscany-node-api, tuscany-node and tuscany-node-impl.
The API module defines a set of classes in org.apache.tuscany.sca.node and
the SPI module extends this package with more classes. So the package
org.apache.tuscany.sca.node is split across tuscany-node-api and
tuscany-node. If we used maven-bundle-plugin to generate OSGi manifest
entries for Tuscany modules, we would get three OSGi bundles corresponding
to the node modules. And the API and SPI bundles have to specify that they
use split-packages. It would obviously have been better if API and SPI used
different packages, but the point I am trying to make is that splitting
packages across modules is not as crazy as it sounds, and split packages do
appear in code written by experienced programmers.
IMO, supporting overlapping package import/exports is more important with
SCA contributions than with OSGi bundles since SCA contributions can specify
wildcards in import.java/export.java. eg. If you look at packaging
tuscany-contribution and tuscany-contribution-impl where
tuscany-contribution-impl depends on tuscany-contribution, there is no clear
naming convention to separate the two modules using a single import/export
statement pair. So if I could use wildcards, the simplest option that would
avoid separate import/export statements for each subpackage (as required in
OSGi) would be to export org.apache.tuscany.sca.contribution* from
tuscany-contribution and import org.apache.tuscany.sca.contribution* in
tuscany-contribution-impl. The sub-packages themselves are not shared but
the import/export namespaces are. We need to avoid cycles in these cases.
Again, there is a way to avoid sharing package spaces, but it is simpler to
share, and there is nothing in the SCA spec which stops you sharing packages
across contributions.
I dont think the current model resolver code which recursively searches
exporting contributions for artifacts is correct anyway - even for artifacts
other than classes. IMO, when an exporting contribution is searched for an
artifact, it should only search the exporting contribution itself, not its
imports. And that would avoid cycles in classloading. I would still prefer
not to intertwine classloading and model resolution because that would
unnecessarily make classloading stack traces which are complex anyway, even
more complex that it needs to be. But at least if it works all the time,
rather than run into stack overflows, I might not have to look at those
stack traces....
and this will convince me to help fix it now :) Thanks.
It is not broken now - you have to break it first and then fix it :-).
I have reviewed the model resolution and classloading code and found the
following:
- Split namespaces are currently supported (for example by the WSDL and
XSD resolvers). The model resolver mechanism does not have an issue with
split namespaces.
- The Java import/export resolvers do not seem to support split packages
(if I understood that code which was quite tricky), but that's an issue
in that Java import/export specific code, which just needs to be fixed.
I'll work on it.
- The interactions between the Java import/export listener, the model
resolvers and the ContributionClassLoader are way too complicated IMHO.
That complexity is mostly caused by ContributionClassLoader, I'll try to
show a simpler implementation in a few days.
- Dependency cycles are an exception in Java as build tools like Maven
don't support them, but can exist in XSD for example. Supporting cycles
just requires a simple fix to the import model resolvers, I'll help fix
that too.
Hope this helps.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
