Re: [nant-dev] Re: NAnt
On Mon, 6 Sep 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: 1) A project can have an attribute of language=csharp (and this is needed to generate lib path). wouldn't we need a more generic platform or something like this. Would the lib path treatment of a J# or Nemerle or whatever .NET supported language be any different from the csharp case? 2) The workspace can have dotnet framework=mono-1.0.1 / to set the framework (passed to NAnt, must be a recently nightly, using -t:). Good idea. 3) jar (http://gump.apache.org/metadata/project.html#jar) ought be able to be replaced by output or assembly now. output with some type information would be my preference since it would also allow us to unify jar and license. Stefan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: NAnt
On Mon, 6 Sep 2004, Jaroslaw Kowalski [EMAIL PROTECTED] wrote: See this article Avoid DevPath for info on why you should avoid DEVPATH http://blogs.msdn.com/suzcook/archive/2003/08/15/57238.aspx Thanks again. , | It's not good for the dev. env., either - it makes it unnecessarily | different from the shipping env., which may lead to uncaught | versioning or deployment bugs in the shipping env. ` Is more or less the reason we run Gump. We want to catch versioning conflicts and backwards incompatible changes. We want to run an assembly against a version that it doesn't offically support. But , | So, DevPath is soon to be deprecated. ` probably is a show-stopper. I suggest that you do it the simple way - compile the all your apps/libraries to a single directory using it as both a target and a reference source and forget the GAC at all. Will that work with Mono 1.0.1 installing NUnit 2.1.91 into the GAC as it does on my Mac? I guess it will at compile time, but not when I run tests, right? Stefan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Looping constructs in NAnt
Alex Hildyard wrote:
Hi,
Is it possible to repeat an arbitrary set of tasks with a user-defined
exit condition? If not, could I propose this as a new task?
The foreach task lets you iterate over a certain set of prescribed
structures, but it would be nice to have something which simply provides
an uncomplicated
looping construct. For example:
Using foreach as an example, it would be a pretty simple task to create
a repeat task... I'm not sure this should be part of core NAnt though,
since it tends to undermine NAnt's position as a declarative language.
property name=var1 value=0/
repeat test=${var1 lt; 10}
echo message=${var1}/
property name=var1 value=${convert::to-int(var1)+1}/
/repeat
Currently I implement this with a call task, which doesn't really have
the right semantics, and means I have to initialise var1 from inside a
different
template, which tends to break the encapsulation.
target name=repeat
property name=var1 value=0 overwrite=false /
echo message=${var1} /
property name=var1 value=${convert::to-int(var1) + 1) /
call target=repeat if=${convert::to-int(var1) 10} /
/target
I'm not sure why you suggest that call doesn't have the right
semantics... you're simply re-rolling your iterative approach back into
a tail-recursive approach. The above should do exactly the same as your
repeat function, doesn't require pre-initialisation (the first time) and
is almost as concise.
If you use this often in your build, though, you would probably benefit
from creating the repeat task - the recursive approach will create
excessively verbose logs, especially when using an XML logger; also, any
loop variables will need to be reset (externally) before the second and
subsequent calls.
The other alternative is to wrap any loops in the script task. Use
could use Project.Execute to perform any required tasks... the example
above again:
target name=repeat-body
echo message=${var1} /
/target
target name=repeat
script language=C#
code![CDATA[
public static void ScriptMain(Project project) {
for (int i = 0; i 10; i++) {
Project.Properties[var1] = i;
Project.Execute(repeat-body);
}
}
]]/code
/script
/target
Regards,
-- Troy
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] NAnt and Gump -- getting closer...
All, I think I led Clayton down a false path, by me not knowing that bin/NAnt.exe was mini NAnt. (Sorry Clayton, you kept saying bin/NAnt.exe and I was clueless since (to me) that just seemed like a built NAnt, I didn't know it was mini-NAnt pre-stored in CVS.) All ... I am struggling here 'cos I'm no expert in what you know (NAnt/DotNet) only in Gump. I really want a good blend of what your platform requires, and what I (Gump) can do, but it is hard to get that blend since people come with pre-conceived notions/understandings (like mine not knowing mini-NAnt). I feel we are getting closer to understanding each other's areas, I feel we have a clearer understanding of how Gump will use NAnt, the artifacts it creates, and the tests it runs. I hope this translates to one simple implementation (that is easy for me/Gumpers to code :-) and that we don't keep finding better ways. Still, we are working through the details, we are getting there. I think the answer is 'who decides what is the right approach', and I feel it is the NAnt team. Gump has some good notions, but it is trying to emulate a developer (albeit in a clean environment) not dictate strategy. As such, if bin/NAnt.exe is the right way, I assume we use it. That said, it might be easiest [for me to code] for there to be a script (called bootstrap or mini-NAnt w/ .bat.sh) that calls the bin/NAnt.exe min-NAnt so we don't have to special code that. I think the full bootstrap process (as described by Jaraslow) where we build NAnt, build it's components, re-build NAnt is correct. That is pretty much what Ant does (they have a bootstrap-ant project and later an 'ant' project.) I think we can get to this. It seems right. I'd like to have the nant.xml metadata describe a bootstrap-nant project (maybe we call it mini-nant) that calls the script (that uses mini-NAnt to build NAnt.exe, wherever that is) and then we use that to build the next projects. If there really is no purpose for a script I could add an exe element to Gump, but that worries me (only a little). BTW: What (and where) are the assemblies that come out of running mini-NAnt? How would one then invoke them to be full NAnt? As for the GAC, and the DEVPATH environment variable, we don't have a perfect answer yet -- do we? Clayton was wondering if we could use References inside NAnt, and Gump write a pre-defined include file [it does something similar when it run Maven]. Does this idea have legs? Will it work for compiles and tests? Gump would like to be transparent to projects, if a convention exists that it can be, but if not we perhaps we can be creative, like this. I won't work on this more until we determine the final approach. BTW: Any help/descriptions that could be added to this page (blank, waiting for content) would be appreciated. http://wiki.apache.org/gump/GumpBuilders/NAntBuilder As for output -- it exists (as do artifact and jar) and ought work. Artifact and Jar are simply aliases (right now) with no extra meaning. What types were you thinking of Stefan? type=library and|or executable or something? As for language=csharp, if there truly is no significant difference between the various languages, I am more than game to do platform=dotnet|java. I could either add a platform, to supplement language, or replace. What do you think? BTW: Ought we attempt to contribute metadata for the mini-nant up to nant projects (including log4net, etc.) and see if we can get that working from within Gump? I think that makes a good first goal. regards, Adam - Original Message - From: Clayton Harbour [EMAIL PROTECTED] To: Adam R. B. Jack [EMAIL PROTECTED] Sent: Monday, September 06, 2004 8:51 PM Subject: RE: [nant-dev] Re: NAnt Hi Adam, I did not realize that you didn't know about the bin\NAnt.exe. Is that something that will suite your needs better than the .bat script? If so maybe we should look at using that, but if you would really prefer a complete rebuild then we can keep looking at the batch/ shell scripts. Let me know what you think. Cheers, Clayton -Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Mon 9/6/2004 1:16 PM To: Clayton Harbour; Jaroslaw Kowalski; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Subject: Re: [nant-dev] Re: NAnt I was talking with Adam the other day and he suggested that a batch/ shell script that built NAnt from source might be a little better than relying on the mini-NAnt.exe. I believe ant uses something similar to bootstrap itself so my understanding is that this fits in better with the gump philosophy. And just for completion ... mainly, I just didn't get what bin/NAnt.exe was, or how it worked. I didn't understand it was for bootstrap. Still, building from scratch each time does fit Gump's philosophy. regards Adam --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA
Re: [nant-dev] NAnt and Gump -- getting closer...
On Tue, 7 Sep 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I think the answer is 'who decides what is the right approach', and I feel it is the NAnt team. Yes, I agree. We may need to explain in more detail what we want to do and why we want to do that with Gump, but we need the expertize of the NAnt folks to achieve that. I'd like to have the nant.xml metadata describe a bootstrap-nant project (maybe we call it mini-nant) that calls the script (that uses mini-NAnt to build NAnt.exe, wherever that is) and then we use that to build the next projects. The script would need to know which framework you intend to use. For the Bourne shell script this simply means something like #!/bin/sh mono bin/NAnt.exe (ignoring Rotor and DotGNU for now) but the Windows batch file is a different beast. If there really is no purpose for a script I could add an exe element to Gump, but that worries me (only a little). Again, you'd need to handle it differently when running Mono (you don't invoke the executable directly). As for the GAC, and the DEVPATH environment variable, we don't have a perfect answer yet -- do we? No, I don't think we have. Since we control the machine running Gump we can ensure that the GAC is more or less empty. After that we may get away with the dump everything into a single directory strategy. Clayton was wondering if we could use References inside NAnt, and Gump write a pre-defined include file [it does something similar when it run Maven]. Does this idea have legs? Will it work for compiles and tests? I don't think it would work for tests. Can you specify the path to nunit.core.dll at runtime for NAnt's nunit task - or maybe before runtime, but to a value that may be different every day? As for output -- it exists (as do artifact and jar) and ought work. Artifact and Jar are simply aliases (right now) with no extra meaning. What types were you thinking of Stefan? type=library and|or executable or something? type=jar|license|library|executable|documentation|... As for language=csharp, if there truly is no significant difference between the various languages, I am more than game to do platform=dotnet|java. I think this would be the correct approach. BTW: Ought we attempt to contribute metadata for the mini-nant up to nant projects (including log4net, etc.) and see if we can get that working from within Gump? I think that makes a good first goal. I don't understand that, sorry. Are you asking whether we should try log4net first once we manage to use NAnt from within Gump? Yes, it looks like a good candidate. As would NUnit. Stefan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAnt and Gump -- getting closer...
BTW: Ought we attempt to contribute metadata for the mini-nant up to nant projects (including log4net, etc.) and see if we can get that working from within Gump? I think that makes a good first goal. I don't understand that, sorry. Are you asking whether we should try log4net first once we manage to use NAnt from within Gump? Yes, it looks like a good candidate. As would NUnit. When working with Clayton on Saturday we had NAnt being called by Gump (on it's own source), but that was a simple invocation (with NAnt expected to be on the path). The work for calculating a DEVPATH is in there, but untested in that simple scenario. Take a peek at gump-n.xml (workspace and profile) for this. Above I was discussing trying to set up the mini-nant (ala bootstrap-ant) to nant (ala ant) metadata, i.e. all the projects that are in this work list that Jaraslow (aka Jarek) wrote: --- Jarek wrote: BTW. I've been thinking about it for a while and the process of fully rebuilding NAnt is quite complicated: 1. Download NAnt sources from CVS 2. Bootstrap NAnt using mini-nant and binary libraries found in CVS (bin/lib directory) 3. From now on, use the bootstrapped NAnt 4. Download and rebuild the platform-neutral version of log4net.dll 5. Download and rebuild the platform-specific version of NUnit.*.dll 6. Download and rebuild the platform-specific version of NDoc.*.dll 7. Download and rebuild the ICSharpCode.SharpCvsLib.Console.dll referencing the log4net.dll built in step 4 8. Download and rebuild the ICSharpCode.SharpZip.dll 9. Put the just-built DLLs in the appropriate nant/bin/lib subdirectory 11. Bootstrap NAnt again by using the previously built nant (not the mini-nant) and the fresh libraries --- If we can square away this set of projects, and get this behaviour correct, and then (for projects that depends upon project==nant) use the output from 11, then I feel we've achieved a good enough/tested enough base. regards, Adam --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAnt and Gump -- getting closer...
The script would need to know which framework you intend to use. For the Bourne shell script this simply means something like #!/bin/sh mono bin/NAnt.exe (ignoring Rotor and DotGNU for now) but the Windows batch file is a different beast. We could set a Gump parameter in the workspace and launch nant-%FRAMEWORK%.[sh|bat] as the script, meaning a different one per framework. Alternatively we could pass the framework as a parameter. Whichever works best for the NAnt community... regards Adam --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: NAnt
I've been following this dicussion from the sidelines, and one idea that has occurred to me that may help, and should probably be addressed anyway, is having Gump produce its own public/private key pair for signing strong names for the assemblies. By using a separate key, you reduce the GAC problem to just other Gump builds, and if you can somehow guarantee a unique version number for Gump builds, you're home free. There is a tradeoff between how secure you're willing to keep the private key versus how easily a malicious or negligant user could break things, but that's no worse than the current situation. While NAnt doesn't need to go into the GAC, and hence doesn't need a strong name, other components such as NUnit do, at least for now. So I think that sooner or later you're going to have to ask the question as to whether you want to keep using the project-specific private keys. (I believe NAnt and NUnit each provide their own, different public/private key files in their source trees.) I haven't really thought this through. I'm just tossing it out as a possible different direction to investigate. Gary --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: fileset/directoryscanner hang
- Original Message - From: Matthew Mastracci [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: Ian MacLean [EMAIL PROTECTED] Sent: Tuesday, September 07, 2004 7:57 PM Subject: Re: fileset/directoryscanner hang I think we decided to just document this side-effect. My memory fails me here ... But if that is what we decided, then I guess we should indeed document it in both the filset doc and in the release notes .. The base directory is now returned when the pattern **/* is used, whereas before it was not. All other patterns are identical. AFAIK, **/* is equivalent to ** anyways. To avoid matching the base directory, people should be using */** instead. Would be interesting to check what Ant does here ... The reason for keeping this was that it was more consistent with patterns like foo/**/bar.cs. We can enhance the warning in DirectoryScanner.cs to recommend using either ** to match the base directory or */** to not match the base directory. I suppose we could even make that particular pattern an error. Not sure we should do this ... Gert PS. I'm copying the dev list in on this ... Gert Driesen wrote: Matthew, I think you already mentioned this before, but your changes actually have a side effect: the base directory of the fileset is now also returned as an entry in the DirectoryNames string collection. Is it possible to fix this side-effect ? Gert - Original Message - From: Matthew Mastracci [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: Ian MacLean [EMAIL PROTECTED] Sent: Saturday, September 04, 2004 5:10 PM Subject: Re: fileset/directoryscanner hang Okay. I see the problem now. If a Regex entry doesn't have a BaseDirectory set (like any of the exclude patterns) it won't be applied properly. I added code at one point to clear the BaseDirectory if the pattern is an exclude one. I'll take that out since it seems to be the culprit. Gert - can you reget CVS and see if this fixes your problem? Thanks, Matt. On Fri, 2004-09-03 at 23:33, Gert Driesen wrote: - Original Message - From: Matthew Mastracci [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: Ian MacLean [EMAIL PROTECTED] Sent: Friday, September 03, 2004 10:52 PM Subject: Re: fileset/directoryscanner hang Hrm... not sure what's going on. When you have a chance, please uncomment the DEBUG_REGEXES line in DirectoryScanner.cs and send me the output. It might help us find out what might be going on here. here you go ... Gert -- Matthew Mastracci [EMAIL PROTECTED] --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Looping constructs in NAnt
From: Alex Hildyard [EMAIL PROTECTED] Sent: Monday, September 06, 2004 6:06 PM Is it possible to repeat an arbitrary set of tasks with a user-defined exit condition? If not, could I propose this as a new task? Might I ask exactly what you're trying to accomplish with this? That might help with determining whether there isn't a declarative task itching to come out. Gary --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAnt and Gump -- getting closer...
I don't know exactly what you're trying to achieve with Gump, but IMO things are much easier than you think if you fully utilize NAnt's potential. Nant is quite a portable beast today. It can run on 4 platforms (mono-1.0, net-1.0, net-1.1, net-2.0) and compile for some more (netcf-1.0 and sscli). The platform of your choice influences all .NET tasks and involves platform-specific lookup and commandline parameter pasing. Many things have been done to assure platform independence so that you can run target multiple platforms with little to no change in your build scripts. NAnt provides all the logic to detect the presence and location of platform-specific assemblies and to pass them as arguments to appropriate commandline compilers. On windows it's possible to target all the platforms (including mono for windows). On Linux it's only possible to target mono-1.0. To compile for a particular platform you simply run nant.exe -targetframework:net-1.0 buildfile.build nant.exe -targetframework:net-1.1 buildfile.build nant.exe -targetframework:net-2.0 buildfile.build nant.exe -targetframework:mono-1.0 buildfile.build nant.exe -targetframework:netcf-1.0 buildfile.build If you don't provide the target platform it's assumed that you want to target the current platform you're running on (.NET 1.1 in most cases, but can be .NET 2.0 or .NET 1.0). Nant can be run from any directory, there's no need to invoke it in the build file directory. The sequence used to download, compile and install nant from CVS is very simple: cvs checkout nant nant\bin\NAnt.exe install -f:nant\NAnt.build -D:install.prefix=targetprefix I believe that all steps necessary to fully bootstrap nant from source (including external dependencies) can be easily put in a single build file that would be invoked by just-bootstrapped nant itself. The build would be very simple and would just consist of cvs-checkout, nant and copy tasks. Or perhaps I am missing something... Correct me if I'm wrong. Jarek BTW. You may contact me on ICQ #298783166 or somewhere on IRC - Original Message - From: Adam R. B. Jack [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stefan Bodewig [EMAIL PROTECTED] Sent: Tuesday, September 07, 2004 6:37 PM Subject: Re: [nant-dev] NAnt and Gump -- getting closer... The script would need to know which framework you intend to use. For the Bourne shell script this simply means something like #!/bin/sh mono bin/NAnt.exe (ignoring Rotor and DotGNU for now) but the Windows batch file is a different beast. We could set a Gump parameter in the workspace and launch nant-%FRAMEWORK%.[sh|bat] as the script, meaning a different one per framework. Alternatively we could pass the framework as a parameter. Whichever works best for the NAnt community... regards Adam --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: fileset/directoryscanner hang
I think we decided to just document this side-effect. My memory fails me here ... But if that is what we decided, then I guess we should indeed document it in both the filset doc and in the release notes .. Sounds fair. The reason for keeping this was that it was more consistent with patterns like foo/**/bar.cs. We can enhance the warning in DirectoryScanner.cs to recommend using either ** to match the base directory or */** to not match the base directory. I suppose we could even make that particular pattern an error. Not sure we should do this ... Since the pattern isn't optimal, I think a warning could be useful here. Ideally, you should choose one of the patterns above instead for maximum performance, rather than using the strange corner-case pattern itself. :) Matt. begin:vcard fn:Matthew Mastracci n:Mastracci;Matthew org:aclaro Softworks, inc. adr:;;1900 a - 11 St. SE;Calgary;Alberta;T2H 3G2;Canada email;internet:[EMAIL PROTECTED] title:Software Developer tel;work:(403) 299-6612 x-mozilla-html:FALSE url:http://www.aclaro.com version:2.1 end:vcard
Re: [nant-dev] NAnt and Gump -- getting closer...
I don't know exactly what you're trying to achieve with Gump, but IMO things are much easier than you think if you fully utilize NAnt's potential. Yeah, I think we need to step back and make that clear. Gump is attempting to emulate a rabid OSS developer, perform the steps a developer would do in order to download and build NAnt, and then others -- from scratch. This OSS developer is particulary anal, they don't want yesterdays build ... they want it fresh, everything the very latest. Their objective isn't to run this, it is to monitor for changes, disconnects. If project X breaks project Y the developer wishes to feel this pain. This automated developer is there to reduce pain for human developers/users, and to catch interface change pain early! If early enough perhaps the problem can be resolved before a release is made, and a problems gets into the field. Gump is a Python program that interacts with things (CVS, SVN, Shell, Ant, Maven) and we'd like NAnt. Gump wants to bootstrap NAnt 'cos it was to also catch NAnt changes --- not just compilation, but runtime. Being an outsider is important. Gump is Python (not Java) so it is spearate from concerns of the platform, and this ought make it a good candidate for working on DotNet. We want to work with NAnt as NAnt ought be worked with, but not inside NAnt, outside -- as a developer would be. Further, we want to allow existing NAnt scripts -- as they exist today -- without change. This allows projects to benefit from Gump without changing how they work. At least, that is what we'd like. For more/historical information see: http://gump.apache.org/why.html regards, Adam --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1023986 ] delay-sign task fails
Bugs item #1023986, was opened at 2004-09-07 17:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1023986group_id=31650 Category: Tasks Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard J Foster (richardjfoster) Assigned to: Nobody/Anonymous (nobody) Summary: delay-sign task fails Initial Comment: The delay-sign task appears to be attempting to use an executable called delay-sign.exe. I have no such executable available. Shouldn't it be trying to use sn -R? Development environment: Visual Studio 2003 Professional. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1023986group_id=31650 --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
