Luciano Resende wrote:
Trying to go further with the support of import/export, looks like at
some cases we need specialized resolvers that understand better the
specifics of the artifact type being resolved, I started looking into
this piece and will start adding some support for plugable resolvers
in the contribution service and then integrate then with the current
support for import/export.
Thoughts ?
On 7/13/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
I have just committed initial support for import/export, the
integration tests exercise and demonstrates the usage of multiple
contributions using import/export scenarios, there is also a strawman
documentation available on the wiki [1].
This is working in progress, and I will look a little more into it to
optimize the algorithm being used on the resolution mechanism of the
imports.
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Contribution+-+Import+and+Export
On 7/11/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> I have started looking into contribution import/export as defined in
> the SCA 1.0 Assembly spec. I've started putting together some test
> cases around the following scenarios :
>
> - Two contributions, where C1 defines and exports CompositeA and C2
> imports and reference it trough a <implementation.composite>
> - Two contributions, where C1 defines a WSDL contract and export
> it's namespace, and C2 imports and reference it through a ws-binding.
> - Two contributions, where C1 defines some interfaces and export
> it's package, and C2 imports and reference these interfaces
>
> I'll start checking in the test-cases, and then working on adding
> support for contribution service to handle these cases.
>
> Please comment on these scenarios, and feel free to add to it, and off
> course, help is always welcome.
>
The pluggable model resolvers look good to me. On top of this I think we
need to support several types of imports/exports:
- Namespace based <import>/<export>
- Java package name based <import.java>/<export.java>
- other <import>/<export> types for other definition types
So we're going to need an extensibility mechanism similar to what we
already have for bindings and implementation types. In fact it's so
similar that I'd suggest to use the same extension point mechanism with
StAXArtifactProcessors for the different types of imports/exports.
As a first step to enable this, I have created new base Import/Export
interfaces suitable all import/export types and
NamespaceImport/NamespaceExport interfaces to represent the namespace
based imports/exports. When we add JavaImport/JavaExport they'll be able
to extend Import/Export as well. I left the existing
ContributionImport/ContributionExport interfaces in place but deprecated
(they just extend the new NamespaceImport/NamespaceExport) to avoid
breaking any code that uses them.
I adjusted the contribution implementation module to reflect these changes.
These changes are available in revision r558558.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
