Pieter Van Gorp wrote:
On 8/24/05, Chad Brandon <[EMAIL PROTECTED]> wrote:
I don't think using Maven goals to handle it
is appropriate...that means AndroMDA becomes dependant on Maven...it
should be in the cartridge descriptor....AndroMDA should be embeddedable
in any java tool.
I agree, let's use the cartridge descriptor.
I do like your suggestion a lot better than the
interface approach, that means any java class could be a transformer.
True, any *new* Java class would also be usable in Matthias' interface
approach but an adapter would be needed for existing transformation
classes (or new classes generated by closed-source transformation
generators). Does anybody see whether we're overlooking advantages of
the interface approach (or disadvantages of the plain Java approach)?
One thing we should do however is register the transformer and its
corresponding transformation method in a "namespace"...with a
namespace.xml (we do that with repositories and other other components
within AndroMDA). The reason being is that we can then reference the
component (in this case a transformation) by name as opposed to class
name, this insulates us from the fact that the class or package name
(or even the method that performs the transformation) may change later
on (which would be a huge pain if it was embedded everywhere in each
cartridge, etc). One disadvantage of not enforcing the interface is
that transformation implementations won't know if the contract has
changed until it stops working at runtime.
Kind regards,
Pieter.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
