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 <mailto:[EMAIL PROTECTED]> *To:* Scott Hernandez <mailto:[EMAIL PROTECTED]> ; [EMAIL PROTECTED] <mailto:[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 areconsidering. 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 both syntaxes back and forth.
� Being able to author a task such that it will
run on either NAnt or MSBuild.
That's at least how we have been breaking up the problem.
Thanks,
Alex Kipman ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
Program Manager
Visual Studio Core Team
This posting is provided "AS IS" with no warranties, and confers no rights.
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Scott Hernandez *Sent:* Wednesday, November 19, 2003 10:23 AM *To:* [EMAIL PROTECTED] *Subject:* Re: [nant-dev] In case you haven't seen this yet
Thanks for the update Alex. I didn't read the original article, but this seems like a pretty short synopsis. I'm looking forward to seeing msbuild when it gets closer to release.
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)?
----- Original Message -----
*From:* Alex Kipman <mailto:[EMAIL PROTECTED]>
*To:* [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
*Sent:* Tuesday, November 18, 2003 9:24 PM
*Subject:* [nant-dev] In case you haven't seen this yet
Hello everyone,
At the risk of reliving a very painful subject, I wanted to point the community to the published "chapter 2" of Brent Rectors book entitled Introducing Longhorn for Developers. The link is here:
http://msdn.microsoft.com/Longhorn/understanding/books/rector/default.aspx?pull=/library/en-us/dnintlong/html/longhornch02.asp#longhornch02_topic1
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. In other
words what was printed in the PDC copy of the book will no
longer be printed. I hope you find the current text to be more
precise and especially less adversarial.
Just thought you should know,
Alex Kipman ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
Program Manager
MSBuild Team
This posting is provided "AS IS" with no warranties, and confers no rights.
------------------------------------------------------- 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
