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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Luciano Resende http://people.apache.org/~lresende
