tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luciano Resende" <luckbr1...@gmail.com>
Subject Re: Contribution services and SCDL4J
Date Fri, 06 Apr 2007 07:26:51 GMT
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 ?


On 4/4/07, Jean-Sebastien Delfino <jsdelfino@apache.org> wrote:
>
> Jean-Sebastien Delfino wrote:
> > [snip]
> > Luciano Resende wrote:
> >> Hi Sebastien
> >>
> >>   Your understanding is very right, with the new artifactProcessor
> >> interfaces, we should be able to separate the load phases in multiple
> >> phases
> >> as you described.
> >>
> >>   As for your specific questions, let me try to clarify :
> >>
> >>> - The assembly module deals with 3 types of files, .componentType,
> >> .constrainingType, .composite.
> >>> Does that mean I have to implement 3 ArtifactProcessors?
> >>
> >> Not necessarily, you can associate multiple file types with same
> >> processor,
> >> as an example, I had previously associated .scdl and .composite all
> >> with the
> >> SCDLProcessor. It all depends on the algorithms used to process these
> >> files,
> >> if they are the same or very simmilar, you might consider building one
> >> artifact processor, otherwise, you should create multiple processors
> >>
> >>> If the answer is yes, how do I associate a particular
> ArtifactProcessor
> >> with a file type?
> >>
> >> Basically, the PackageProcessors will scan a file system or jar archive
> >> contribution, and for each artifact, it will use the contentType
> >> describer
> >> to identify what type of file it is, and call the artifactProcessor
> >> registered for the artifact type. At the moment, an artifactProcessor
> >> can
> >> only register for one type, but you make the contentType describer
> >> recognize
> >> multiple files extensions as one unique type as the example I described
> >> above (.scdl and .composite).
> >>
> >> Talking about this, one thing that I wasn't planning to do for now, is
> >> plugability to extend the contentType describer, so new types could be
> >> recognized... but I'm starting to think we might need this ? Thoughts ?
> >>
> >> BTW, I should have the artifactResolver registry and other things
> >> necessary
> >> to exercise the processors you are implementing by EOD today (sometime
> >> tonight) ...
> >>
> >
> > I think that we need to make this extensible, to support different
> > content types without having to go change the code in a central
> > ContentDescriber. I'm also not sure about how an artifact processor
> > can be associated with a content type.
> >
> > So, instead of each extension having to:
> > - write a ContentDescriber that returns a ContentType for say
> > .composite files
> > - register the ContentDescriber in some registry
> > - having to know about an ArtifactProcessorRegistry in my
> > ArtifactProcessor implementation
> > - register myself in that registry with that content type for
> > .composite...
> >
> > Could we start simple and I would just implement a String
> > getContentType() method (to be added to ArtifactProcessor), return
> > ".composite" from that method, and that would be your indication that
> > you need to invoke me on .composite files?
> >
>
> More progress on this: I have committed a first cut of the changes to
> port the assembly, idl-java, idl-wsdl and impl-java modules to the
> ArtifactProcessor contribution SPI. The test cases that exercize the
> artifact processors manually all seem to work.
>
> Next step: I'm going to move some of the resolution code and the logic
> to establish wires and normalize policies and component configuration to
> the ArtifactProcessors as well.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
Luciano Resende
http://people.apache.org/~lresende

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