Re: [nant-dev] types merging
Sorry for my previous example. The resulting fileset should be empty because files cannot be both "xxx.*" and "AAA.*". Jarek > the resulting fileset is (in terms of the set algebra, + means union, - > means difference) > > L1 + L2 - (L3 - L4) > > so (because we're excluding almost every file but AAA.*) this means the same > as: > > > > --- 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
Re: [nant-dev] types merging
> I think this is sufficient in 99.9% scenarios so if we don't find merge be > useful we could always implement this [I have it in some state already] > Should such implementation include even excludes from referenced fileset? I suggest the following evaluation semantics: Means: 1. find all files matching "xxx.*" and convert them to the set of filenames (L1) 2. find all files matching "yyy.*" and convert them to the set of filenames (L2) 3. find all files matching "*.*" and convert them to the set of filenames (L3) 4. find all files matching "AAA.*" and convert them to the set of filenames (L4) the resulting fileset is (in terms of the set algebra, + means union, - means difference) L1 + L2 - (L3 - L4) so (because we're excluding almost every file but AAA.*) this means the same as: I propose a rule, which I think is quite intuitive: Every time you or a fileset, resolve it to a set of files and proceed with include/exclude as if it was specified as a series of or Awaiting comments. Jarek --- 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
Re: [nant-dev] types merging
> I think this is sufficient in 99.9% scenarios so if we don't find merge be > useful we could always implement this [I have it in some state already] > Should such implementation include even excludes from referenced fileset? I suggest the following evaluation semantics: Means: 1. find all files matching "xxx.*" and convert them to the set of filenames (L1) 2. find all files matching "yyy.*" and convert them to the set of filenames (L2) 3. find all files matching "*.*" and convert them to the set of filenames (L3) 4. find all files matching "AAA.*" and convert them to the set of filenames (L4) the resulting fileset is (in terms of the set algebra, + means union, - means difference) L1 + L2 - (L3 - L4) so (because we're excluding almost every file but AAA.*) this means the same as: I propose a rule, which I think is quite intuitive: Every time you or a fileset, resolve it to a set of files and proceed with include/exclude as if it was specified as a series of or Awaiting comments. Jarek --- 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
Re: [nant-dev] types merging
> Not in current implementation. I dont like it much - using both id and refid > is little opaque... > > Better to introduce what you suggest in previous mail: > > > > To be more readable, I would: 1. Make fail on attempts to define fileset when fileset with the specified "id" already exists. 2. Add overwrite="true" or redefine="true" to suppress this behaviour. Being more verbose here is a good thing. What do you think ? Jarek --- 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
Re: [nant-dev] types merging
> BTW. Can you have this? (both reference a named fileset and re-define it ?) > > > > > > Jarek Not in current implementation. I dont like it much - using both id and refid is little opaque... Better to introduce what you suggest in previous mail: This does merge simmilary to redefinemode so it is sufficient to merge two filesets. I think this is sufficient in 99.9% scenarios so if we don't find merge be useful we could always implement this [I have it in some state already] Should such implementation include even excludes from referenced fileset? Martin --- 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
Re: [nant-dev] types merging
BTW. Can you have this? (both reference a named fileset and re-define it ?) Jarek --- 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
Re: [nant-dev] types merging
> 3. Maybe we should start by implementing it the simple way: Make "includes" > and "excludes" support filesets (both referenced and nested): > > > > > > > > > > > > > > > > > Nice Jarek. First I tried something very simmilar (named it includesFileset) but then realize need for something like: ... some s ... ... ... then after comments from Gert and Ian I came with more general approach to merge general types (redefinemode). But I share your doubt that xml merging will be enough... btw: type if we introduce it later could be nice to be mergable. But am not sure whether simple xml merge will be sufficient for it either. > 4. This approach has the nice property of being side-effect-free - it can be > used in all places where a is expected. I'm not sure how would > behave in this case. Hmm. True. You could always define new id and reference it but... Good point! I think it is doable. Let me think about it a little deeper. Martin --- 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
Re: [nant-dev] types merging
> Perhaps it would be more efficient to hold off on the patch until more > people have provided feedback, and until we've decided it in more detail. > I'd hate to see your efforts go to waste ... My 0.02 PLN: 1. I don't think merging can be done in a generic way (neither on xml level nor at the object level) 2. I cannot think of a reason to merge: and similar objects and I suggest we focused on filesets only. 3. Maybe we should start by implementing it the simple way: Make "includes" and "excludes" support filesets (both referenced and nested): 4. This approach has the nice property of being side-effect-free - it can be used in all places where a is expected. I'm not sure how would behave in this case. 5. Let's keep it simple and I hope that the idea I've presented for nested s is simple enough. Jarek --- 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
Re: [nant-dev] types merging
- Original Message - From: "Martin Aliger" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]>; "Ian MacLean" <[EMAIL PROTECTED]> Cc: "! nant" <[EMAIL PROTECTED]> Sent: Tuesday, January 20, 2004 10:35 AM Subject: Re: [nant-dev] types merging > > 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. ? > > > > > > > > > > > I agree that this would not work as expected using my proposal, and I'm not sure if and how this should work, let me give it some thought ... > > > 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. Perhaps it would be more efficient to hold off on the patch until more people have provided feedback, and until we've decided it in more detail. I'd hate to see your efforts go to waste ... 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
Re: [nant-dev] types merging
> 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. ? > 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
Re: [nant-dev] types merging
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 ... 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 ... 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
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 test.build Description: Binary data DataTypeBase.cs.patch Description: Binary data FileSet.cs.patch Description: Binary data Project.cs.patch Description: Binary data Target.cs.patch Description: Binary data TaskContainer.cs.patch Description: Binary data PathScanner.cs.patch Description: Binary data
Re: [nant-dev] types merging
What do you think? Should I prepare patch for it? sure. I'd like to see it. Ian Martin --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- 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
[nant-dev] types merging
Hi all, I implement raw XML merge of all types. It can handle correctly [echo] E:\src\extern\nant\test2\1 [echo] E:\src\extern\nant\test2\2 BUT ! basedir setting is lost during merge... You coudn't have one fileset with two basedirs. Only possible approach is to override merging mechanism for filesets and merge it differently. Plain XML merge could be default mechanism though. What do you think? Should I prepare patch for it? Martin --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
