Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
- Started to create sample tasks showing how to bootstrap a subset
of Tuscany to work with the various models [1], see
ListDeployables.java, ListDependencies.java, ListComponents.java,
and WireComponents.java.
...
The init() methods in the sample programs are there to help explore
the various Tuscany bootstrap patterns required for these common
tasks, candidate to become generic utility methods if people want that.
Looking at these init methods, a lot of the setup code is about setting
up XML and document artifact processors, which we shouldn't have to
write if all the necessary processors were correctly registered under
META-INF/services.
I noticed that some of the base processors (CompositeProcessor,
ComponentTypeProcessor, ConstrainingType etc) are missing from
META-INF/services so I'm going to try to fix that and register them
dynamically like all the other ones.
That should help simplify that setup code.
I've done a first pass through all the artifact processors and declared
them under META-INF/services. I had to make minor changes or add the
expected constructors to some of them to follow the pattern that was
already in place to support lazy / automatic loading and initialization.
The following methods:
StAXArtifactProcessorExtensionPoint.getProcessor(modelClass)
StAXArtifactProcessorExtensionPoint.getProcessor(qname)
URLArtifactProcessorExtensionPoint.getProcess(modelClass)
URLArtifactProcessorExtensionPoint.getProcess(artifactType)
should now work for all artifact processors, hoping that I didn't miss any.
With these changes I was able to simplify the bootstrapping code, as it
doesn't need to create all these artifact processors manually anymore.
It was a little tedious but I also went through most artifact processor
unit test cases and was able to simplify their setup method as well.
I'll try to go through the remaining test cases and samples in the next
day or two.
--
Jean-Sebastien
