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: [nant-dev] NAntContrib update was ( Updating Nant-Contrib tolatest 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. 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. Ian Gert On Sat, 2003-06-28 at 18:53, Ian MacLean wrote: OK I bit the bullet on this today and copied all the NAntContrib tasks to a new NAnt.Optional directory under my nant source tree. I went thru and fixed all the issues Mike mentiond and then some. Nothing too difficult just lots of find and replace. It all compiles and the tasks load fine. I'm not going to commit this to the nant tree just yet because: 1) I don't think we are quite agreed that we should move all those tasks into NAnt ( although I'm starting to lean that way ) and 2) if we do move them I'll get the sf admins to import the .rcs files so that we can preserve the history. what I'll do is post the updated source as a zip tomorrow so that people can try it out and test that their favourite nantcontrib tasks are still working. NAnt.OptionalTasks.dll and dependencies weigh in at around 1mb which won't make the distribution too much larger. I'm going to propose that the optional stuff goes into a subdir of bin. so: bin\optional this way there is less clutter in the main bin directory and users will be able to change a taskpath setting in the config file to prevent scanning of NAnt.OptionalTasks.dll for tasks if they don't want to use it. so any feedback on the strategy to take - and stay posted for that .zip. Ian I am concerned about the friction NAnt users are experiencing trying to contribute and in general use the NAntContrib tasks: http://www.iunknown.com/000278.html I would love to help clean up NAntContrib. I have some recent experience from updating the StarTeam tasks. I will take a look at the items Mike listed and see what I can do. If anyone can relay motes of wisdom please jump in. Kevin Miller --- From: Mike Roberts <[EMAIL PROTECTED]> Updating Nant-Contrib to latest Nant 2003-06-25 14:56 I spent a couple of hours looking at updating Nant-Contrb last night to compile against the latest NAnt, and realised its a lot more than just changing the namespace hierarchy from Sourceforge.Nant to Nant.Core. Other updates since Nant 0.8.2 that effect Nant-Contrib include: - Logging has completely changed - Log Listeners have disappeared, so FileLogListener and the RecordTask need to change significantly - Some classnames have changed (e.g. 'MsftFXSDKExternalProgramBase') - Some stuff has moved to Nant.Core.Types - OptionCollection stuff seems to have completely changed - and more (I think) In light of this, the fact that I don't know Nant-Contrib very well, and also that there aren't a significant amount of tests, I'm now reluctant to update the whole of Nant-Contrib. I'm only using the task, so can just update that locally.. However, I'm going to bold now and give my opinion which the project leads are more than free to completely disregard. :) I don't really understand why Nant-Contrib and Nant are 2 separate projects. I can see the value in having separation to some extent (e.g. downloadable binaries, so that users don't have to download a bunch of tasks that they don't want), but on the other hand complete separation leads to (a) confusion in the user community and (b) the kind of situation that currently exists where there are significant differences between the 2 trees. I personally think it would be valuable, therefore, if the following happened: 1 - As a goal, the Nant-Contrib project should be phased out 2 - All the work (that is going to continue to live on) from Nant-Contrib should be (task-by-task) brought into the Nant project, maybe under a separate directory called 'optional-tasks'[a] 3 - The Nant buildfile should compile both the NAnt Core, the existing extra tasks and the 'optional-tasks' so that the latter of these don't get out of sync with changes to the core. 4 - ... a result of which would be the tasks imported from Nant-Contrib would also be updated to fit in with latest NAnt [a] - I actually think that
RE: [nant-dev] NAntContrib update was ( Updating Nant-Contrib tolatest Nant)
Not sure about VSS. Unfortunately the COM Interop for StarTeam is very necessary as it is the only programmatic interface to their server. Maybe I missed the point of the desire to be rid of it. The StarTeam SDK now has an "official" .NET interop assembly distributed with their 5.2 SDK. When the new contrib stuff stabilizes I will update the binary and build file if necessary. Is anyone using the StarTeam tasks in NantContrib? -Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Saturday, June 28, 2003 1:40 PM To: Ian MacLean Cc: Miller, Kevin; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [nant-dev] NAntContrib update was ( Updating Nant-Contrib tolatest Nant) 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 ? 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 ? 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] NAntContrib update was ( Updating Nant-Contrib tolatest Nant)
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 ? 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 ? Gert On Sat, 2003-06-28 at 18:53, Ian MacLean wrote: > OK I bit the bullet on this today and copied all the NAntContrib tasks > to a new NAnt.Optional directory under my nant source tree. > I went thru and fixed all the issues Mike mentiond and then some. > Nothing too difficult just lots of find and replace. It all compiles and > the tasks load fine. I'm not going to commit this to the nant tree just > yet because: > > 1) I don't think we are quite agreed that we should move all those tasks > into NAnt ( although I'm starting to lean that way ) and > 2) if we do move them I'll get the sf admins to import the .rcs files so > that we can preserve the history. > > what I'll do is post the updated source as a zip tomorrow so that people > can try it out and test that their favourite nantcontrib tasks are still > working. > > NAnt.OptionalTasks.dll and dependencies weigh in at around 1mb which > won't make the distribution too much larger. I'm going to propose that > the optional stuff goes into a subdir of bin. so: > bin\optional > > this way there is less clutter in the main bin directory and users will > be able to change a taskpath setting in the config file to prevent > scanning of NAnt.OptionalTasks.dll for tasks if they don't want to use it. > > so any feedback on the strategy to take - and stay posted for that .zip. > > Ian > > >I am concerned about the friction NAnt users are experiencing trying to > >contribute and in general use the NAntContrib tasks: > >http://www.iunknown.com/000278.html > > > >I would love to help clean up NAntContrib. I have some recent experience > >from updating the StarTeam tasks. I will take a look at the items Mike > >listed and see what I can do. If anyone can relay motes of wisdom please > >jump in. > > > >Kevin Miller > > > >--- > >From: Mike Roberts <[EMAIL PROTECTED]> > > Updating Nant-Contrib to latest Nant > >2003-06-25 14:56 > > I spent a couple of hours looking at updating Nant-Contrb last night to > > > > compile against the latest NAnt, and realised its a lot more than just > > changing the namespace hierarchy from Sourceforge.Nant to Nant.Core. > > Other updates since Nant 0.8.2 that effect Nant-Contrib include: > > - Logging has completely changed > > - Log Listeners have disappeared, so FileLogListener and the RecordTask > > > > need to change significantly > > - Some classnames have changed (e.g. 'MsftFXSDKExternalProgramBase') > > - Some stuff has moved to Nant.Core.Types > > - OptionCollection stuff seems to have completely changed > > - and more (I think) > > > > > > > > > In light of this, the fact that I don't know Nant-Contrib very well, > >and > > also that there aren't a significant amount of tests, I'm now reluctant > > > > to update the whole of Nant-Contrib. I'm only using the > >task, > > so can just update that locally.. > > > > However, I'm going to bold now and give my opinion which the > >project > > leads are more than free to completely disregard. :) > > > > I don't really understand why Nant-Contrib and Nant are 2 separate > > projects. I can see the value in having separation to some extent (e.g. > > > > downloadable binaries, so that users don't have to download a bunch of > > tasks that they don't want), but on the other hand complete separation > > leads to (a) confusion in the user community and (b) the kind of > > situation that currently exists where there are significant differences > > > > between the 2 trees. I personally think it would be valuable, > >therefore, > > if the following happened: > > 1 - As a goal, the Nant-Contrib project should be phased out > > 2 - All the work (that is going to continue to live on) from > > Nant-Contrib should be (task-by-task) brought into the Nant project, > > maybe under a separate directory called 'optional-tasks'[a] > > 3 - The Nant buildfile should compile both the NAnt Core, the existing > > extra tasks and the 'optional-tasks' so that the latter of these don't > > get out of sync with changes to the core. > > 4 - ... a result of which would be the tasks imported from Nant-Contrib > > > > would also be updated to fit in with latest NAnt > > > > [a] - I actually think that some of the (smaller) tasks from > > Nant-Contrib maybe better off in the main Nant download. Perhaps the > > NAnt committee would want to think about each task on a case-by-case > >basis. > > > > Of course, I'm a newbie round here, and there are probably very good > > reasons for the separation of the projects and I'm just being > > presumptuous to suggest su
