[nant-dev] Fileset references
Ian,
I've a target like the following that simply initializes a file set:
target name=dist
...
fileset id=archive.set basedir=${build.dir}
...
includes name=../AUTHORS/
includes name=../COPYRIGHT/
includes name=../LICENSE/
includes name=${package.name}/**/
excludes name=${package.name}/**/*.xml/
excludes name=${package.name}/**/*.resources/
/fileset
/target
... and then another target that uses it:
target name=package depends=dist
...
zip zipfile=${archive.name}
fileset refid=archive.set/
/zip
/target
Well, the resulting zip archive is empty. Am I missing
something?
Gius_.
--
Giuseppe Greco
::agamura::
phone: +41 (0)91 604 67 65
mobile: +41 (0)76 390 60 32
email: [EMAIL PROTECTED]
web:www.agamura.com
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAntContrib update was ( Updating Nant-Contrib to latest Nant)
- Original Message - From: Ian MacLean [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: Miller, Kevin [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 29, 2003 4:10 AM Subject: Re: [nant-dev] NAntContrib update was ( Updating Nant-Contrib to latest Nant) Gert Driesen wrote: How do you propose to deal with the NAntContrib sources ? will they be moved into /src/NAnt.Optional and /tests/NAnt.Optional or will they be integrated into the current namespace structure ? src/NAnt.Optional to start with and move those tasks that fit into NAnt.DotNet or NAnt.win2 or whatever. I think Optional has a place for the less frequently used tasks. Will you first make a proposal for incorporating the NAntContrib tasks into NAnt regarding source location, namespace and perhaps class name (don't know if we'll be needing to change class names as well, though). eg. right now, the vss tasks are in a separate namespace in NAntContrib, but we have no(t yet a) separate namespace for the cvs tasks. we should try to make it all consistent, I think I would still like to get rid of needing a COM interop assembly for SourceSafe (and if possible also for StarTeam, don't know if that's possible though). Can't we create a wrapper for the vss commandline tool ? why ? how else do you propose to connect to com code ? Sorry, but forgoing a perfectly good COM based api to wrap a command line tool seems completely backward to me. I don't understand the problem you have with interop assemblies - they are simply metadata and mappings that allow you to call COM objects. Is there somthing inherently evil about them that I don't know about ? Feel free to write wrappers in managed c++ if you want. The problem I have with COM interop assemblies is that they are linked to a specific version of the COM interface, and that they are specific to win32. Well, I know command-line interfaces can change too between versions, but you could still deal with that yourself. Up until now, we've always tried to create wrappers around command-line tools as these will likely be more portable, and I really think that's a good strategy after all. But if you think that using the COM interop assembly is the way to go, then that's fine by me. Gert --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Fileset references
Gius,
I forgot to make the filest in zip task settable - shold be fixed now.
Ian
Ian,
I've a target like the following that simply initializes a file set:
target name=dist
...
fileset id=archive.set basedir=${build.dir}
...
includes name=../AUTHORS/
includes name=../COPYRIGHT/
includes name=../LICENSE/
includes name=${package.name}/**/
excludes name=${package.name}/**/*.xml/
excludes name=${package.name}/**/*.resources/
/fileset
/target
... and then another target that uses it:
target name=package depends=dist
...
zip zipfile=${archive.name}
fileset refid=archive.set/
/zip
/target
Well, the resulting zip archive is empty. Am I missing
something?
Gius_.
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] NAnt.Optional.zip
grab it from http://www26.brinkster.com/ianm74/NAnt.Optional.zip unzip it under nant\src and add the following line to TaskAssemblies.txt : NAnt.Optional then just run the main nant build. this creates a new folder optional under build\nant-0.8.3-debug\bin with the optional tasks dll and its dependencies. If you run the newly built NAnt it will load the optional tasks as well as the core ones. I just got it compiling and tested a few of the tasks. Please try it out and let me know if anything is broken. Ian --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAntContrib update was ( Updating Nant-Contrib tolatest Nant)
Gert Driesen wrote: Will you first make a proposal for incorporating the NAntContrib tasks into NAnt regarding source location, namespace and perhaps class name (don't know if we'll be needing to change class names as well, though). eg. right now, the vss tasks are in a separate namespace in NAntContrib, but we have no(t yet a) separate namespace for the cvs tasks. we should try to make it all consistent, I think all valid points. However I think its important to get somthing people can use right away. NAnt.Optional is a good catch all for extra tasks and we can move them gradually to different namespaces/assemblies as appropriate. End users don't care which assembly/namespace a task resides in as long as it works. I will draw up a list of which tasks I think can be slotted into the existing nant task namespaces and I'll post it so that people can add to it. why ? how else do you propose to connect to com code ? Sorry, but forgoing a perfectly good COM based api to wrap a command line tool seems completely backward to me. I don't understand the problem you have with interop assemblies - they are simply metadata and mappings that allow you to call COM objects. Is there somthing inherently evil about them that I don't know about ? Feel free to write wrappers in managed c++ if you want. The problem I have with COM interop assemblies is that they are linked to a specific version of the COM interface, and that they are specific to win32. Well, I know command-line interfaces can change too between versions, but you could still deal with that yourself. I'm fairly sure that the interop assembly contains the typelib, interface and clsid GUIDs from the source typelib. So if the implementation of the COM interface is updated but the guids not changed it will still work. Sourcesafe is also specific to win32 - so that isn't really an issue. I don't know about starteam though. we can update the interop assembly when the interface changes. Up until now, we've always tried to create wrappers around command-line tools as these will likely be more portable, and I really think that's a good strategy after all. not in all cases. We have done for the sdk tools and compilers- the reasoning there being that : we didn't want to be bound to a specific framework version for those tools. ie if we use the .exe then changing frameworks is only a matter of pointing at a different directory - as opposed to binding to different assemblies. since the compilers are commonly used on the commandline we wanted to ensure that the output was the same from nant as form the commandline. for cvs and zip we already bind to libraries - although they aren't COM ones. But if you think that using the COM interop assembly is the way to go, then that's fine by me. well I just don't have an issue with it and its the implementation we have. If what we had was a wrapper around a sourcesafe commandline tool then I'd probably be happy with that too. Ian --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [NAntC-Dev] RE: [nant-dev] NAntContrib update was ( UpdatingNant-Contrib to latest Nant)
Tomas Restrepo wrote: Humm That sounds much better. Still, I'd personally prefer not to end with something like Nant.Optional :) I believe we could move these into their own assemblies and then just do whatever we want in how to build them (the organization thingie seems to be creeping up again :P). Anyway I'm guessing the real problem is what should go on in the basic distribution I'm not so sure. I see NAnt.optional as a place for new tasks that may or may not be useful. As such it will always have a place. So if we get a new task donated and we're not sure if it will be useful or not we can drop it in optional and use the feedback we get to decide whether to keep it or re-locate it to a different task assembly. and since NAnt.Optional.Tasks.dll + dependencies adds up to 1.2mb I don't have a problem shipping the whole thing. I also tried moving the sources last night but got a little bored after around 1 hour... Had most of it compiling, too, but then again, I'm fairly familiar with both Nant and NAntContrib (heck, I wrote my fair share of the tasks in NantContrib, after all). The checklist sounds like a very good idea! OK - I'll get on to it. Ian --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Namespaces and NAnt.Cnntrib tasks
Gert Driesen wrote: Will you first make a proposal for incorporating the NAntContrib tasks into NAnt regarding source location, namespace and perhaps class name (don't know if we'll be needing to change class names as well, though). below is my basic proposal for where I see the nantcontrib tasks fitting into nant. Source location and namespace are effectively the same thing in our source structure. I'm not too bothered whether everything is moved before the next release because users will be able to use them all regardless. Some of these tasks need some work with regard to formatting, code style etc and I would prefer to have that done before they are moved. comments suggestions ? NAnt.DotNet AssemblyInfoTask.cs DiscoTask.cs GacTask.cs NGenTask.cs WsdlTask.cs XsdTask.cs VersionTask.cs TypedCollectionTask.cs NAnt.Win32 ADSIBaseTask.cs ADSIGetPropertyTask.cs ADSISetPropertyTask.cs TlbExpTask.cs TlbImpTask.cs AxImpTask.cs COMRegisterTask.cs RegasmTask.cs Vb6Task.cs NAnt.VisualCpp RcTask.cs MidlTask.cs McTask.cs NAnt.NUnit.NUnit2 NUnitReportTask.cs NAnt.SourceControl.SourceSafe AddTask.cs BaseTask.cs CheckinTask.cs CheckoutTask.cs GetTask.cs LabelTask.cs UndoCheckoutTask.cs General/NAnt.Core ?? ScpTask.cs ValidateXmlTask.cs CodeStatsTask.cs ConcatTask.cs unknown - stay in NAnt.Optional ? ChecksumTask.cs HxCompTask.cs HxRegTask.cs IISTasks.cs MailExTask.cs MgmtClassGenTask.cs MSITask.cs MSMTask.cs RecordTask.cs SchemaValidatedTask.cs SlingshotTask.cs SqlTask.cs NAnt.Optional.StarTeam ... eg. right now, the vss tasks are in a separate namespace in NAntContrib, but we have no(t yet a) separate namespace for the cvs tasks. we should try to make it all consistent, I think of course. Can you think of a name for the directory containing the cvs tasks that isn't 'CVS' ? Ian --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Namespaces and NAnt.Cnntrib tasks
Looks pretty much ok, some minor comments/questions inline ... - Original Message - From: Ian MacLean [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, June 29, 2003 2:56 PM Subject: [nant-dev] Namespaces and NAnt.Cnntrib tasks Gert Driesen wrote: Will you first make a proposal for incorporating the NAntContrib tasks into NAnt regarding source location, namespace and perhaps class name (don't know if we'll be needing to change class names as well, though). below is my basic proposal for where I see the nantcontrib tasks fitting into nant. Source location and namespace are effectively the same thing in our source structure. I'm not too bothered whether everything is moved before the next release because users will be able to use them all regardless. Some of these tasks need some work with regard to formatting, code style etc and I would prefer to have that done before they are moved. comments suggestions ? NAnt.DotNet AssemblyInfoTask.cs DiscoTask.cs GacTask.cs NGenTask.cs WsdlTask.cs XsdTask.cs VersionTask.cs TypedCollectionTask.cs NAnt.Win32 ADSIBaseTask.cs ADSIGetPropertyTask.cs ADSISetPropertyTask.cs Are these actually win32 specific tasks ? Their name does suggest that, but these are using System.DirectoryServices right ? We can leave them in Win32 for now, and decide later ... TlbExpTask.cs TlbImpTask.cs AxImpTask.cs COMRegisterTask.cs RegasmTask.cs Vb6Task.cs NAnt.VisualCpp RcTask.cs MidlTask.cs McTask.cs NAnt.NUnit.NUnit2 NUnitReportTask.cs Hasn't this task been supersedes by http://nunit2report.sourceforge.net ? NAnt.SourceControl.SourceSafe AddTask.cs BaseTask.cs CheckinTask.cs CheckoutTask.cs GetTask.cs LabelTask.cs UndoCheckoutTask.cs Will this be NAnt.SourceControl.SourceSafe.Tasks or NAnt.SourceControl.Tasks.SourceSafe ? General/NAnt.Core ?? ScpTask.cs ValidateXmlTask.cs CodeStatsTask.cs ConcatTask.cs not too sure about the usefulness of the CodeStatsTask here. Shouldn't it be in NAnt.DotNet anyway ? unknown - stay in NAnt.Optional ? ChecksumTask.cs HxCompTask.cs HxRegTask.cs IISTasks.cs MailExTask.cs MgmtClassGenTask.cs MSITask.cs MSMTask.cs RecordTask.cs SchemaValidatedTask.cs SlingshotTask.cs SqlTask.cs NAnt.Optional.StarTeam ... eg. right now, the vss tasks are in a separate namespace in NAntContrib, but we have no(t yet a) separate namespace for the cvs tasks. we should try to make it all consistent, I think of course. Can you think of a name for the directory containing the cvs tasks that isn't 'CVS' ? I'm afraid not ... Gert --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [NAntC-Dev] RE: [nant-dev] NAntContrib update was ( Updating Nant-Contrib to latest Nant)
Hi Ian, I'm not so sure. I see NAnt.optional as a place for new tasks that may or may not be useful. I guess this is what I don't like. Useful? Uhh... If someone wrote the damn thing, I'm sure *they* considered it useful. Who are we to decide what is useful and what not? But, if you guys decide we should be so bold as to take on that decision, then it becomes much easier: don't accept things that are *not useful* in the first place, and now you don't need NAnt.Optional again. If you were to say Nant.Experimental, well, that would convey a completely different meaning jejejeje -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [NAntC-Dev] RE: [nant-dev] NAntContrib update was ( UpdatingNant-Contrib to latest Nant)
Tomas, Maybe my phrasing was a bit off. Obviously they are useful for someone. I have no problem calling it Nant.Experimental. Optional just came from the equivalent in Ant. Ian Hi Ian, I'm not so sure. I see NAnt.optional as a place for new tasks that may or may not be useful. I guess this is what I don't like. Useful? Uhh... If someone wrote the damn thing, I'm sure *they* considered it useful. Who are we to decide what is useful and what not? But, if you guys decide we should be so bold as to take on that decision, then it becomes much easier: don't accept things that are *not useful* in the first place, and now you don't need NAnt.Optional again. If you were to say Nant.Experimental, well, that would convey a completely different meaning jejejeje -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ NAntContrib-Developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Namespaces and NAnt.Cnntrib tasks
Gert Driesen wrote: NAnt.Win32 ADSIBaseTask.cs ADSIGetPropertyTask.cs ADSISetPropertyTask.cs Are these actually win32 specific tasks ? Their name does suggest that, but these are using System.DirectoryServices right ? We can leave them in Win32 for now, and decide later ... is ADSI implemented on other platforms ? - I just took a guess that it wasn't NAnt.NUnit.NUnit2 NUnitReportTask.cs Hasn't this task been supersedes by http://nunit2report.sourceforge.net ? maybe so. I wonder if Gilles will let us ship with it. Its gpl so probably. NAnt.SourceControl.SourceSafe AddTask.cs BaseTask.cs CheckinTask.cs CheckoutTask.cs GetTask.cs LabelTask.cs UndoCheckoutTask.cs Will this be NAnt.SourceControl.SourceSafe.Tasks or NAnt.SourceControl.Tasks.SourceSafe ? probably NAnt.SourceControl.SourceSafe.Tasks unless you think we should bundle all sourcecontrol tasks in one assembly. General/NAnt.Core ?? CodeStatsTask.cs ConcatTask.cs not too sure about the usefulness of the CodeStatsTask here. Shouldn't it be in NAnt.DotNet anyway ? does it only work with cs files ? Anything we have doubts about can go in Optional - or Experimental - depending on how it ends up. Ian --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Namespaces and NAnt.Cnntrib tasks
Hi Ian, Gert, Cc: [EMAIL PROTECTED] Subject: Re: [nant-dev] Namespaces and NAnt.Cnntrib tasks NAnt.NUnit.NUnit2 NUnitReportTask.cs Hasn't this task been supersedes by http://nunit2report.sourceforge.net ? maybe so. I wonder if Gilles will let us ship with it. Its gpl so probably. The NUnitReportTask in NAntContrib only works with Nunit 1 (which afaik we still support). The other one supports NUnit2 that I recall. So it would be nice to have both, certainly. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] NAntContrib
I am a bit confused. Is NAntContrib going away? From my understanding it was meant to be a standard place where people could share any tasks that they had written, regardless of weather they were deemed usefull by the NAnt team. If the NAnt team thought a task was usefull enough to a large audience then they could cherry pick from the NAntContrib and include it in a future release. I don't see the need to include ALL tasks into NAnt (but I do think that most of the tasks submitted are generally usefull), and that tasks not included should stay in NAntContrib. brant ... - Original Message - From: Gert Driesen [EMAIL PROTECTED] To: Ian MacLean [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, June 29, 2003 6:33 AM Subject: Re: [nant-dev] Namespaces and NAnt.Cnntrib tasks Looks pretty much ok, some minor comments/questions inline ... - Original Message - From: Ian MacLean [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, June 29, 2003 2:56 PM Subject: [nant-dev] Namespaces and NAnt.Cnntrib tasks Gert Driesen wrote: Will you first make a proposal for incorporating the NAntContrib tasks into NAnt regarding source location, namespace and perhaps class name (don't know if we'll be needing to change class names as well, though). below is my basic proposal for where I see the nantcontrib tasks fitting into nant. Source location and namespace are effectively the same thing in our source structure. I'm not too bothered whether everything is moved before the next release because users will be able to use them all regardless. Some of these tasks need some work with regard to formatting, code style etc and I would prefer to have that done before they are moved. comments suggestions ? NAnt.DotNet AssemblyInfoTask.cs DiscoTask.cs GacTask.cs NGenTask.cs WsdlTask.cs XsdTask.cs VersionTask.cs TypedCollectionTask.cs NAnt.Win32 ADSIBaseTask.cs ADSIGetPropertyTask.cs ADSISetPropertyTask.cs Are these actually win32 specific tasks ? Their name does suggest that, but these are using System.DirectoryServices right ? We can leave them in Win32 for now, and decide later ... TlbExpTask.cs TlbImpTask.cs AxImpTask.cs COMRegisterTask.cs RegasmTask.cs Vb6Task.cs NAnt.VisualCpp RcTask.cs MidlTask.cs McTask.cs NAnt.NUnit.NUnit2 NUnitReportTask.cs Hasn't this task been supersedes by http://nunit2report.sourceforge.net ? NAnt.SourceControl.SourceSafe AddTask.cs BaseTask.cs CheckinTask.cs CheckoutTask.cs GetTask.cs LabelTask.cs UndoCheckoutTask.cs Will this be NAnt.SourceControl.SourceSafe.Tasks or NAnt.SourceControl.Tasks.SourceSafe ? General/NAnt.Core ?? ScpTask.cs ValidateXmlTask.cs CodeStatsTask.cs ConcatTask.cs not too sure about the usefulness of the CodeStatsTask here. Shouldn't it be in NAnt.DotNet anyway ? unknown - stay in NAnt.Optional ? ChecksumTask.cs HxCompTask.cs HxRegTask.cs IISTasks.cs MailExTask.cs MgmtClassGenTask.cs MSITask.cs MSMTask.cs RecordTask.cs SchemaValidatedTask.cs SlingshotTask.cs SqlTask.cs NAnt.Optional.StarTeam ... eg. right now, the vss tasks are in a separate namespace in NAntContrib, but we have no(t yet a) separate namespace for the cvs tasks. we should try to make it all consistent, I think of course. Can you think of a name for the directory containing the cvs tasks that isn't 'CVS' ? I'm afraid not ... Gert --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: [NAntC-Dev] NAntContrib update was ( Updating Nant-Contrib to latest Nant)
The other problem we will have, that we haven't really addressed, is in describing the dependencies of some of the tasks. Take the MSI tasks as an example. There is a lot of stuff that needs to be installed to actually use it. It might be best to introduce the idea of a dependencies/requirements section in the documentation of each task. With so much need for external executables, or COM objects, in our tasks it is really hard to see what is needed sometimes at runtime. It seems like we can change the nant behavior to look in bin/tasks/**/*tasks.* for any tasks. Then we can just distribute any optional tasks with nice directory names there. It would keep things a little cleaner than putting everything is bin. - Original Message - From: Mike Roberts [EMAIL PROTECTED] Ian - you're a star - thanks! (and thanks for letting us know before I was going and do the same thing for some of the tasks. :) ) re: directory tree / namespaces. My own take is that tasks that have binary dependencies outside of NAnt at least at compile time (e.g. StarTeam with its interop requirement) should go into an optional directory, but that there's no harm in other tasks being merged into the main NAnt tree (e.g. I would make GacTask 'Nant.DotNet.Tasks.GacTask' in nant/src/NAnt.DotNet/Tasks and StarTeamTask 'Nant.Optional.SourceControl.Tasks.StarTeamTask in (maybe) nant/src/NAnt.Optional/SourceControl/Tasks). If the task help index page starts getting cluttered, we can always make it categorized based on namespace, and then alphabetical. In terms of how this is packaged into binaries, I think the main NAnt release could be everything apart from NAnt.Optional. The optional tasks could be a separate download and if required dropped into Nant/bin as normal (yes, its cluttered but will only be there if people need it, and it removes the need for sub-directories and multiple paths) ... but both of these things are minor - the fact that a lot of these tasks are going into NAnt at all is the main thing so thanks again! [snip] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Fileset references
I forgot to make the filest in zip task settable - shold be fixed now. You added a unit test for this before fixing it, right? :) John C Barstow --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] NAntContrib
For what it's worth, here's my opinion. I'm trying to arrange things so releases will be less chaotic affairs, so that's my main bias in my arguments. NAntContrib should be distributed with NAnt. That means when we have a release, we build both and package all the binaries and source together. The list of tasks that make up NAnt need to stabilize before 1.0. There's too much change between releases (though more frequent releases will help fix this). By necessity, everything else needs to go into NAntContrib. I think for the next release (0.8.3.xxx), we should NOT restructure the code; it will only delay things and confuse people. Instead, we simply need to fix the project so it builds against the current version of NAnt. Both projects will be built and distributed together for this release. The following release (0.8.4.xxx), we should do whatever restructuring is necessary, as long as we can agree that no major refactorings are going to take place after this. One of the reasons my company is paying for me to work on this is because we are using the project in our production environment; if things start breaking I know I'm the one they're going to blame. After that (0.8.xxx), there needs to be a major push to test everything. Writing lots of test scripts, and a lot more unit tests. There are a number of subtle, untracked bugs caused by dependencies, cascades, etc. Part of the reason people complain about the extent of changes is so much stuff breaks. Better unit tests would make it a lot easier to find *and document* the scope of proposed changes before they are made. For the (0.9.xxx) releases, we really should be concentrating on documenting things and bug fixing. We need a *lot* more examples, so people don't keep reinventing the wheel and so people get a deep understanding of how build scripts work. Unfortunately, the major features that get implemented between releases make it much harder to get a deep understanding of the system; that makes it harder to contribute to the core and everyone ends up trying to commit to NAntContrib where everything breaks anyhow. I know there are lots of really useful features that need to be added, but the tasks that are in there TODAY are letting people write sophisticated, production-quality build systems. If we can polish and document the existing functionality, we have a solid core for a 1.0 release, and a much better foundation for integrating changes and tasks going forward. - As for doing my part, I am going to be writing some fairly extensive release notes this go round. Expect a first draft in about two days. In addition, I'm going to be putting in some more unit tests as soon as we ship 0.8.3.xxx. I'm also going to be pretty aggressive about trying to get out a new release every month. - John C Barstow --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Namespaces and NAnt.Cnntrib tasks
probably NAnt.SourceControl.SourceSafe.Tasks unless you think we should bundle all sourcecontrol tasks in one assembly. I was actually thinking of bundling them all in one assembly, but then we run into trouble on Mono with the VSS COM interop library :-) Its only a problem if the vss task is called. Having a separate assembly for each source control provider seems a bit overkill, no ? maybe - we have a seperate assembly for ziptasks right now. Ian --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAntContrib
ok - lets get nantcontrib building as it is for this release. That list of tasks I posted earlier - assigned to namespaces should be moved into NAnt and the remainder can stay in NAntContrib - how does that sound ? Ian Brant, I actually share your opinion on this one, but this isn't something one person should decide. I think the decision has already been made on this, but I would've preferred not to do this in a rush ... Gert - Original Message - From: brant [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED]; Ian MacLean [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, June 29, 2003 7:01 PM Subject: [nant-dev] NAntContrib I am a bit confused. Is NAntContrib going away? From my understanding it was meant to be a standard place where people could share any tasks that they had written, regardless of weather they were deemed usefull by the NAnt team. If the NAnt team thought a task was usefull enough to a large audience then they could cherry pick from the NAntContrib and include it in a future release. I don't see the need to include ALL tasks into NAnt (but I do think that most of the tasks submitted are generally usefull), and that tasks not included should stay in NAntContrib. brant ... - Original Message - From: Gert Driesen [EMAIL PROTECTED] To: Ian MacLean [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, June 29, 2003 6:33 AM Subject: Re: [nant-dev] Namespaces and NAnt.Cnntrib tasks Looks pretty much ok, some minor comments/questions inline ... - Original Message - From: Ian MacLean [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, June 29, 2003 2:56 PM Subject: [nant-dev] Namespaces and NAnt.Cnntrib tasks Gert Driesen wrote: Will you first make a proposal for incorporating the NAntContrib tasks into NAnt regarding source location, namespace and perhaps class name (don't know if we'll be needing to change class names as well, though). below is my basic proposal for where I see the nantcontrib tasks fitting into nant. Source location and namespace are effectively the same thing in our source structure. I'm not too bothered whether everything is moved before the next release because users will be able to use them all regardless. Some of these tasks need some work with regard to formatting, code style etc and I would prefer to have that done before they are moved. comments suggestions ? NAnt.DotNet AssemblyInfoTask.cs DiscoTask.cs GacTask.cs NGenTask.cs WsdlTask.cs XsdTask.cs VersionTask.cs TypedCollectionTask.cs NAnt.Win32 ADSIBaseTask.cs ADSIGetPropertyTask.cs ADSISetPropertyTask.cs Are these actually win32 specific tasks ? Their name does suggest that, but these are using System.DirectoryServices right ? We can leave them in Win32 for now, and decide later ... TlbExpTask.cs TlbImpTask.cs AxImpTask.cs COMRegisterTask.cs RegasmTask.cs Vb6Task.cs NAnt.VisualCpp RcTask.cs MidlTask.cs McTask.cs NAnt.NUnit.NUnit2 NUnitReportTask.cs Hasn't this task been supersedes by http://nunit2report.sourceforge.net ? NAnt.SourceControl.SourceSafe AddTask.cs BaseTask.cs CheckinTask.cs CheckoutTask.cs GetTask.cs LabelTask.cs UndoCheckoutTask.cs Will this be NAnt.SourceControl.SourceSafe.Tasks or NAnt.SourceControl.Tasks.SourceSafe ? General/NAnt.Core ?? ScpTask.cs ValidateXmlTask.cs CodeStatsTask.cs ConcatTask.cs not too sure about the usefulness of the CodeStatsTask here. Shouldn't it be in NAnt.DotNet anyway ? unknown - stay in NAnt.Optional ? ChecksumTask.cs HxCompTask.cs HxRegTask.cs IISTasks.cs MailExTask.cs MgmtClassGenTask.cs MSITask.cs MSMTask.cs RecordTask.cs SchemaValidatedTask.cs SlingshotTask.cs SqlTask.cs NAnt.Optional.StarTeam ... eg. right now, the vss tasks are in a separate namespace in NAntContrib, but we have no(t yet a) separate namespace for the cvs tasks. we should try to make it all consistent, I think of course. Can you think of a name for the directory containing the cvs tasks that isn't 'CVS' ? I'm afraid not ... Gert --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email
Re: [nant-dev] NAntContrib
John Barstow wrote: For what it's worth, here's my opinion. I'm trying to arrange things so releases will be less chaotic affairs, so that's my main bias in my arguments. NAntContrib should be distributed with NAnt. That means when we have a release, we build both and package all the binaries and source together. The list of tasks that make up NAnt need to stabilize before 1.0. There's too much change between releases (though more frequent releases will help fix this). By necessity, everything else needs to go into NAntContrib. agreed. Actually the list of tasks has been fairly stable - its been code in the core thats been changing recently. I think for the next release (0.8.3.xxx), we should NOT restructure the code; it will only delay things and confuse people. Instead, we simply need to fix the project so it builds against the current version of NAnt. Both projects will be built and distributed together for this release. ok fair enough. NAntContrib now builds against the latest nant cvs so we're on the way. The following release (0.8.4.xxx), we should do whatever restructuring is necessary, as long as we can agree that no major refactorings are going to take place after this. One of the reasons my company is paying for me to work on this is because we are using the project in our production environment; if things start breaking I know I'm the one they're going to blame. again good. The only re-structuring I forsee is moving some tasks from contrib into main. Unfortunately, the major features that get implemented between releases make it much harder to get a deep understanding of the system; that makes it harder to contribute to the core and everyone ends up trying to commit to NAntContrib where everything breaks anyhow. I know there are lots of really useful features that need to be added, but the tasks that are in there TODAY are letting people write sophisticated, production-quality build systems. If we can polish and document the existing functionality, we have a solid core for a 1.0 release, and a much better foundation for integrating changes and tasks going forward. Why don't we try and capture all of these features as well as all the fixes and documentation that needs doing. Then we can start assigning them to specific releases up to 1.0 and beyond. - As for doing my part, I am going to be writing some fairly extensive release notes this go round. Expect a first draft in about two days. In addition, I'm going to be putting in some more unit tests as soon as we ship 0.8.3.xxx. I'm also going to be pretty aggressive about trying to get out a new release every month. - John C Barstow --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] LONG: New idea for handling build configurations
Hi all!
Recently Giuseppe has prepared a document that describes recommended build
configurations. This document and c.a. 99.441% of all build files in the
universe attempt to invent their own methods for setting up parameters like:
debug, optimize, defines for master and child builds.
THE PROBLEM:
Most of the time you see this:
property name=something.debug value=... /
property name=something.optimize value=... /
and then
csc ... debug=${something.debug} optimize=${something.optimize}
/csc
and all csc tasks tend to use the same settings in the whole buildfile.
I think that the following covers at least 80% of all cases:
1. Most of the build files are simple: they use a single setting for
debug, optimize, defines in all their outputs.
2. Builds that have many subdirectories tend to pass their current settings
to sub-builds (we have inheritance here).
3. Most of the time you want to have configurations like: debug and
release configurations (perhaps something third, but nothing more).
4. Build files tend to produce their output to a single directory, because
it's in accordance to .NET deployment model, so being able to specify a
default target directory makes sense in general.
5. You need to write some boilerplate code even for the simplest tasks if
you want any degree of flexibility
THE SOLUTION - IDEA
===
My idea (not complete yet, but may serve as a base for some discussion) is
to introduce a concept of configurations.
The configuration would define and group the most commonly used settings
(perhaps global properties) like:
default value of debug parameter for all tasks
default value of optimize parameter for all tasks
default value of defines parameter for all tasks
default value for output directory for all tasks
(and perhaps even more reasonable defaults)
You would invoke NAnt by specifying the build file and the configuration
(both can have defaults specified in project tag.
NAnt.exe -cfg:debug build
would build target build with configuration debug.
It would be possible to build all configurations by something like
NAnt.exe -cfg:all build
The configuration definition would be provided by:
NAnt:
NAnt would provide reasonable defaults for flags like debug,
optimize,
defines, and output directory. They should be provided (perhaps in
NAnt.exe.config)
for debug and release configurations.
command line:
Users may want to override some particular setting on the command line
nant.exe -D:default.csc.debug=false
configuration file:
(not well thought out, but I think it sould be
possible so you don't need to specify long command lines)
build file:
Build file would contain a bunch of:
configuration name=debug
property name=default.jsc.debug value=false /
property name=default.csc.debug value=true /
property name=default.debug value=true /
property name=default.csc.outdir value=bin/debug /
/configuration
configuration name=release
property name=default.jsc.debug value=false /
property name=default.csc.debug value=true /
property name=default.debug value=true /
property name=default.csc.outdir value=bin/release /
/configuration
As you can see I propose some form of default values inheritance. For
example csc task whould look for the value for its debug parameter by
looking at (in order):
- the value specified in csc task
- if it's not found, get it from default.csc.debug
- if it's not specified, get the value from default.debug
And all csc tasks would be reduced to:
csc target=winexe output=test.exe
sources
/sources
/csc
instead of (ugly in my opinion):
csc
target=winexe
output=${something.outdir}/test.exe
debug=${something.debug}
optimize=${something.optimize}
define=${something.define}
sources
/sources
...
/csc
The idea is to have ultra-clean, yet very flexible build files that would be
very easy to create and maintain.
I think it would be simple to implement it using current model of
properties.
What do you think?
Jarek
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
