I have completed the remaining work for (contribution-resource). You
can now define a element in your
sca-contribution.xml and then it will be used by contribution service
when resolving resources/artifacts.
Exporting resources using sca-contribution.xml :
http://www.osoa.org/xmlns/sca/1.0";
t; >>>
> >>> I think we should start by raising a jira, and discussing what's the
> >>> best solution here, should we just reuse some already existent
> >>> import/export to configure the componentType model resolver ? You
>
ort/export ?
I'll keep thinking and do some investigation on this area...
Thoughts ?
On 10/25/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote:
Hello,
Is there any reason why unlike CompositeModelResolver and
ConstrainingTypeModelResolver, ComponentTypeModelResolver does not look
I have committed the new import/export resource module
(contribution-resource) under revision #629235. This still need to be
integrated to the runtime and proper iTests need to be created. These
all should be ready in the next day or so.
On Feb 18, 2008 6:35 PM, Jean-Sebastien Delfino <[EMAIL PROT
Luciano Resende wrote:
Do you want to restrict this to file ? Some bindings, like
binding.http can point to a specific folder, that's why I thought
would be more appropriate name for this new import ?
You're right we need to support folders too, import.resource is better.
--
Jean-Sebastien
-
.
Enhancements available in componentType modelResolver under revision #628592.
> Imported contributions not used in resolving component type files
> --
>
> Key: TUSCANY-1873
> URL: https://is
ing component type files
> --
>
> Key: TUSCANY-1873
> URL: https://issues.apache.org/jira/browse/TUSCANY-1873
> Project: Tuscany
> Issue Type: Bug
> Component
On Feb 15, 2008 3:31 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Luciano Resende wrote:
> > I guess we have couple scenarios here :
> >
> > - Considering contribution A importing a java package from
> > Contribution B, we can have the componentType in either Contribution
> > A(supported
Luciano Resende wrote:
I guess we have couple scenarios here :
- Considering contribution A importing a java package from
Contribution B, we can have the componentType in either Contribution
A(supported today) or contribution B (not working: TUSCANY-1873).
- We can also consider Contribution A
?
> >
> > I'll keep thinking and do some investigation on this area...
> >
> > Thoughts ?
> >
> > On 10/25/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > Is there any reason why unlike CompositeMod
t/export ?
>
> I'll keep thinking and do some investigation on this area...
>
> Thoughts ?
>
> On 10/25/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > Is there any reason why unlike CompositeModelResolver and
> > ConstrainingType
Imported contributions not used in resolving component type files
--
Key: TUSCANY-1873
URL: https://issues.apache.org/jira/browse/TUSCANY-1873
Project: Tuscany
Issue Type: Bug
omponentTypeModelResolver does not look at
> imported namespaces for resolving component type files?
>
> My test case contains:
>ContributionA : contains a composite file, with a component C1
>ContributionB: contains the Java implementation classes for C1 (
> x.y.C1.class), and
Hello,
Is there any reason why unlike CompositeModelResolver and
ConstrainingTypeModelResolver, ComponentTypeModelResolver does not look at
imported namespaces for resolving component type files?
My test case contains:
ContributionA : contains a composite file, with a component C1
14 matches
Mail list logo
