Hi Kr�n,
Sorry - I'm not aware of a way around the inheritance restrictions you outline,
although my XML/XSD knowledge is far from extensive; I've really just learned as much
as I've needed to get the job done on various occasions.
FWIW my vote is definitely in favour of your proposed breaking change though. I'd be
fully prepared to tweak my build files (and it's only a simple cut & paste reordering
in most cases) if that would enable the tasks to be more maintainable and extensible
in future. Maybe you can have an error handler on the validation that prints a helpful
error message for those users who aren't on the list and whose builds may break.
Cheers,
Simon
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 12 November 2003 11:01
To: [EMAIL PROTECTED]
Subject: [NAntC-Dev] MSITask/MSMTask refactoring, part I
Hi,
I've started work on the refactoring of MSITask/MSMTask. I've started by splicing the
Xsd files, so that the two types 'msi' and 'msm' inherit from a common type 'MSIBase'
that contains most of the data. So from two files totalling about 1560 lines, I've
gone to one file containing 900 lines. This has the added benefit that the generated
.Net msi and msm classes both inherit from an MSIBase class. This will make
refactoring MSITask.cs and MSMTask.cs much easier.
But... This comes with a price: a breaking change that will force users to reorder the
subelements of their msm/msi tasks. This is because to use inheritance in XSD, common
elements must be placed before the subclass-specific elements (and you can only extend
a XSD <sequence> - not an <all>). For the <msi> task, you will have to move the
<launchconditions>, <features> and <mergemodules> subelements to the bottom of the
task, and for the <msm> task, you will have to move the <module*> elements.
So my question is: do any of you know of a way to get around this (I'm not that
proficient with XSD and serialization)? Failing that, do you think I should proceed?
That is, do you think (as I do) that the benefits of ease of maintenance outweighs the
penalty of a breaking change at this stage?
/Kr�n
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
NAntContrib-Developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
NAntContrib-Developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer
