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] Idea: Inline task definitions (task orchestration/macros).
I still haven't got any firm ideas on now to handle Nant data types like filesets etc. I'd really like to be able to use them. - Mitch Denny - [EMAIL PROTECTED] - http://www.monash.net - +61 (414) 610141 - -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Monday, 19 January 2004 11:59 PM To: Mitch Denny Cc: [EMAIL PROTECTED] Subject: Re: [nant-dev] Idea: Inline task definitions (task orchestration/macros). Sorry for coming late tgo the discussion, but the original request sounds a lot like Ant's new macrodef[1] task. Stefan Footnotes: [1] http://ant.apache.org/manual/CoreTasks/macrodef.html -- http://stefanbodewig.blogger.de/ --- 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] style task
Gert Driesen wrote:
Giuseppe can always first download the stylesheet to his local filesystem
using the get task. This has the advantage that he's able to set both
proxy and authentication information for fetching the file and it would also
increase performance for subsequent transformations.
sure - and he could also use the system.net classes to grab it before
calling XsltTransform in C# code but the transform class supports using
remote uri's as a convenience to the user. I think its a valid and
relatively common use case.
However, it should be perfectly possible to also support the System.Uri
class as a special property type in NAnt and also construct a URI referring
to a full path relative to the project base dir if the value of the
attribute is not a value URI.
sure thats a good idea but it doesn't help for the style task because
you really want to allow the style attribute to be either a local file
or a remote url
In case of the style task it would add more complexity to use a URI for
the stylesheet as you'll also need to check whether the stylesheet was
updated or exists.
thats true - another reason to keep it as a string and pass it straight
to the xsltransform object which does all that checking anyway and
reports decent errors if the file isn't found. ( local or remote )
Let me know if you'd want me to add support for properties backed by a Uri
type (regardless of whether you'll use it for the style task)...
looks like you've done it anyway - good work.
however I think it makes more sense for the style task to use strings
rather than file/Uri info objects and let the transform do the validation.
Ian
Gert
From: Ian MacLean [EMAIL PROTECTED]
To: Giuseppe Greco [EMAIL PROTECTED]
Cc: NAnt Developers [EMAIL PROTECTED]
Sent: Saturday, January 17, 2004 1:05 AM
Subject: Re: [nant-dev] style task
Right now it doesn't support remote stylesheets and in fact with recent
changes ( current cvs ) it will give the following error instead:
'http://www.agamura.com/quxo/stylesheets/current/html/chunk.xsl' is not
a valid
value for attribute 'style' of style ... /.
The given path's format is not supported.
I've made the changes to allow remote urls for the stylesheet and input
file in my local cvs tree. This undoes much of the FileInfo based
validation that Gert recently added however thats not a major issue
since the xslt processor will output a meaningful error for invalid
local paths. I think its worth making the change but I'd like to hear
what Gert thinks first. If you have an urgent need for this I can send
you the patch while the decision is made.
Ian
Giuseppe Greco wrote:
Hi all,
Is there a way to get the style task working with a stylesheets
located on the web?
For instance, the following task does not work...
style
style=http://www.agamura.com/quxo/stylesheets/current/html/chunk.xsl;
basedir=.
destdir=${build.dir}
in=${nant.project.name}.xml/
... and here below is the result:
BUILD FAILED
/home/genius/projects/csharp-coding-guidelines/src/default.build(102,5):
Stylesheet file
'/home/genius/projects/csharp-coding-guidelines/src/http:/www.agamura.com/q
uxo/stylesheets/current/html/chunk.xsl' does not exist.
NAnt prefixes the URL of the stylesheet with base.dir.
j3d.
---
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
---
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
---
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] Nightly task docs broken
Looks like the nightly task docs broke at some point- http://nant.sourceforge.net/nightly/help/ You don't have permission to access /nightly/help/index.html on this server. Permissions issue with SCP? Matt. --- 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] style task
- Original Message - From: Ian MacLean [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: Giuseppe Greco [EMAIL PROTECTED]; NAnt Developers [EMAIL PROTECTED] Sent: Monday, January 19, 2004 11:02 PM Subject: Re: [nant-dev] style task Gert Driesen wrote: Giuseppe can always first download the stylesheet to his local filesystem using the get task. This has the advantage that he's able to set both proxy and authentication information for fetching the file and it would also increase performance for subsequent transformations. sure - and he could also use the system.net classes to grab it before calling XsltTransform in C# code but the transform class supports using remote uri's as a convenience to the user. I think its a valid and relatively common use case. I agree that we should support remote uri's as well, but I was just pointing him to the get task as it also allows credentials and proxy information to be set ... However, it should be perfectly possible to also support the System.Uri class as a special property type in NAnt and also construct a URI referring to a full path relative to the project base dir if the value of the attribute is not a value URI. sure thats a good idea but it doesn't help for the style task because you really want to allow the style attribute to be either a local file or a remote url That's exactly what I was trying to say : we could have uri backup attribute that allow both remote and local uri's, if the value specified by the user is not a valid uri, we can always consider it be a file path, convert it a full path (relative to project base dir) and construct a uri from it ... In case of the style task it would add more complexity to use a URI for the stylesheet as you'll also need to check whether the stylesheet was updated or exists. thats true - another reason to keep it as a string and pass it straight to the xsltransform object which does all that checking anyway and reports decent errors if the file isn't found. ( local or remote ) Not sure I agree about this, the more errors we can catch ourselves the better ... And we still need to have a way to determine the last modification date of the file pointed to by the remove uri ... Let me know if you'd want me to add support for properties backed by a Uri type (regardless of whether you'll use it for the style task)... looks like you've done it anyway - good work. No, right now I did it the other way around : I now support uri's for FileInfo backup attributes ... 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
