[nant-dev] zip bug with some characters
Hi, I encoutered a bug with the zip task (using NAnt 0.8.4). Some characters (example: ç, é, è) are wrongly encoded in the zip file, which result in invalid filenames, as reported when openning the file with winzip. Nick _ MSN Messenger : discutez en direct avec vos amis ! http://messenger.fr.msn.ca/ --- 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] NAnt cvs task changes
Hi, I am planning on making some changes to the cvs task. We have been working on a command line client for #cvslib that behaves the same as the cvs and cvsnt command line clients. What I am going to do is use this client to interface with the #cvslib component by executing the cvs.exe process. I am also planning on giving the option to use the default cvs.exe client (#cvslib client, distributed with NAnt) or to override and use a native cvs.exe client (either from cvs-home or cvsnt). For the existing tasks the change should be transparent to the end user. There will be an additional task with (**still developing**) the following format: cvs command=cvsroot=destination=module= usesharpcvslib= globaloptions option name=quiet value=true / /globaloptions commandoptions option name=overridedirectory value=other-directory / /commandoptions /cvs Note the globaloptions / and commandoptions / will be available in the cvs-checkout / and cvs-update / tasks as well, and that the commandoptions / will replace the current options / tag (which will still be available...but will be phased out). I am just in the stages of making sure this will work the same, and everything looks good so far. If no one has issues with these changes I will check them in when they are cleaned up a bit more.. Cheers, Clayton --- 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] Property Scoping
Seems like the flow scope should be called local in C#/programming
terms, and local would be private/container-only scoping. Having global be
the default is a good call, but only in come case, as you have identified in
if//foreach//etc.
I'm sure we will be able to say more with a patch; so we can test things
out. If the changes are small enough, and defaults don't change existing
functionality, I'm happy to put them in the head since we are still a little
while from testing/beta'n this version.
I'd be inclined to separate the two patches, one for scoped properties
(which are core changes) and one for the new task def stuff.
- Original Message -
From: Mitch Denny [EMAIL PROTECTED]
Hi folks,
OK, I've got a bit of a prototype working for property scoping which so
far appears to be non-breaking to existing scripts. It works like this:
property name=x value=y accessibility=Global /
Global is actually the default. If I had this:
property name=x value=y accessibility=Local /
It would mean that the property is accessible to all things in the
current scope where a scope is defined by the current target (project
for root level tasks) or TaskContainer. So this would cause an error in
the expression evaluator:
if test=true
property name=x value=y accessibility=Local /
/if
echo message=${x} /
Because x is not accessible outside of the scope defined by the if task
container. This works with my earlier taskdef work too! Interestingly
the following won't work.
if test=true
property name=x value=y accessibility=Local /
if test=true
echo message=${x} /
/if
/if
Because local is local to the current task container. I introduced a
third accessibility level called Flow which allows this to work.
Remember that the default is Global when you are using the property /
task, so it won't break anything. The way it works is that I have lots
of PropertyDictionary objects attached to a hierarchy of Scope objects.
The scope is updated when ever a build/target/task container starts or
finishes.
I also modified quite a bit of the implementation of PropertyDictionary
so that it now stores a Property object as its value although the
external interface is unaffected (cross fingers I didn't break
anything).
Now that I have done this, and if there is enough interest I'd like to
propose that we do something like has been done for expression
evaluation, take a branch and do some exploritory work on this where
this = taskdef / and property scoping.
Can I get a +1 or -1?
---
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] Property Scoping
Hiya Jarek,
Yeah I wasn't sure about the nested if approach either, its easy enough
to change the behavior (I think). By default its Global anyway, and flow
fits the bill. Maybe Local should behave like Flow, and have one called
Private or something. Shrug :)
Come to think of it, there are very few cases where you wouldn't want to
use either Global or Flow instead of Local. Need to think about where we
want Flow properties to fall out of scope and cross breed it with
Local.
- Mitch Denny
- [EMAIL PROTECTED]
- http://www.monash.net
- +61 (414) 610141
-
-Original Message-
From: Jaroslaw Kowalski [mailto:[EMAIL PROTECTED]
Sent: Thursday, 22 January 2004 6:37 AM
To: Mitch Denny; [EMAIL PROTECTED]
Subject: Re: [nant-dev] Property Scoping
Hi Mitch!
property name=x value=y accessibility=Global /
Global is actually the default. If I had this:
property name=x value=y accessibility=Local /
It would mean that the property is accessible to all things in the
current scope where a scope is defined by the current target (project
for root level tasks) or TaskContainer. So this would cause an error
in the expression evaluator:
if test=true
property name=x value=y accessibility=Local / /if
echo message=${x} /
That's intuitive. You usually expect variable to be inaccessible when it
leaves the scope.
Because x is not accessible outside of the scope defined by the if
task container. This works with my earlier taskdef work too!
Interestingly the following won't work.
if test=true
property name=x value=y accessibility=Local / if test=true
echo message=${x} / /if /if
This one is counter-intuitive. Most languages use local for what
you've called flow. What is the use for local scoping anyway?
Because local is local to the current task container. I introduced a
third accessibility level called Flow which allows this to work.
Remember that the default is Global when you are using the property
/ task, so it won't break anything. The way it works is that I have
lots of PropertyDictionary objects attached to a hierarchy of Scope
objects.
The scope is updated when ever a build/target/task container starts or
finishes.
I haven't noticed a patch attached, but I don't know why do you want to
store multiple dictionaries? Usually the this kind of processing can be
done entirely on the evaluation stack.
I also modified quite a bit of the implementation of
PropertyDictionary so that it now stores a Property object as its
value although the external interface is unaffected (cross fingers I
didn't break anything).
Now that I have done this, and if there is enough interest I'd like to
propose that we do something like has been done for expression
evaluation, take a branch and do some exploritory work on this where
this = taskdef / and property scoping.
This definitely needs some thought. +1 for the branch idea.
Can I get a +1 or -1?
+2/3
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] Property Scoping
Scott,
I'd really prefer to branch on this - it has the ability to really break
things. One of the first changes is changing the PropertyDictionary to
to store Property objects instead of string values. The property object
is where the accessibility level is stored.
While I am really keen to put this in, I realise that this may not be
stable before the next release. One of the key drivers for the scoped
properties (for me anyway) is the inline task definitions. That's why I
wanted to see them together. Scoped properties would need to be
implemented first mind.
- Mitch Denny
- [EMAIL PROTECTED]
- http://www.monash.net
- +61 (414) 610141
-
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott
Hernandez
Sent: Thursday, 22 January 2004 7:37 AM
To: [EMAIL PROTECTED]
Subject: Re: [nant-dev] Property Scoping
Seems like the flow scope should be called local in C#/programming
terms, and local would be private/container-only scoping. Having
global be the default is a good call, but only in come case, as you
have identified in if//foreach//etc.
I'm sure we will be able to say more with a patch; so we can test things
out. If the changes are small enough, and defaults don't change existing
functionality, I'm happy to put them in the head since we are still a
little while from testing/beta'n this version.
I'd be inclined to separate the two patches, one for scoped properties
(which are core changes) and one for the new task def stuff.
- Original Message -
From: Mitch Denny [EMAIL PROTECTED]
Hi folks,
OK, I've got a bit of a prototype working for property scoping which
so
far appears to be non-breaking to existing scripts. It works like
this:
property name=x value=y accessibility=Global /
Global is actually the default. If I had this:
property name=x value=y accessibility=Local /
It would mean that the property is accessible to all things in the
current scope where a scope is defined by the current target (project
for root level tasks) or TaskContainer. So this would cause an error
in
the expression evaluator:
if test=true
property name=x value=y accessibility=Local /
/if
echo message=${x} /
Because x is not accessible outside of the scope defined by the if
task
container. This works with my earlier taskdef work too! Interestingly
the following won't work.
if test=true
property name=x value=y accessibility=Local /
if test=true
echo message=${x} /
/if
/if
Because local is local to the current task container. I introduced a
third accessibility level called Flow which allows this to work.
Remember that the default is Global when you are using the property
/
task, so it won't break anything. The way it works is that I have lots
of PropertyDictionary objects attached to a hierarchy of Scope
objects.
The scope is updated when ever a build/target/task container starts or
finishes.
I also modified quite a bit of the implementation of
PropertyDictionary
so that it now stores a Property object as its value although the
external interface is unaffected (cross fingers I didn't break
anything).
Now that I have done this, and if there is enough interest I'd like to
propose that we do something like has been done for expression
evaluation, take a branch and do some exploritory work on this where
this = taskdef / and property scoping.
Can I get a +1 or -1?
---
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
RE: [nant-dev] Property Scoping
Hiya,
Yeah, I was considering the same thing. I also wondered whether this
could mean that there could be a unified type system. Filesets, string
properties etc.
- Mitch Denny
- [EMAIL PROTECTED]
- http://www.monash.net
- +61 (414) 610141
-
-Original Message-
From: Jaroslaw Kowalski [mailto:[EMAIL PROTECTED]
Sent: Thursday, 22 January 2004 7:50 AM
To: Mitch Denny; Scott Hernandez; [EMAIL PROTECTED]
Subject: Re: [nant-dev] Property Scoping
Scott,
I'd really prefer to branch on this - it has the ability to really
break things. One of the first changes is changing the
PropertyDictionary to to store Property objects instead of string
values. The property object is where the accessibility level is
stored.
The branch is a good idea. I'd like to evaluate another issue: can we
have TYPED properties? Like this:
property name=counter type=integer value=0 /
This way you can write:
if test=${counter + 1 = 100}
/if
instead of:
if test=${convert::to-int(counter) + 1 = 100} /if
Once a property has its type set, it cannot be re-typed. Every time you
store a value in such a property, it is checked for type compatibility.
Storing data type (optional - would default to string) in a
PropertyDictionary would help here a lot.
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
