OK, using a namespace makes the learning curve higher but I understand the advantages.
We should have good documentation for all involved XML files... Secondly, we've noticed that the schema's of AndroMDA's XML files have changed a couple of times over te past months. We would welcome a policy stating that every schema change should be accompanied by an XML transformation script that automates the migration (we could vote for that in another mail thread...) Thanks for the input, Pieter. On 8/24/05, Chad Brandon <[EMAIL PROTECTED]> wrote: > 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
