Hi Chad, I didn't want to criticize the existing docs, they have indeed become quite good!
> >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...) > . That would be good...are you volunteering to help write them? :) Sure, as soon as I change a schema, I'll post the migration script :-P Keep up the good work and maintain your awesome velocity, -- Pieter. On 8/24/05, Chad Brandon <[EMAIL PROTECTED]> wrote: > Pieter Van Gorp wrote: > > >OK, using a namespace makes the learning curve higher but I understand > >the advantages. > > > >We should have good documentation for all involved XML files... > > > > > Yes, we actually do have documents describing each of our docs (I'm sure > they could be improved though),. for example: > http://team.andromda.org/docs/namespace.html. We were planning on > generating documentation on each XML file from the XSD and its > documentation but it hasn't happened yet. > > >Secondly, we've noticed that the schema's of AndroMDA's XML files have > >changed a couple of times over te past months. > > > Yeah we've tried to avoid that, but it hard > > >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...) > > > > > . That would be good...are you volunteering to help write them? :) > > >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
