tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Venkata Krishnan" <for.svkr...@gmail.com>
Subject Re: Contribution services and SCDL4J
Date Sun, 08 Apr 2007 13:01:12 GMT
Hi,

I am catching up with all the work that is going on in 'modules' and am
trying my best join the party.  Here are some questions that have come up my
mond... please help me with answers.

 - I see that the 'resolve' method in ArtifactProcessor has an argument
'resolver'.   Where is this resolver going to be passed from ?  I see in the
testcases that this resolver is created and then passed, but don't quite get
the bigger picture as to how a chain of resolvers would be instantiated and
passed around.  For example when the CompositeProcessor's resolve method  is
called what is the resolver that would be used.
- To start putting my hands as well into this, I was looking for a humble
start with respect to property loading.  For example if I were to verify
where a component property defined is actually existing in the underlying
componentType where and when would I do this.  I suppose it would be in the
'resolve' phase  right ?  If so which processor should do this?  I was
looking at the CompositeProcessor.resolve for a place to do this but then
ended up with the question in the first bullet.  (hope this is not already
done and I have missed it)
- The 'Reference' interface in assembly has accessor methods for
'autowire'.  I wonder if this should move up to ComponentReference as I did
not see the relvence of 'autowire' in componentType references and composite
references.  Am I missing a point ?

Thanks

- Venkat

On 4/6/07, Jean-Sebastien Delfino <jsdelfino@apache.org> wrote:
>
> Luciano Resende wrote:
> > I have also made some progress on this: I have simplified the
> > packageProcessors interfaces, making it responsible only for providing a
> > list of artifacts that need to be processed, and processing now
> > should/will
> > be driven by the contributionServiceImpl.
> >
> > I have also started to integrate the artifactProcessors and it's
> > phases into
> > the contributionServiceImpl, but had a question about whether or not the
> > contribution-impl should have dependencies on assembly-impl-xml in
> > order to
> > be able to perform some unit tests using the artifactProcessors defined
> > there. Thoughts ?
> >
> >
>
> It may be simpler to write a test ArtifactProcessor in
> contribution-impl. This way, if I break assembly-xml for example, I
> won't break your contribution-impl unit test.
>
> More generally, the contribution framework provides a base platform for
> various extensions/plug-ins, assembly, policy, implementation-java etc.
> So, it would look odd to have the contribution framework implementation
> depend on one of the extensions, even for testing purposes.
>
> If you have your own test ArtifactProcessor in contribution-impl, we
> also need to test the integration of assembly-xml and contribution-impl,
> but this can be tested in assembly-xml itself..
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message