> I still think we should use xml merging (of both child nodes and attributes, > not only child nodes) for all types and not deal with filsets differently > ...
It will be nice, but how to do e.g. ? <fileset id="1" basedir="..\test2"> <includes name="1"/> <includes name="2"/> </fileset> <fileset id="1" basedir="..\test1" redefinemode="Append"> <includes name="1"/> <includes name="2"/> </fileset> > I also don't think we should actually initialize the global types when we > initialize the project, I think we should only merge the xml of the type > instance with the global type when the type is actually used ... Doable. I'll prepare patch for it. > Gert > > ----- Original Message ----- > From: "Martin Aliger" <[EMAIL PROTECTED]> > To: "Ian MacLean" <[EMAIL PROTECTED]>; "Gert Driesen" > <[EMAIL PROTECTED]> > Cc: "! nant" <[EMAIL PROTECTED]> > Sent: Monday, January 19, 2004 3:16 PM > Subject: Re: [nant-dev] types merging > > > > Here it is. I also react to Gert's notes inline... > > > > Also is attached mine test build script. > > > > Martin > > > > ----- Original Message ----- > > From: "Ian MacLean" <[EMAIL PROTECTED]> > > > > > >What do you think? Should I prepare patch for it? > > > sure. I'd like to see it. > > > > > > Ian > > > > ----- Original Message ----- > > From: "Gert Driesen" <[EMAIL PROTECTED]> > > > > > I definitely think we ought to consider using xml merging here, as the > way > > > Martin implemented it will definitely cause problems, eg. when you > change > > > the base directory in the redefined fileset, you can't just add the > files > > of > > > redefined fileset to the original fileset definition ... > > > > Change base directory in fileset does problems. But more in xml merge than > > custom fileset merging... > > > > > when we can use raw xml merging, we could allow allow partial definition > > of > > > types, meaning that the original definition does not have to pass all > > > initialization rules as its only when actually referencing the type > > > definition (after possibly merging it with additional xml) that an > > instance > > > of the type will have to be created > > > > Done this way now :-) Or atleast very simmilarly... > > > > > should we also use the class naming guidelines for the enum field (eg. > > > RedefineMode.Replace instead of RedefineMode.replace instead), in order > to > > > have it match our other enums (we could perhaps consider resolving them > in > > a > > > case insensitive way)? > > > > Please, do it! It is not very nice to write redefinemode="Append" when > whole > > script is in lowercase... > > > > > perhaps we should also rename the mode attribute to redefinemode, as > that > > > name is more meaningful and there's less chance of it conflicting with > an > > > existing attribute ... > > > > True and done. > > > > > Gert > > > > ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
