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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
