Agreed, the breaking change would be better for the future of the tool.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Simon Protheroe
Sent: Wednesday, November 12, 2003 7:01 AM
To: [EMAIL PROTECTED]
Subject: RE: [NAntC-Dev] MSITask/MSMTask refactoring, part I
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
-------------------------------------------------------
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
