Pieter Van Gorp wrote:
Hi Chad, I didn't want to criticize the existing docs, they have
indeed become quite good!
Yeah they have come a long way.....primarily due to Wouter. :)
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
Sounds like a plan...but yes I agree, it would be a good policy to have.
Keep up the good work and maintain your awesome velocity,
Thanks..I'll try :)
-- 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
