[nant-dev] Re: In case you haven't seen this yet

[Matthew Mastracci]

If the MSBuild schema is anything like the Office 2003 schema, we 
probably can't touch it:

http://www.microsoft.com/mscorp/ip/format/xmlpatentlicense.asp

"If you distribute, license or sell a Licensed Implementation, this 
license is conditioned upon you requiring that the following notice be 
prominently displayed in all copies and derivative works of your source 
code and in copies of the documentation and licenses associated with 
your Licensed Implementation:"

- and -

"You are not licensed to distribute a Licensed Implementation under 
license terms and conditions that prohibit the terms and conditions of 
this license."

- and -

"You are not licensed to sublicense or transfer your rights."

It's a very questionable license, AFAIK incompatible with the GPL.  It 
will be interesting to see if they are going to pull the same thing with 
MSBuild.

Matt.

Scott Hernandez wrote:

Alex,
 
Yeah, sounds like a good break-down.
 
1 and 2 sound pretty easy. It would be nice to do this in the managed 
world but I expect we will need to run each others binaries as external 
processes. We have a stub console loader that does everything an 
external program would need to do to in order to run a build file, from 
the managed world. As we are still in pre-1.0 release mode now is good 
time to make changes that need to.
 
As for a transformation between our file formats, this gets a little 
more hairy. We support a config file format that supplements a lot of 
what *could* be explicitly set in the build file via a config section of 
the app.config. I think we may need more than just a xslt to make it 
work well. There are also issues of mapping task params, and tasks 
themselves, from one framework to the other. This seems reasonable, but 
like a fairly large task. It might make sense to setup a website where 
this type of mapping information can be collected by the user base and a 
xslt file can be dynamically created based on the version of our two 
frameworks you are converting from/to. As NAnt is an open source 
project, and we will probably be releasing more often than MSBuild, it 
would make sense that anything MSBuild ships (or NAnt for that matter) 
will be stale by the time it hits the street. That is why a website that 
generates a build transformation is probably more useful than a static 
file shipped in a release. Will MSBuild provide XSDs for all types of tasks?
 
I expect the format of tasks will stay relatively static (in NAnt), and 
there are probably some simple places where we can interact and provide 
examples, and guidelines (for what to do, and not to do) in order to 
build tasks that work in both frameworks. But there will always be 
differences in the services that our frameworks offer to task developer. 
Logging, property access (build file variables), our expression 
languages, exception propagation, and utility classes are all things 
that will differ from build framework to framework. It will be good to 
put together guideline as to what should work across our frameworks.
 
I'd be more than happy to (as I'm sure other active devs will be also) 
work on these issues, but I really need to know that legally we are not 
stepping into the sh*T in doing so.
 
Moving forward this is a clear place where we can work together and 
build a solution for our users that is seamless and empowering. Every 
step we take we keep in mind the ability and flexibility of our users. 
With that in mind, working together seems like a great idea.
 
Alex, would you be willing to have a sit-down meeting in the next few 
weeks to work on some of these ideas? It would be good to keep fostering 
these ideas of communication between the NAnt and MSBuild teams.
 

- Original Message -
*From:* Alex Kipman 
*To:* Scott Hernandez  ;
[EMAIL PROTECTED]

*Sent:* Monday, November 24, 2003 2:10 PM
*Subject:* RE: [nant-dev] In case you haven't seen this yet
As the MSBuild PM, do you know if the team has considered any
interop scenarios with NAnt tasks or the NAnt framework. Is this
something that would be in the scope of the work you would consider?
If not, can you comment on the technical challenges in doing in
working either way (nant->msbuild; msbuild->nant, task interop)?
>> Great question.  This is totally in the scope of the work we are
considering.  I believe very strongly that we will need
nant<>msbuild interop.  In my mind this work segments into four
nice manageable chunks:
 

· An MSBuild task needs to exist in the NAnt
library.  This way you can build MSBuild projects from within NAnt
projects
· A NAnt task needs to exist in the MSBuild
library.  This way you can build NAnt projects from within MSBuild
projects
· A file format conversion tool (ala xslt) which
will convert b

[nant-dev] Re: In case you haven't seen this yet

[Stefan Bodewig]

On Tue, 18 Nov 2003, Alex Kipman <[EMAIL PROTECTED]> wrote:

> You will note Brent re-wrote the entire section about "Why not
> Ant/NAnt", and what you see on this link is what you will see
> printed on the book when it hits your local bookstore.

Thanks Alex, both for the pointer and for the nudging into the right
direction you've done.

Stefan

-- 
http://stefanbodewig.blogger.de/


---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers