Re: VmWare SDK to vijava
Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL-180 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL-180 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
#1 would still need licensing sorted - explicitly it would need to be a Cat A or Cat B license. https://www.apache.org/legal/3party.html #2 or similar would work I think (though I'd imagine they'd choose MIT or BSD if going that route) #3 A statement that they don't consider the WSDL copyrightable (I can't imagine they'd go for that, but who knows, makes sense technically and Feist v Rural seems to suggest that 'information' or even 'collection of information' isn't copyrightable without an element of creativity. WSDL by it's nature is a description; and the phonebook analogy plays well there. http://en.wikipedia.org/wiki/Feist_v._Rural --David On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL-180 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
I'd say option 1 is the easiest to digest. On that note, are we gaining anything (legal-wise) by switching to vijava? I just uncompressed the download[1]. It bundles the compiled classes found in vim25.jar which is (presumably) VMWare proprietary. [1] http://vijava.sourceforge.net/ On 2/18/14 11:10 AM, David Nalley da...@gnsa.us wrote: #1 would still need licensing sorted - explicitly it would need to be a Cat A or Cat B license. https://www.apache.org/legal/3party.html #2 or similar would work I think (though I'd imagine they'd choose MIT or BSD if going that route) #3 A statement that they don't consider the WSDL copyrightable (I can't imagine they'd go for that, but who knows, makes sense technically and Feist v Rural seems to suggest that 'information' or even 'collection of information' isn't copyrightable without an element of creativity. WSDL by it's nature is a description; and the phonebook analogy plays well there. http://en.wikipedia.org/wiki/Feist_v._Rural --David On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL-180 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
Option 1 still needs licensing sorted. Being on a maven repo still doesn't fix the problem for us and our users. WRT to vijava the classes in source all appear to have a copyright header indicating that Steve is the author and licensed under BSD. In example: http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim25/AgentInstallFailed.java --David On Tue, Feb 18, 2014 at 2:47 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I'd say option 1 is the easiest to digest. On that note, are we gaining anything (legal-wise) by switching to vijava? I just uncompressed the download[1]. It bundles the compiled classes found in vim25.jar which is (presumably) VMWare proprietary. [1] http://vijava.sourceforge.net/ On 2/18/14 11:10 AM, David Nalley da...@gnsa.us wrote: #1 would still need licensing sorted - explicitly it would need to be a Cat A or Cat B license. https://www.apache.org/legal/3party.html #2 or similar would work I think (though I'd imagine they'd choose MIT or BSD if going that route) #3 A statement that they don't consider the WSDL copyrightable (I can't imagine they'd go for that, but who knows, makes sense technically and Feist v Rural seems to suggest that 'information' or even 'collection of information' isn't copyrightable without an element of creativity. WSDL by it's nature is a description; and the phonebook analogy plays well there. http://en.wikipedia.org/wiki/Feist_v._Rural --David On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL-180 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a
Re: VmWare SDK to vijava
Not all. http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim25/mo /Alarm.java On 2/18/14 12:05 PM, David Nalley da...@gnsa.us wrote: Option 1 still needs licensing sorted. Being on a maven repo still doesn't fix the problem for us and our users. WRT to vijava the classes in source all appear to have a copyright header indicating that Steve is the author and licensed under BSD. In example: http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim25/A gentInstallFailed.java --David On Tue, Feb 18, 2014 at 2:47 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I'd say option 1 is the easiest to digest. On that note, are we gaining anything (legal-wise) by switching to vijava? I just uncompressed the download[1]. It bundles the compiled classes found in vim25.jar which is (presumably) VMWare proprietary. [1] http://vijava.sourceforge.net/ On 2/18/14 11:10 AM, David Nalley da...@gnsa.us wrote: #1 would still need licensing sorted - explicitly it would need to be a Cat A or Cat B license. https://www.apache.org/legal/3party.html #2 or similar would work I think (though I'd imagine they'd choose MIT or BSD if going that route) #3 A statement that they don't consider the WSDL copyrightable (I can't imagine they'd go for that, but who knows, makes sense technically and Feist v Rural seems to suggest that 'information' or even 'collection of information' isn't copyrightable without an element of creativity. WSDL by it's nature is a description; and the phonebook analogy plays well there. http://en.wikipedia.org/wiki/Feist_v._Rural --David On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL-18 0 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that
Re: VmWare SDK to vijava
That's still licensed as BSD (the license header is in the file) --David On Tue, Feb 18, 2014 at 3:54 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Not all. http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim25/mo /Alarm.java On 2/18/14 12:05 PM, David Nalley da...@gnsa.us wrote: Option 1 still needs licensing sorted. Being on a maven repo still doesn't fix the problem for us and our users. WRT to vijava the classes in source all appear to have a copyright header indicating that Steve is the author and licensed under BSD. In example: http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim25/A gentInstallFailed.java --David On Tue, Feb 18, 2014 at 2:47 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I'd say option 1 is the easiest to digest. On that note, are we gaining anything (legal-wise) by switching to vijava? I just uncompressed the download[1]. It bundles the compiled classes found in vim25.jar which is (presumably) VMWare proprietary. [1] http://vijava.sourceforge.net/ On 2/18/14 11:10 AM, David Nalley da...@gnsa.us wrote: #1 would still need licensing sorted - explicitly it would need to be a Cat A or Cat B license. https://www.apache.org/legal/3party.html #2 or similar would work I think (though I'd imagine they'd choose MIT or BSD if going that route) #3 A statement that they don't consider the WSDL copyrightable (I can't imagine they'd go for that, but who knows, makes sense technically and Feist v Rural seems to suggest that 'information' or even 'collection of information' isn't copyrightable without an element of creativity. WSDL by it's nature is a description; and the phonebook analogy plays well there. http://en.wikipedia.org/wiki/Feist_v._Rural --David On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL-18 0 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to
Re: VmWare SDK to vijava
If vim25.jar source is BSD then why are we including it in noredist? mvn install:install-file -Dfile=vim25_51.jar -DgroupId=com.cloud.com.vmware -DartifactId=vmware-vim25-Dversion=5.1 -Dpackaging=jar On 2/18/14 1:51 PM, David Nalley da...@gnsa.us wrote: That's still licensed as BSD (the license header is in the file) --David On Tue, Feb 18, 2014 at 3:54 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Not all. http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim25/ mo /Alarm.java On 2/18/14 12:05 PM, David Nalley da...@gnsa.us wrote: Option 1 still needs licensing sorted. Being on a maven repo still doesn't fix the problem for us and our users. WRT to vijava the classes in source all appear to have a copyright header indicating that Steve is the author and licensed under BSD. In example: http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim25 /A gentInstallFailed.java --David On Tue, Feb 18, 2014 at 2:47 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I'd say option 1 is the easiest to digest. On that note, are we gaining anything (legal-wise) by switching to vijava? I just uncompressed the download[1]. It bundles the compiled classes found in vim25.jar which is (presumably) VMWare proprietary. [1] http://vijava.sourceforge.net/ On 2/18/14 11:10 AM, David Nalley da...@gnsa.us wrote: #1 would still need licensing sorted - explicitly it would need to be a Cat A or Cat B license. https://www.apache.org/legal/3party.html #2 or similar would work I think (though I'd imagine they'd choose MIT or BSD if going that route) #3 A statement that they don't consider the WSDL copyrightable (I can't imagine they'd go for that, but who knows, makes sense technically and Feist v Rural seems to suggest that 'information' or even 'collection of information' isn't copyrightable without an element of creativity. WSDL by it's nature is a description; and the phonebook analogy plays well there. http://en.wikipedia.org/wiki/Feist_v._Rural --David On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL- 18 0 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and
Re: VmWare SDK to vijava
The reason why it ended up at noredist build is that the binary jars are copied from VMware SDK, we are not sure about the license implication and we don’t build it from source. In VMware 5.1 SDK, vim25.jar is generated from importing WSDL plus a fix-up, the fix-up step is performed by a tool named FixJaxWsWsdlResource. I disassembled the tool and found that it merely replaces VimService.class resource search path before it compiles WSDL generated java files. So technically, if there is not any license concerns, we can put all these into our build scripts, but before I go ahead to do that, someone has to clear the legal concern of following steps 1) include vim25.wsdl into CloudStack source code distribution 2) Include a fixup tool, not sure we can directly take it from VMware’s SDK or is it a problem to rewrite it by us from license point of view. 3) Build script to produce a vim25.jar from CloudStack Kelven On 2/18/14, 2:07 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: If vim25.jar source is BSD then why are we including it in noredist? mvn install:install-file -Dfile=vim25_51.jar -DgroupId=com.cloud.com.vmware -DartifactId=vmware-vim25-Dversion=5.1 -Dpackaging=jar On 2/18/14 1:51 PM, David Nalley da...@gnsa.us wrote: That's still licensed as BSD (the license header is in the file) --David On Tue, Feb 18, 2014 at 3:54 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Not all. http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim25 / mo /Alarm.java On 2/18/14 12:05 PM, David Nalley da...@gnsa.us wrote: Option 1 still needs licensing sorted. Being on a maven repo still doesn't fix the problem for us and our users. WRT to vijava the classes in source all appear to have a copyright header indicating that Steve is the author and licensed under BSD. In example: http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim2 5 /A gentInstallFailed.java --David On Tue, Feb 18, 2014 at 2:47 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I'd say option 1 is the easiest to digest. On that note, are we gaining anything (legal-wise) by switching to vijava? I just uncompressed the download[1]. It bundles the compiled classes found in vim25.jar which is (presumably) VMWare proprietary. [1] http://vijava.sourceforge.net/ On 2/18/14 11:10 AM, David Nalley da...@gnsa.us wrote: #1 would still need licensing sorted - explicitly it would need to be a Cat A or Cat B license. https://www.apache.org/legal/3party.html #2 or similar would work I think (though I'd imagine they'd choose MIT or BSD if going that route) #3 A statement that they don't consider the WSDL copyrightable (I can't imagine they'd go for that, but who knows, makes sense technically and Feist v Rural seems to suggest that 'information' or even 'collection of information' isn't copyrightable without an element of creativity. WSDL by it's nature is a description; and the phonebook analogy plays well there. http://en.wikipedia.org/wiki/Feist_v._Rural --David On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL - 18 0 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub
Re: VmWare SDK to vijava
Why do we need the WSDL at all? Why can't we check in vim25 sources like the vijava project has done? On 2/18/14 2:42 PM, Kelven Yang kelven.y...@citrix.com wrote: The reason why it ended up at noredist build is that the binary jars are copied from VMware SDK, we are not sure about the license implication and we don’t build it from source. In VMware 5.1 SDK, vim25.jar is generated from importing WSDL plus a fix-up, the fix-up step is performed by a tool named FixJaxWsWsdlResource. I disassembled the tool and found that it merely replaces VimService.class resource search path before it compiles WSDL generated java files. So technically, if there is not any license concerns, we can put all these into our build scripts, but before I go ahead to do that, someone has to clear the legal concern of following steps 1) include vim25.wsdl into CloudStack source code distribution 2) Include a fixup tool, not sure we can directly take it from VMware’s SDK or is it a problem to rewrite it by us from license point of view. 3) Build script to produce a vim25.jar from CloudStack Kelven On 2/18/14, 2:07 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: If vim25.jar source is BSD then why are we including it in noredist? mvn install:install-file -Dfile=vim25_51.jar -DgroupId=com.cloud.com.vmware -DartifactId=vmware-vim25-Dversion=5.1 -Dpackaging=jar On 2/18/14 1:51 PM, David Nalley da...@gnsa.us wrote: That's still licensed as BSD (the license header is in the file) --David On Tue, Feb 18, 2014 at 3:54 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Not all. http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim2 5 / mo /Alarm.java On 2/18/14 12:05 PM, David Nalley da...@gnsa.us wrote: Option 1 still needs licensing sorted. Being on a maven repo still doesn't fix the problem for us and our users. WRT to vijava the classes in source all appear to have a copyright header indicating that Steve is the author and licensed under BSD. In example: http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim 2 5 /A gentInstallFailed.java --David On Tue, Feb 18, 2014 at 2:47 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I'd say option 1 is the easiest to digest. On that note, are we gaining anything (legal-wise) by switching to vijava? I just uncompressed the download[1]. It bundles the compiled classes found in vim25.jar which is (presumably) VMWare proprietary. [1] http://vijava.sourceforge.net/ On 2/18/14 11:10 AM, David Nalley da...@gnsa.us wrote: #1 would still need licensing sorted - explicitly it would need to be a Cat A or Cat B license. https://www.apache.org/legal/3party.html #2 or similar would work I think (though I'd imagine they'd choose MIT or BSD if going that route) #3 A statement that they don't consider the WSDL copyrightable (I can't imagine they'd go for that, but who knows, makes sense technically and Feist v Rural seems to suggest that 'information' or even 'collection of information' isn't copyrightable without an element of creativity. WSDL by it's nature is a description; and the phonebook analogy plays well there. http://en.wikipedia.org/wiki/Feist_v._Rural --David On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGA L - 18 0 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP
Re: VmWare SDK to vijava
Where do we get the source code of vim25.jar the first place? VMware only releases WSDL but not the java source, we can either copy it from vijava or generate it ourselves to put it into our source repo, but if we do generate, it would be easier to maintain the code base if this generation step is also automatic and in our build scripts. I’m also fine to just put the source code into CloudStack if we can always get it from somewhere without a license issue Kelven On 2/18/14, 2:43 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Why do we need the WSDL at all? Why can't we check in vim25 sources like the vijava project has done? On 2/18/14 2:42 PM, Kelven Yang kelven.y...@citrix.com wrote: The reason why it ended up at noredist build is that the binary jars are copied from VMware SDK, we are not sure about the license implication and we don’t build it from source. In VMware 5.1 SDK, vim25.jar is generated from importing WSDL plus a fix-up, the fix-up step is performed by a tool named FixJaxWsWsdlResource. I disassembled the tool and found that it merely replaces VimService.class resource search path before it compiles WSDL generated java files. So technically, if there is not any license concerns, we can put all these into our build scripts, but before I go ahead to do that, someone has to clear the legal concern of following steps 1) include vim25.wsdl into CloudStack source code distribution 2) Include a fixup tool, not sure we can directly take it from VMware’s SDK or is it a problem to rewrite it by us from license point of view. 3) Build script to produce a vim25.jar from CloudStack Kelven On 2/18/14, 2:07 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: If vim25.jar source is BSD then why are we including it in noredist? mvn install:install-file -Dfile=vim25_51.jar -DgroupId=com.cloud.com.vmware -DartifactId=vmware-vim25 -Dversion=5.1 -Dpackaging=jar On 2/18/14 1:51 PM, David Nalley da...@gnsa.us wrote: That's still licensed as BSD (the license header is in the file) --David On Tue, Feb 18, 2014 at 3:54 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Not all. http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim 2 5 / mo /Alarm.java On 2/18/14 12:05 PM, David Nalley da...@gnsa.us wrote: Option 1 still needs licensing sorted. Being on a maven repo still doesn't fix the problem for us and our users. WRT to vijava the classes in source all appear to have a copyright header indicating that Steve is the author and licensed under BSD. In example: http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vi m 2 5 /A gentInstallFailed.java --David On Tue, Feb 18, 2014 at 2:47 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I'd say option 1 is the easiest to digest. On that note, are we gaining anything (legal-wise) by switching to vijava? I just uncompressed the download[1]. It bundles the compiled classes found in vim25.jar which is (presumably) VMWare proprietary. [1] http://vijava.sourceforge.net/ On 2/18/14 11:10 AM, David Nalley da...@gnsa.us wrote: #1 would still need licensing sorted - explicitly it would need to be a Cat A or Cat B license. https://www.apache.org/legal/3party.html #2 or similar would work I think (though I'd imagine they'd choose MIT or BSD if going that route) #3 A statement that they don't consider the WSDL copyrightable (I can't imagine they'd go for that, but who knows, makes sense technically and Feist v Rural seems to suggest that 'information' or even 'collection of information' isn't copyrightable without an element of creativity. WSDL by it's nature is a description; and the phonebook analogy plays well there. http://en.wikipedia.org/wiki/Feist_v._Rural --David On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEG A L - 18 0 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file
Re: VmWare SDK to vijava
We don't know that it is. We know the vim25.jar is distributed to us from the vmware SDK with different licensing. On Tue, Feb 18, 2014 at 5:07 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: If vim25.jar source is BSD then why are we including it in noredist? mvn install:install-file -Dfile=vim25_51.jar -DgroupId=com.cloud.com.vmware -DartifactId=vmware-vim25-Dversion=5.1 -Dpackaging=jar On 2/18/14 1:51 PM, David Nalley da...@gnsa.us wrote: That's still licensed as BSD (the license header is in the file) --David On Tue, Feb 18, 2014 at 3:54 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Not all. http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim25/ mo /Alarm.java On 2/18/14 12:05 PM, David Nalley da...@gnsa.us wrote: Option 1 still needs licensing sorted. Being on a maven repo still doesn't fix the problem for us and our users. WRT to vijava the classes in source all appear to have a copyright header indicating that Steve is the author and licensed under BSD. In example: http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim25 /A gentInstallFailed.java --David On Tue, Feb 18, 2014 at 2:47 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I'd say option 1 is the easiest to digest. On that note, are we gaining anything (legal-wise) by switching to vijava? I just uncompressed the download[1]. It bundles the compiled classes found in vim25.jar which is (presumably) VMWare proprietary. [1] http://vijava.sourceforge.net/ On 2/18/14 11:10 AM, David Nalley da...@gnsa.us wrote: #1 would still need licensing sorted - explicitly it would need to be a Cat A or Cat B license. https://www.apache.org/legal/3party.html #2 or similar would work I think (though I'd imagine they'd choose MIT or BSD if going that route) #3 A statement that they don't consider the WSDL copyrightable (I can't imagine they'd go for that, but who knows, makes sense technically and Feist v Rural seems to suggest that 'information' or even 'collection of information' isn't copyrightable without an element of creativity. WSDL by it's nature is a description; and the phonebook analogy plays well there. http://en.wikipedia.org/wiki/Feist_v._Rural --David On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL- 18 0 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan.
Re: VmWare SDK to vijava
On 2/18/14, 2:43 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Why do we need the WSDL at all? Why can't we check in vim25 sources like the vijava project has done? We don’t have the vim25 source directly, further investigation showed that vijava actually uses a different Web service engine, even if we copy all the vim25 source files from vijava, it will still be missing an important file called VimService.java. Further investigation showed that, the strange VMware fixup tool does nothing at all, it has misled us to believe that we can’t use directly generated vim25.jar, this is not true any more. The conclusion is that we can use wsimport tool from JDK to directly generate vim25.jar from WSDL and use it. Kelven On 2/18/14 2:42 PM, Kelven Yang kelven.y...@citrix.com wrote: The reason why it ended up at noredist build is that the binary jars are copied from VMware SDK, we are not sure about the license implication and we don’t build it from source. In VMware 5.1 SDK, vim25.jar is generated from importing WSDL plus a fix-up, the fix-up step is performed by a tool named FixJaxWsWsdlResource. I disassembled the tool and found that it merely replaces VimService.class resource search path before it compiles WSDL generated java files. So technically, if there is not any license concerns, we can put all these into our build scripts, but before I go ahead to do that, someone has to clear the legal concern of following steps 1) include vim25.wsdl into CloudStack source code distribution 2) Include a fixup tool, not sure we can directly take it from VMware’s SDK or is it a problem to rewrite it by us from license point of view. 3) Build script to produce a vim25.jar from CloudStack Kelven On 2/18/14, 2:07 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: If vim25.jar source is BSD then why are we including it in noredist? mvn install:install-file -Dfile=vim25_51.jar -DgroupId=com.cloud.com.vmware -DartifactId=vmware-vim25 -Dversion=5.1 -Dpackaging=jar On 2/18/14 1:51 PM, David Nalley da...@gnsa.us wrote: That's still licensed as BSD (the license header is in the file) --David On Tue, Feb 18, 2014 at 3:54 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Not all. http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim 2 5 / mo /Alarm.java On 2/18/14 12:05 PM, David Nalley da...@gnsa.us wrote: Option 1 still needs licensing sorted. Being on a maven repo still doesn't fix the problem for us and our users. WRT to vijava the classes in source all appear to have a copyright header indicating that Steve is the author and licensed under BSD. In example: http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vi m 2 5 /A gentInstallFailed.java --David On Tue, Feb 18, 2014 at 2:47 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I'd say option 1 is the easiest to digest. On that note, are we gaining anything (legal-wise) by switching to vijava? I just uncompressed the download[1]. It bundles the compiled classes found in vim25.jar which is (presumably) VMWare proprietary. [1] http://vijava.sourceforge.net/ On 2/18/14 11:10 AM, David Nalley da...@gnsa.us wrote: #1 would still need licensing sorted - explicitly it would need to be a Cat A or Cat B license. https://www.apache.org/legal/3party.html #2 or similar would work I think (though I'd imagine they'd choose MIT or BSD if going that route) #3 A statement that they don't consider the WSDL copyrightable (I can't imagine they'd go for that, but who knows, makes sense technically and Feist v Rural seems to suggest that 'information' or even 'collection of information' isn't copyrightable without an element of creativity. WSDL by it's nature is a description; and the phonebook analogy plays well there. http://en.wikipedia.org/wiki/Feist_v._Rural --David On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I just pinged the attorney again (there is a live one assigned to this question on the VMWare side). What options will work? If we can provide some concrete options, perhaps they will pick 1. Provide generated SDK jars in maven repo 2. Explicitly add ASL to WSDL 3. ? -- Chiradeep On 2/18/14 7:14 AM, Hugo Trippaers h...@trippaers.nl wrote: Chiradeep, Whats the progress on this? Cheers, Hugo On 22 jan. 2014, at 23:35, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEG A L - 18 0 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote:
Re: VmWare SDK to vijava
Reached out to @strikesme and @danwendlandt On 1/21/14 10:14 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL-180 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
Heya, Does anyone know about the current status the legal discussions around including the WSDL or code generated by parsing the WSDL? I would really like to have the vmware support in the normal build instead of just in the noredist build. It would probably boost adoption amongst people using vmware. I’m at a point where i’m about to just commit a change to use vijava so we can do it. I’d rather revert that change later when the legal issues are sorted then wait another release before we have vmware support in the normal build. We already missed the 4.3 release, let’s make sure its fixed in 4.4. Cheers, Hugo On 4 okt. 2013, at 19:04, Darren Shepherd darren.s.sheph...@gmail.com wrote: I created https://issues.apache.org/jira/browse/LEGAL-180 for this. Darren
Re: VmWare SDK to vijava
I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. On Tue, Jan 21, 2014 at 3:40 AM, Hugo Trippaers h...@trippaers.nl wrote: Heya, Does anyone know about the current status the legal discussions around including the WSDL or code generated by parsing the WSDL? I would really like to have the vmware support in the normal build instead of just in the noredist build. It would probably boost adoption amongst people using vmware. I’m at a point where i’m about to just commit a change to use vijava so we can do it. I’d rather revert that change later when the legal issues are sorted then wait another release before we have vmware support in the normal build. We already missed the 4.3 release, let’s make sure its fixed in 4.4. Cheers, Hugo On 4 okt. 2013, at 19:04, Darren Shepherd darren.s.sheph...@gmail.com wrote: I created https://issues.apache.org/jira/browse/LEGAL-180 for this. Darren
Re: VmWare SDK to vijava
On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
Hugo, I think we seems to come to a census that to use WSDL to generate the java stub which is pretty much compatible to what we have right now. Kelven On 1/21/14, 12:40 AM, Hugo Trippaers h...@trippaers.nl wrote: Heya, Does anyone know about the current status the legal discussions around including the WSDL or code generated by parsing the WSDL? I would really like to have the vmware support in the normal build instead of just in the noredist build. It would probably boost adoption amongst people using vmware. I¹m at a point where i¹m about to just commit a change to use vijava so we can do it. I¹d rather revert that change later when the legal issues are sorted then wait another release before we have vmware support in the normal build. We already missed the 4.3 release, let¹s make sure its fixed in 4.4. Cheers, Hugo On 4 okt. 2013, at 19:04, Darren Shepherd darren.s.sheph...@gmail.com wrote: I created https://issues.apache.org/jira/browse/LEGAL-180 for this. Darren
Re: VmWare SDK to vijava
Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
Let's not repeat the previous discussion. We allready agreed that the wsdl is the way forward. However we can't get any legal entity to say that it is ok to do so. Hence my proposal to at least move forward even if it means to temporarily use vijava. I really don't care what we do, as long as we have VMware in the regular build before the 4.4 feature freeze. If anyone of you is willing to chase VMware legal on this, please have a go at it. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
We are now again at the exact same point as where Darren was. This is the legal ticket relevant to the license discussion: https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEGAL-180 Either we get an ok from legal or we need to find an alternative. Kelven, Chiradeep, are you guys going to chase this ticket? Hugo Sent from my iPhone On 22 jan. 2014, at 07:04, Hugo Trippaers trip...@gmail.com wrote: Kelven, Chiradeep, What license governs the redistribution, what do we include in our notice file and is that license compatible with the ASF license policy? Hugo Sent from my iPhone On 22 jan. 2014, at 00:44, Kelven Yang kelven.y...@citrix.com wrote: Q. Can I redistribute the VI SDK libraries and sample code? A. You can redistribute only those parts of the SDK package that have been designated as ³distributable code². In VI SDK 2.5, the following components can be redistributed: vim.jar, vim25.jar. To note developers typically generate web service stubs from the WSDL file that is included in the VI SDK using a SOAP toolkit. The stubs source and the compiled stubs can also be distributed. Could this solve our license problem, we discussed before that generating our own java stub can give us flexibility to support co-existence of different versions of VMware web service API inside CloudStack. If we see this as urgency, we need to have someone work on to put WSDL generation process to maven build For latest names of VI SDK libraries that can be redistributed visit http://vmware.com/go/sdk-redistribution-info On 1/21/14, 3:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Apparently we can https://communities.vmware.com/docs/DOC-7983 http://markmail.org/thread/ttamcfb4d6azzbw7 On 1/21/14 2:46 PM, Hugo Trippaers trip...@gmail.com wrote: Chiradeep, Even on the generated sources nobody seems willing to state that it is ok to include them at the moment. Otherwise I would have put them in already. Hugo Sent from my iPhone On 21 jan. 2014, at 19:32, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Suboptimal for? Wouldn't the ACS user want the best / supported client libraries? Alternatively, can't we just compile the WSDL and check in the generated sources? Not check-in the WSDL, but the client sources. On 1/21/14 7:18 AM, David Nalley da...@gnsa.us wrote: On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers chipchild...@apache.org wrote: I bet we never got an answer. Frankly, I'd like to see us use something where the licensing is clear. That, or we don't include the WSDL in our repo / distro. Additionally, we are an open source project that is in the business of producing open source software. Depending on non-free and non-opensource libraries is suboptimal, but its worse when there is a open source alternative. --David
Re: VmWare SDK to vijava
I created https://issues.apache.org/jira/browse/LEGAL-180 for this. Darren
Re: VmWare SDK to vijava
Darren, Any update on the vmware patch? Did you get the patch tested already? Would be nice to get this in for the next release. Cheers, Hugo On Sep 26, 2013, at 6:23 AM, David Nalley da...@gnsa.us wrote: On Tue, Sep 24, 2013 at 8:01 PM, Alex Huang alex.hu...@citrix.com wrote: Wow good guess...Hugo had me scratching my head on that oneIs Prussian some code name for Apache legalShould I askWould it make me look stupid if I askedall sorts of doubts going through my mind. --Alex I think Prasanna just earned a new nickname thanks to autocorrect. :) --David
Re: VmWare SDK to vijava
No update on this. I mentally got blocked on the emailing legal@ about it. Should I go ahead and email them? Whats the full email address? From a technical perspective I know this will work, I did some bytecode analysis and we can produce basically the exact same thing as what's in the jar today. So its just a legal question in my mind. So I didn't want to waste anybodies time if legal is going to say no. Darren On Wed, Oct 2, 2013 at 2:27 AM, Hugo Trippaers h...@trippaers.nl wrote: Darren, Any update on the vmware patch? Did you get the patch tested already? Would be nice to get this in for the next release. Cheers, Hugo On Sep 26, 2013, at 6:23 AM, David Nalley da...@gnsa.us wrote: On Tue, Sep 24, 2013 at 8:01 PM, Alex Huang alex.hu...@citrix.com wrote: Wow good guess...Hugo had me scratching my head on that oneIs Prussian some code name for Apache legalShould I askWould it make me look stupid if I askedall sorts of doubts going through my mind. --Alex I think Prasanna just earned a new nickname thanks to autocorrect. :) --David
Re: VmWare SDK to vijava
On Wed, Oct 2, 2013 at 4:23 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: No update on this. I mentally got blocked on the emailing legal@ about it. Should I go ahead and email them? Whats the full email address? From a technical perspective I know this will work, I did some bytecode analysis and we can produce basically the exact same thing as what's in the jar today. So its just a legal question in my mind. So I didn't want to waste anybodies time if legal is going to say no. Legal has in the past said it depends - so we won't know til you ask. Anytime resources are referenced as $something@ here at the ASF - you can generally assume postpending apache.org to that will get you to the right place. Except in this case legal-disc...@apache.org is the list you want, and you probably want to actually file a Jira ticket for it, so Sam and others will see the constant tickler. You may want to look at https://issues.apache.org/jira/browse/LEGAL-137 which is another WSDL-related issue.
Re: VmWare SDK to vijava
On Tue, Sep 24, 2013 at 8:01 PM, Alex Huang alex.hu...@citrix.com wrote: Wow good guess...Hugo had me scratching my head on that oneIs Prussian some code name for Apache legalShould I askWould it make me look stupid if I askedall sorts of doubts going through my mind. --Alex I think Prasanna just earned a new nickname thanks to autocorrect. :) --David
Re: VmWare SDK to vijava
, 2013, at 11:43 PM, Hugo Trippaers h...@trippaers.nl wrote: On Sep 23, 2013, at 1:39 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Yeah, I'll dig into it more. I think I understand a bit that vmware api is just a bunch of generics objects, so another library on top to create types on top of it helps. So I'll look at it more. In the end I'm still going to probably have reservations about 1) a custom XML/soap framework 2) a third party maintained later between us and vmware (sorta like libvirt-java always behind and incomplete with native libvirt). So it just depends on if the nicer api is worth the risk of the other things. I don't think vmwares api changes much, and you can always get to the generic objects so maybe my concerns are moot. Thanks, i could actually use a second pair of eyes if we want to get this into master. It would be nice to have a few people test this. I don't really share the concern on the XML/soap framework one is a good or bad as the other usually, i've seen interesting things with the axes framework as well. But thats besides the point for now. My main objective now it to get vijava working with as little changes as possible. Later we can do some refactoring and see if vijava really benefits us as much as i think/hope it will do. Your second concern is one i share, we will have to see how it goes. Vmware doesn't really change its api that often and if it does we are generally not the early adopters of new versions of libraries. So for now we should be ok. Hopefully we will get the vmware stuff in the redistributable build which is the primary objective here. All benefits are nice to have for future developments. Cheers, Hugo Darren On Sep 22, 2013, at 10:14 PM, Hugo Trippaers h...@trippaers.nl wrote: On Sep 23, 2013, at 1:01 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Oh, I thought the primary motivation was just to get to fully open source and out of noredist. I don't know enough about VMware and vijava so my comments may be off base (everything I know about vmware client is based off about 2 hours of googling), but my gut reaction is that its better to stick with mainstream than use vijava. I understand the VMware wsdl is a complicated and weird API. But the fact that you could drop vijava in real quick and it mostly matches the existing illustrates that its not a big departure from from the vmware bindings so doesn't seem to make consuming it much easier. It seems that vijava was better than vmware sdk 2.5 because you didn't need Apache Axis. But vSphere 5.1 sdk is based off of JAXWS and thus doesn't need axis anymore. If I'm going to put my trust in something at runtime I'd rather use the sun/oracle jaxws or apache CXF and not some custom xml/soap framework one guy wrote. The drop in real quick bit is just for starters. Some of the enums have changes names and instead of lists vijava uses arrays. Those items are pretty quick to adapt. The real interesting things are in the serviceInstance etc. That's where there are some changes. A nice example is on the vijava website where 100 lines of regular vmware sdk is replaced by 20-something lines of vijava. I'd say dig a bit deeper and i could use the help with the conversion process. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other
RE: VmWare SDK to vijava
Agree. Given current CloudStack code base changing something to another thing is really not a good way. As Darren is working on modular spring, why not construct a new VMWare plugin separately using vijava? Then we can reduce the risk of surprising existing customer and switch to new module when it finally gets mature. -Original Message- From: Kelven Yang [mailto:kelven.y...@citrix.com] Sent: Tuesday, September 24, 2013 11:59 AM To: dev@cloudstack.apache.org Subject: Re: VmWare SDK to vijava We have commercial releases on top of existing code base and there are lots of testing efforts behind it, dramatic switch means $ cost, the major concern for me is not about how beautiful vijava is or how bad a direct wsdl approach would be. it is about to get things move smoothly. It looks like that we should have VMware layer on its own to have a plugin structure so that we can replace underlying binding easier, it should solve the balance between developer's motivation and carrying on the legacy with minimal impacts to the rest of others. Kelven On 9/23/13 6:01 PM, Hugo Trippaers h...@trippaers.nl wrote: Heya, This biggest advantage i see in using vijava is that a lot of the functionality that we now have in the vmware-base project is already supplied with vijava. There is a lot of code that facilitates calling tasks and other stuff in our MO classes. These classes are available in vijava and could be used instead of our classes. Basically when using vijava correctly you hardly have to work with the ManagedObjectReferences anymore. For me this would be a big benefit as it makes programming against vmware a lot easier. We also have a lot of duplicate code currently in the vmware class and i wouldn't mind getting rid of it, which i think is easier with the vijava libraries. That said, the main driver is getting it into the main build so any other efforts towards that goal are ok with me. I would propose that somebody else puts up a branch with our own wdsl wrapper and we open a discussion thread when both branches are ready to see which we want to merge in master. Anybody who wants to pick that up? I'm stubbornly going to continue with converting to vijava, I put some effort into it and i want at least to see it running once ;-) And the more i work with it the more i'm seeing to benefits of the library so i might be able to be more convincing in the end :-) Cheers, Hugo On Sep 24, 2013, at 2:18 AM, Kelven Yang kelven.y...@citrix.com wrote: Prior to 5.1, VMware provides java binding in its SDK and this is where CloudStack VMware integration began with. Starting from 5.1, VMware no longer provides the java binding in binary form and recommends its customers to generate directly from its WS WSDL. Since we are not sure if we can distribute VMware wsdl legally or not, therefore, we ended up to generate and distribute the java binding in binary form. If we can get this cleared in lebal, as Darren pointed, we can solve our non-dist issue easily in matter of adding couple of lines in maven. As of vijava, yes, I think it may add some value from developer's point of view, but on the other hand, I don't see immediate benefits to having another layer on top of VMware official WS API, vijava is an open source project for providing convenient java binding to vmware WS API, maybe I'm wrong, but I think VMware vSphere WS API is the only official published API from VMware, and the testing result of the API is endorsed by VMware as an commercial entity. So I see more business value to stick with the official WS API directly. If we can clear the legal concern of redistributing VMware wsdl. I would +1 to add a build step of generating VMware java binding from wsdl. Kelven On 9/23/13 12:40 AM, Hugo Trippaers h...@trippaers.nl wrote: We have been having this discussion on moving vmware out of noredist since i joined the project. So no real need to rush this suddenly. Still it would be nice to get this in for the next release. The feature freeze of 4.3 is october 31st for the 4.3 release. This change (or any sdk change to vmware) should be considered an architecture change so it should come in at the start of the new release cycle. So this is currently my main activity on CloudStack meaning i can work pretty much dedicated on this. With a bit of luck i can have the changes finished this week. Then it's up to the test results if we can make it into the 4.3 release or the 4.4 release. Of course all pending a successful merge vote. Cheers, Hugo On Sep 23, 2013, at 3:10 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: It's seems there could be some good merit to adopting vijava. I hate to belabor this point, but we could get vmware plugin out of noredist real fast if we just generate bindings (I think) Do you know if legally we can add the vmware
Re: VmWare SDK to vijava
It is about the interface layer between CloudStack and VMware, Spring can only help to what it can, ultimately, we need to refactor the interface layer to take in vijava as one of its implementations. We also need to consider of another situation, with the latest vSphere 5.1 API, although VMware claims to support all previous vSphere versions with it, we actually found that this is not true. We may have to face the fact that we will need to support two versions of vSphere APIs at run time side-by-side. I'm leaning towards for us to to have some control in generating the API stub for this(the direct WSDL way), if it is to vijava, it depends on whether or not it has built-in side-by-side VMware API support. and we will have more things to worry and test about it. Kelven On 9/24/13 1:10 PM, Frank Zhang frank.zh...@citrix.com wrote: Agree. Given current CloudStack code base changing something to another thing is really not a good way. As Darren is working on modular spring, why not construct a new VMWare plugin separately using vijava? Then we can reduce the risk of surprising existing customer and switch to new module when it finally gets mature. -Original Message- From: Kelven Yang [mailto:kelven.y...@citrix.com] Sent: Tuesday, September 24, 2013 11:59 AM To: dev@cloudstack.apache.org Subject: Re: VmWare SDK to vijava We have commercial releases on top of existing code base and there are lots of testing efforts behind it, dramatic switch means $ cost, the major concern for me is not about how beautiful vijava is or how bad a direct wsdl approach would be. it is about to get things move smoothly. It looks like that we should have VMware layer on its own to have a plugin structure so that we can replace underlying binding easier, it should solve the balance between developer's motivation and carrying on the legacy with minimal impacts to the rest of others. Kelven On 9/23/13 6:01 PM, Hugo Trippaers h...@trippaers.nl wrote: Heya, This biggest advantage i see in using vijava is that a lot of the functionality that we now have in the vmware-base project is already supplied with vijava. There is a lot of code that facilitates calling tasks and other stuff in our MO classes. These classes are available in vijava and could be used instead of our classes. Basically when using vijava correctly you hardly have to work with the ManagedObjectReferences anymore. For me this would be a big benefit as it makes programming against vmware a lot easier. We also have a lot of duplicate code currently in the vmware class and i wouldn't mind getting rid of it, which i think is easier with the vijava libraries. That said, the main driver is getting it into the main build so any other efforts towards that goal are ok with me. I would propose that somebody else puts up a branch with our own wdsl wrapper and we open a discussion thread when both branches are ready to see which we want to merge in master. Anybody who wants to pick that up? I'm stubbornly going to continue with converting to vijava, I put some effort into it and i want at least to see it running once ;-) And the more i work with it the more i'm seeing to benefits of the library so i might be able to be more convincing in the end :-) Cheers, Hugo On Sep 24, 2013, at 2:18 AM, Kelven Yang kelven.y...@citrix.com wrote: Prior to 5.1, VMware provides java binding in its SDK and this is where CloudStack VMware integration began with. Starting from 5.1, VMware no longer provides the java binding in binary form and recommends its customers to generate directly from its WS WSDL. Since we are not sure if we can distribute VMware wsdl legally or not, therefore, we ended up to generate and distribute the java binding in binary form. If we can get this cleared in lebal, as Darren pointed, we can solve our non-dist issue easily in matter of adding couple of lines in maven. As of vijava, yes, I think it may add some value from developer's point of view, but on the other hand, I don't see immediate benefits to having another layer on top of VMware official WS API, vijava is an open source project for providing convenient java binding to vmware WS API, maybe I'm wrong, but I think VMware vSphere WS API is the only official published API from VMware, and the testing result of the API is endorsed by VMware as an commercial entity. So I see more business value to stick with the official WS API directly. If we can clear the legal concern of redistributing VMware wsdl. I would +1 to add a build step of generating VMware java binding from wsdl. Kelven On 9/23/13 12:40 AM, Hugo Trippaers h...@trippaers.nl wrote: We have been having this discussion on moving vmware out of noredist since i joined the project. So no real need to rush this suddenly. Still it would be nice to get this in for the next release. The feature freeze of 4.3 is october
Re: VmWare SDK to vijava
I'm fine with that, but I'd say that modular boundary like this is too blurring that may end up to too much code divergency. If we can't state clearly about the boundary, then the cut will drag other pieces along with it. there are other logic being built between CloudStack and VMware API in resource level, we only want to cut at the place we really want and be able to share common work. Kelven On 9/24/13 2:16 PM, Frank Zhang frank.zh...@citrix.com wrote: Emm, I am saying totally creating new VMWare resource/discover/manager/guru as a plugin where each component for example VMWareResource is a module in plugin. This matches Darren's plugin proposal. and you (Kelven) could continue maintaining current implementation for backward compatibility. And community who is interested in vijava could develop own stuff with little concerns about current customers. -Original Message- From: Kelven Yang [mailto:kelven.y...@citrix.com] Sent: Tuesday, September 24, 2013 2:06 PM To: dev@cloudstack.apache.org Subject: Re: VmWare SDK to vijava It is about the interface layer between CloudStack and VMware, Spring can only help to what it can, ultimately, we need to refactor the interface layer to take in vijava as one of its implementations. We also need to consider of another situation, with the latest vSphere 5.1 API, although VMware claims to support all previous vSphere versions with it, we actually found that this is not true. We may have to face the fact that we will need to support two versions of vSphere APIs at run time side-by-side. I'm leaning towards for us to to have some control in generating the API stub for this(the direct WSDL way), if it is to vijava, it depends on whether or not it has built-in side-by-side VMware API support. and we will have more things to worry and test about it. Kelven On 9/24/13 1:10 PM, Frank Zhang frank.zh...@citrix.com wrote: Agree. Given current CloudStack code base changing something to another thing is really not a good way. As Darren is working on modular spring, why not construct a new VMWare plugin separately using vijava? Then we can reduce the risk of surprising existing customer and switch to new module when it finally gets mature. -Original Message- From: Kelven Yang [mailto:kelven.y...@citrix.com] Sent: Tuesday, September 24, 2013 11:59 AM To: dev@cloudstack.apache.org Subject: Re: VmWare SDK to vijava We have commercial releases on top of existing code base and there are lots of testing efforts behind it, dramatic switch means $ cost, the major concern for me is not about how beautiful vijava is or how bad a direct wsdl approach would be. it is about to get things move smoothly. It looks like that we should have VMware layer on its own to have a plugin structure so that we can replace underlying binding easier, it should solve the balance between developer's motivation and carrying on the legacy with minimal impacts to the rest of others. Kelven On 9/23/13 6:01 PM, Hugo Trippaers h...@trippaers.nl wrote: Heya, This biggest advantage i see in using vijava is that a lot of the functionality that we now have in the vmware-base project is already supplied with vijava. There is a lot of code that facilitates calling tasks and other stuff in our MO classes. These classes are available in vijava and could be used instead of our classes. Basically when using vijava correctly you hardly have to work with the ManagedObjectReferences anymore. For me this would be a big benefit as it makes programming against vmware a lot easier. We also have a lot of duplicate code currently in the vmware class and i wouldn't mind getting rid of it, which i think is easier with the vijava libraries. That said, the main driver is getting it into the main build so any other efforts towards that goal are ok with me. I would propose that somebody else puts up a branch with our own wdsl wrapper and we open a discussion thread when both branches are ready to see which we want to merge in master. Anybody who wants to pick that up? I'm stubbornly going to continue with converting to vijava, I put some effort into it and i want at least to see it running once ;-) And the more i work with it the more i'm seeing to benefits of the library so i might be able to be more convincing in the end :-) Cheers, Hugo On Sep 24, 2013, at 2:18 AM, Kelven Yang kelven.y...@citrix.com wrote: Prior to 5.1, VMware provides java binding in its SDK and this is where CloudStack VMware integration began with. Starting from 5.1, VMware no longer provides the java binding in binary form and recommends its customers to generate directly from its WS WSDL. Since we are not sure if we can distribute VMware wsdl legally or not, therefore, we ended up to generate and distribute the java binding in binary form. If we can get
RE: VmWare SDK to vijava
So this discussion took a big turn that I did not expect. I am very strongly against creating a plugin layer just to interface with VmWare. I appreciate both the effort from Darren and Hugo and each hold some merit. I think we should discuss this out and drive a consensus rather than spending time to create plugin layers and such. For me, I prefer going directly to wsdl because the helper layer (both vim25 and vijava) is so thin that it's not a lot of effort to reproduce. Going directly to wsdl has the following advantages: - We don't have to worry about upgrades in the helper libraries. Look at what happened on 4.2 vim25 upgrade and the change in hidden behavior changes that caused lots of bugs. It just doesn't seem to be worth the time to deal with third party helper libraries for the small amount of code gain. - With wsdl, we can generate with different package names so that using two different versions of wsdls can have two different set of stub classes so we avoid using java class loaders to distinguish between the two. Please, let's discuss on this and drive a consensus together rather than try to accommodate all. --Alex -Original Message- From: Kelven Yang [mailto:kelven.y...@citrix.com] Sent: Tuesday, September 24, 2013 2:06 PM To: dev@cloudstack.apache.org Subject: Re: VmWare SDK to vijava It is about the interface layer between CloudStack and VMware, Spring can only help to what it can, ultimately, we need to refactor the interface layer to take in vijava as one of its implementations. We also need to consider of another situation, with the latest vSphere 5.1 API, although VMware claims to support all previous vSphere versions with it, we actually found that this is not true. We may have to face the fact that we will need to support two versions of vSphere APIs at run time side-by-side. I'm leaning towards for us to to have some control in generating the API stub for this(the direct WSDL way), if it is to vijava, it depends on whether or not it has built-in side-by-side VMware API support. and we will have more things to worry and test about it. Kelven On 9/24/13 1:10 PM, Frank Zhang frank.zh...@citrix.com wrote: Agree. Given current CloudStack code base changing something to another thing is really not a good way. As Darren is working on modular spring, why not construct a new VMWare plugin separately using vijava? Then we can reduce the risk of surprising existing customer and switch to new module when it finally gets mature. -Original Message- From: Kelven Yang [mailto:kelven.y...@citrix.com] Sent: Tuesday, September 24, 2013 11:59 AM To: dev@cloudstack.apache.org Subject: Re: VmWare SDK to vijava We have commercial releases on top of existing code base and there are lots of testing efforts behind it, dramatic switch means $ cost, the major concern for me is not about how beautiful vijava is or how bad a direct wsdl approach would be. it is about to get things move smoothly. It looks like that we should have VMware layer on its own to have a plugin structure so that we can replace underlying binding easier, it should solve the balance between developer's motivation and carrying on the legacy with minimal impacts to the rest of others. Kelven On 9/23/13 6:01 PM, Hugo Trippaers h...@trippaers.nl wrote: Heya, This biggest advantage i see in using vijava is that a lot of the functionality that we now have in the vmware-base project is already supplied with vijava. There is a lot of code that facilitates calling tasks and other stuff in our MO classes. These classes are available in vijava and could be used instead of our classes. Basically when using vijava correctly you hardly have to work with the ManagedObjectReferences anymore. For me this would be a big benefit as it makes programming against vmware a lot easier. We also have a lot of duplicate code currently in the vmware class and i wouldn't mind getting rid of it, which i think is easier with the vijava libraries. That said, the main driver is getting it into the main build so any other efforts towards that goal are ok with me. I would propose that somebody else puts up a branch with our own wdsl wrapper and we open a discussion thread when both branches are ready to see which we want to merge in master. Anybody who wants to pick that up? I'm stubbornly going to continue with converting to vijava, I put some effort into it and i want at least to see it running once ;-) And the more i work with it the more i'm seeing to benefits of the library so i might be able to be more convincing in the end :-) Cheers, Hugo On Sep 24, 2013, at 2:18 AM, Kelven Yang kelven.y...@citrix.com wrote: Prior to 5.1, VMware provides java binding in its SDK and this is where CloudStack VMware integration began with. Starting from 5.1, VMware
Re: VmWare SDK to vijava
On 9/24/13 4:22 PM, Alex Huang alex.hu...@citrix.com wrote: So this discussion took a big turn that I did not expect. I am very strongly against creating a plugin layer just to interface with VmWare. I appreciate both the effort from Darren and Hugo and each hold some merit. I think we should discuss this out and drive a consensus rather than spending time to create plugin layers and such. For me, I prefer going directly to wsdl because the helper layer (both vim25 and vijava) is so thin that it's not a lot of effort to reproduce. Going directly to wsdl has the following advantages: - We don't have to worry about upgrades in the helper libraries. Look at what happened on 4.2 vim25 upgrade and the change in hidden behavior changes that caused lots of bugs. It just doesn't seem to be worth the time to deal with third party helper libraries for the small amount of code gain. - With wsdl, we can generate with different package names so that using two different versions of wsdls can have two different set of stub classes so we avoid using java class loaders to distinguish between the two. +1, although I don't want to disappoint developer's motivations. The wsdl approach makes more business sense to me. -kelven Please, let's discuss on this and drive a consensus together rather than try to accommodate all. --Alex -Original Message- From: Kelven Yang [mailto:kelven.y...@citrix.com] Sent: Tuesday, September 24, 2013 2:06 PM To: dev@cloudstack.apache.org Subject: Re: VmWare SDK to vijava It is about the interface layer between CloudStack and VMware, Spring can only help to what it can, ultimately, we need to refactor the interface layer to take in vijava as one of its implementations. We also need to consider of another situation, with the latest vSphere 5.1 API, although VMware claims to support all previous vSphere versions with it, we actually found that this is not true. We may have to face the fact that we will need to support two versions of vSphere APIs at run time side-by-side. I'm leaning towards for us to to have some control in generating the API stub for this(the direct WSDL way), if it is to vijava, it depends on whether or not it has built-in side-by-side VMware API support. and we will have more things to worry and test about it. Kelven On 9/24/13 1:10 PM, Frank Zhang frank.zh...@citrix.com wrote: Agree. Given current CloudStack code base changing something to another thing is really not a good way. As Darren is working on modular spring, why not construct a new VMWare plugin separately using vijava? Then we can reduce the risk of surprising existing customer and switch to new module when it finally gets mature. -Original Message- From: Kelven Yang [mailto:kelven.y...@citrix.com] Sent: Tuesday, September 24, 2013 11:59 AM To: dev@cloudstack.apache.org Subject: Re: VmWare SDK to vijava We have commercial releases on top of existing code base and there are lots of testing efforts behind it, dramatic switch means $ cost, the major concern for me is not about how beautiful vijava is or how bad a direct wsdl approach would be. it is about to get things move smoothly. It looks like that we should have VMware layer on its own to have a plugin structure so that we can replace underlying binding easier, it should solve the balance between developer's motivation and carrying on the legacy with minimal impacts to the rest of others. Kelven On 9/23/13 6:01 PM, Hugo Trippaers h...@trippaers.nl wrote: Heya, This biggest advantage i see in using vijava is that a lot of the functionality that we now have in the vmware-base project is already supplied with vijava. There is a lot of code that facilitates calling tasks and other stuff in our MO classes. These classes are available in vijava and could be used instead of our classes. Basically when using vijava correctly you hardly have to work with the ManagedObjectReferences anymore. For me this would be a big benefit as it makes programming against vmware a lot easier. We also have a lot of duplicate code currently in the vmware class and i wouldn't mind getting rid of it, which i think is easier with the vijava libraries. That said, the main driver is getting it into the main build so any other efforts towards that goal are ok with me. I would propose that somebody else puts up a branch with our own wdsl wrapper and we open a discussion thread when both branches are ready to see which we want to merge in master. Anybody who wants to pick that up? I'm stubbornly going to continue with converting to vijava, I put some effort into it and i want at least to see it running once ;-) And the more i work with it the more i'm seeing to benefits of the library so i might be able to be more convincing in the end :-) Cheers, Hugo On Sep 24, 2013, at 2:18 AM, Kelven Yang kelven.y
RE: VmWare SDK to vijava
-Original Message- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: Tuesday, September 24, 2013 4:23 PM To: dev@cloudstack.apache.org Subject: RE: VmWare SDK to vijava So this discussion took a big turn that I did not expect. I am very strongly against creating a plugin layer just to interface with VmWare. I appreciate both the effort from Darren and Hugo and each hold some merit. I think we should discuss this out and drive a consensus rather than spending time to create plugin layers and such. For me, I prefer going directly to wsdl because the helper layer (both vim25 and vijava) is so thin that it's not a lot of effort to reproduce. Going directly to wsdl has the following advantages: - We don't have to worry about upgrades in the helper libraries. Look at what happened on 4.2 vim25 upgrade and the change in hidden behavior changes that caused lots of bugs. It just doesn't seem to be worth the time to deal with third party helper libraries for the small amount of code gain. - With wsdl, we can generate with different package names so that using two different versions of wsdls can have two different set of stub classes so we avoid using java class loaders to distinguish between the two. I want to elaborate specifically on this point a little bit. In a production deployed cloud that has been around, there's bound to be hypervisors of different versions. We have that problem with XenServer because it is version that's been supported by CloudStack the longest. CloudStack deals with the different versions of the same Hypervisor by writing two different ServerResources (they might share a common base of course). However, if the client stubs the different ServerResources talk to are also of different versions but with the same name, then we have to work on confining different versions of the client stubs to different class loaders. That's a lot of effort to do something simple. Instead, we can simply designate a different package name when generating from the wsdl (assuming the different versions of client stubs is due to wsdl versioning differences when interfacing with different versions of hypervisor) and have the ServerResources just refer to the different client stubs generated. Hence, I prefer generation directly from wsdl. --Alex
Re: VmWare SDK to vijava
a successful merge vote. Cheers, Hugo On Sep 23, 2013, at 3:10 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: It's seems there could be some good merit to adopting vijava. I hate to belabor this point, but we could get vmware plugin out of noredist real fast if we just generate bindings (I think) Do you know if legally we can add the vmware wsdl to git? We wouldn't redistribute it in the binary builds. If we could add the wsdl to git, I could add a couple lines to the Pom and it will generate the bindings as part of the build. Then vmware will be fully redistributable and there is no change to existing code. At runtime everything should be the same too. We could make that change real fast and then additionally continue to look at vijava. Personal I want to get rid of noredist. If somebody wants to contribute code that depends on nonfree code, it seems that should be in a cloudstack-nonfree repo. Darren On Sep 22, 2013, at 11:43 PM, Hugo Trippaers h...@trippaers.nl wrote: On Sep 23, 2013, at 1:39 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Yeah, I'll dig into it more. I think I understand a bit that vmware api is just a bunch of generics objects, so another library on top to create types on top of it helps. So I'll look at it more. In the end I'm still going to probably have reservations about 1) a custom XML/soap framework 2) a third party maintained later between us and vmware (sorta like libvirt-java always behind and incomplete with native libvirt). So it just depends on if the nicer api is worth the risk of the other things. I don't think vmwares api changes much, and you can always get to the generic objects so maybe my concerns are moot. Thanks, i could actually use a second pair of eyes if we want to get this into master. It would be nice to have a few people test this. I don't really share the concern on the XML/soap framework one is a good or bad as the other usually, i've seen interesting things with the axes framework as well. But thats besides the point for now. My main objective now it to get vijava working with as little changes as possible. Later we can do some refactoring and see if vijava really benefits us as much as i think/hope it will do. Your second concern is one i share, we will have to see how it goes. Vmware doesn't really change its api that often and if it does we are generally not the early adopters of new versions of libraries. So for now we should be ok. Hopefully we will get the vmware stuff in the redistributable build which is the primary objective here. All benefits are nice to have for future developments. Cheers, Hugo Darren On Sep 22, 2013, at 10:14 PM, Hugo Trippaers h...@trippaers.nl wrote: On Sep 23, 2013, at 1:01 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Oh, I thought the primary motivation was just to get to fully open source and out of noredist. I don't know enough about VMware and vijava so my comments may be off base (everything I know about vmware client is based off about 2 hours of googling), but my gut reaction is that its better to stick with mainstream than use vijava. I understand the VMware wsdl is a complicated and weird API. But the fact that you could drop vijava in real quick and it mostly matches the existing illustrates that its not a big departure from from the vmware bindings so doesn't seem to make consuming it much easier. It seems that vijava was better than vmware sdk 2.5 because you didn't need Apache Axis. But vSphere 5.1 sdk is based off of JAXWS and thus doesn't need axis anymore. If I'm going to put my trust in something at runtime I'd rather use the sun/oracle jaxws or apache CXF and not some custom xml/soap framework one guy wrote. The drop in real quick bit is just for starters. Some of the enums have changes names and instead of lists vijava uses arrays. Those items are pretty quick to adapt. The real interesting things are in the serviceInstance etc. That's where there are some changes. A nice example is on the vijava website where 100 lines of regular vmware sdk is replaced by 20-something lines of vijava. I'd say dig a bit deeper and i could use the help with the conversion process. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings
Re: VmWare SDK to vijava
On 9/24/13 4:54 PM, Alex Huang alex.hu...@citrix.com wrote: -Original Message- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: Tuesday, September 24, 2013 4:23 PM To: dev@cloudstack.apache.org Subject: RE: VmWare SDK to vijava So this discussion took a big turn that I did not expect. I am very strongly against creating a plugin layer just to interface with VmWare. I appreciate both the effort from Darren and Hugo and each hold some merit. I think we should discuss this out and drive a consensus rather than spending time to create plugin layers and such. For me, I prefer going directly to wsdl because the helper layer (both vim25 and vijava) is so thin that it's not a lot of effort to reproduce. Going directly to wsdl has the following advantages: - We don't have to worry about upgrades in the helper libraries. Look at what happened on 4.2 vim25 upgrade and the change in hidden behavior changes that caused lots of bugs. It just doesn't seem to be worth the time to deal with third party helper libraries for the small amount of code gain. - With wsdl, we can generate with different package names so that using two different versions of wsdls can have two different set of stub classes so we avoid using java class loaders to distinguish between the two. I want to elaborate specifically on this point a little bit. In a production deployed cloud that has been around, there's bound to be hypervisors of different versions. We have that problem with XenServer because it is version that's been supported by CloudStack the longest. CloudStack deals with the different versions of the same Hypervisor by writing two different ServerResources (they might share a common base of course). However, if the client stubs the different ServerResources talk to are also of different versions but with the same name, then we have to work on confining different versions of the client stubs to different class loaders. That's a lot of effort to do something simple. Instead, we can simply designate a different package name when generating from the wsdl (assuming the different versions of client stubs is due to wsdl versioning differences when interfacing with different versions of hypervisor) and have the ServerResources just refer to the different client stubs generated. Hence, I prefer generation directly from wsdl. This is my major point as well. VMware API itself is already complex and we already have wrapped it into isolated MO class layer, it may not be as complete as what vijava has but it pretty-much has served the needs for CloudStack, and as far as CloudStack concerns, we really don't need a full-around API wrapper. I would rather to refactor our MO class layer to not leak VMware low-level objects first and make the isolation layer fully neutral to wsdl/xyz wrapper, than to make a dramatic switch right now. The time should be spent for what is more worth. The less dependency in the middle, the more flexible we will gain in cases like the one we elaborate. -Kelven --Alex
Re: VmWare SDK to vijava
something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. I would seriously consider that overhead in maintenance. Now i don't even have to worry about that besides 4 lines of dependency in my maven project. So I'd personally like it if we just generated the stubs ourself and then we can move VMware plugin out of redist. I guess it would be helpful if you could illustrate some of the benefits of vijava. I know you wanted to get it working first so we could test the merits of it, I'm just having a hard time seeing why we would even attempt it, if we can just stick basically with what we have today, but make it all open source and distributable. Stay tuned and follow the commits :-) Darren Cheers, Hugo
Re: VmWare SDK to vijava
come in at the start of the new release cycle. So this is currently my main activity on CloudStack meaning i can work pretty much dedicated on this. With a bit of luck i can have the changes finished this week. Then it's up to the test results if we can make it into the 4.3 release or the 4.4 release. Of course all pending a successful merge vote. Cheers, Hugo On Sep 23, 2013, at 3:10 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: It's seems there could be some good merit to adopting vijava. I hate to belabor this point, but we could get vmware plugin out of noredist real fast if we just generate bindings (I think) Do you know if legally we can add the vmware wsdl to git? We wouldn't redistribute it in the binary builds. If we could add the wsdl to git, I could add a couple lines to the Pom and it will generate the bindings as part of the build. Then vmware will be fully redistributable and there is no change to existing code. At runtime everything should be the same too. We could make that change real fast and then additionally continue to look at vijava. Personal I want to get rid of noredist. If somebody wants to contribute code that depends on nonfree code, it seems that should be in a cloudstack-nonfree repo. Darren On Sep 22, 2013, at 11:43 PM, Hugo Trippaers h...@trippaers.nl wrote: On Sep 23, 2013, at 1:39 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Yeah, I'll dig into it more. I think I understand a bit that vmware api is just a bunch of generics objects, so another library on top to create types on top of it helps. So I'll look at it more. In the end I'm still going to probably have reservations about 1) a custom XML/soap framework 2) a third party maintained later between us and vmware (sorta like libvirt-java always behind and incomplete with native libvirt). So it just depends on if the nicer api is worth the risk of the other things. I don't think vmwares api changes much, and you can always get to the generic objects so maybe my concerns are moot. Thanks, i could actually use a second pair of eyes if we want to get this into master. It would be nice to have a few people test this. I don't really share the concern on the XML/soap framework one is a good or bad as the other usually, i've seen interesting things with the axes framework as well. But thats besides the point for now. My main objective now it to get vijava working with as little changes as possible. Later we can do some refactoring and see if vijava really benefits us as much as i think/hope it will do. Your second concern is one i share, we will have to see how it goes. Vmware doesn't really change its api that often and if it does we are generally not the early adopters of new versions of libraries. So for now we should be ok. Hopefully we will get the vmware stuff in the redistributable build which is the primary objective here. All benefits are nice to have for future developments. Cheers, Hugo Darren On Sep 22, 2013, at 10:14 PM, Hugo Trippaers h...@trippaers.nl wrote: On Sep 23, 2013, at 1:01 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Oh, I thought the primary motivation was just to get to fully open source and out of noredist. I don't know enough about VMware and vijava so my comments may be off base (everything I know about vmware client is based off about 2 hours of googling), but my gut reaction is that its better to stick with mainstream than use vijava. I understand the VMware wsdl is a complicated and weird API. But the fact that you could drop vijava in real quick and it mostly matches the existing illustrates that its not a big departure from from the vmware bindings so doesn't seem to make consuming it much easier. It seems that vijava was better than vmware sdk 2.5 because you didn't need Apache Axis. But vSphere 5.1 sdk is based off of JAXWS and thus doesn't need axis anymore. If I'm going to put my trust in something at runtime I'd rather use the sun/oracle jaxws or apache CXF and not some custom xml/soap framework one guy wrote. The drop in real quick bit is just for starters. Some of the enums have changes names and instead of lists vijava uses arrays. Those items are pretty quick to adapt. The real interesting things are in the serviceInstance etc. That's where there are some changes. A nice example is on the vijava website where 100 lines of regular vmware sdk is replaced by 20-something lines of vijava. I'd say dig a bit deeper and i could use the help with the conversion process. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google
Re: VmWare SDK to vijava
working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. I would seriously consider that overhead in maintenance. Now i don't even have to worry about that besides 4 lines of dependency in my maven project. So I'd personally like it if we just generated the stubs ourself and then we can move VMware plugin out of redist. I guess it would be helpful if you could illustrate some of the benefits of vijava. I know you wanted to get it working first so we could test the merits of it, I'm just having a hard time seeing why we would even attempt it, if we can just stick basically with what we have today, but make it all open source and distributable. Stay tuned and follow the commits :-) Darren Cheers, Hugo
RE: VmWare SDK to vijava
Agreed. If we can do it is the big question. Although, AFAIK, vijava is also generated from the same set of wsdl. So if we can't get the license, I have to wonder how did vijava get their BSD license? --Alex -Original Message- From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] Sent: Tuesday, September 24, 2013 6:07 PM To: dev@cloudstack.apache.org Cc: dev@cloudstack.apache.org Subject: Re: VmWare SDK to vijava My extensive testing consisted of it compiles! So somebody needs to validate it, I don't have a vmware setup handy. The wsdl generation route is not feasible unless legal says it's okay. Somebody want to email legal@? Darren On Sep 24, 2013, at 5:27 PM, Hugo Trippaers h...@trippaers.nl wrote: So at this moment we have the following tally, Darren, Alex, Kelven opt for the wsdl route Hugo opts for the vijava route I'm perfectly ok with ditching my work on the vijava in favour of the wsdl route. The arguments presented in the last few mails make a lot of sense. So i say the wsdl route is the way to go. I do think however that we need to revisit the vmware code anyway. There is dead code in there, formatting issues and a general duplication of code. Parts of my plan to switch to vijava was to simplify the code as well, but i can still do that with the WSDL layer. Darren, did you run your wsdl branch through the BVT test suite? If you did we can merge it on short notice and get on with it. If you didn't can you take care of that and give an overview of the testing done on that branch besides the BVT? Cheers, Hugo On Sep 25, 2013, at 2:58 AM, Kelven Yang kelven.y...@citrix.com wrote: We have commercial releases on top of existing code base and there are lots of testing efforts behind it, dramatic switch means $ cost, the major concern for me is not about how beautiful vijava is or how bad a direct wsdl approach would be. it is about to get things move smoothly. It looks like that we should have VMware layer on its own to have a plugin structure so that we can replace underlying binding easier, it should solve the balance between developer's tho motivation and carrying on the legacy with minimal impacts to the rest of others. Kelven On 9/23/13 6:01 PM, Hugo Trippaers h...@trippaers.nl wrote: Heya, This biggest advantage i see in using vijava is that a lot of the functionality that we now have in the vmware-base project is already supplied with vijava. There is a lot of code that facilitates calling tasks and other stuff in our MO classes. These classes are available in vijava and could be used instead of our classes. Basically when using vijava correctly you hardly have to work with the ManagedObjectReferences anymore. For me this would be a big benefit as it makes programming against vmware a lot easier. We also have a lot of duplicate code currently in the vmware class and i wouldn't mind getting rid of it, which i think is easier with the vijava libraries. That said, the main driver is getting it into the main build so any other efforts towards that goal are ok with me. I would propose that somebody else puts up a branch with our own wdsl wrapper and we open a discussion thread when both branches are ready to see which we want to merge in master. Anybody who wants to pick that up? I'm stubbornly going to continue with converting to vijava, I put some effort into it and i want at least to see it running once ;-) And the more i work with it the more i'm seeing to benefits of the library so i might be able to be more convincing in the end :-) Cheers, Hugo On Sep 24, 2013, at 2:18 AM, Kelven Yang kelven.y...@citrix.com wrote: Prior to 5.1, VMware provides java binding in its SDK and this is where CloudStack VMware integration began with. Starting from 5.1, VMware no longer provides the java binding in binary form and recommends its customers to generate directly from its WS WSDL. Since we are not sure if we can distribute VMware wsdl legally or not, therefore, we ended up to generate and distribute the java binding in binary form. If we can get this cleared in lebal, as Darren pointed, we can solve our non-dist issue easily in matter of adding couple of lines in maven. As of vijava, yes, I think it may add some value from developer's point of view, but on the other hand, I don't see immediate benefits to having another layer on top of VMware official WS API, vijava is an open source project for providing convenient java binding to vmware WS API, maybe I'm wrong, but I think VMware vSphere WS API is the only official published API from VMware, and the testing result of the API is endorsed by VMware as an commercial entity. So I see more business value to stick with the official WS API directly. If we can clear the legal concern of redistributing VMware wsdl. I would +1 to add
Re: VmWare SDK to vijava
. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. I would seriously consider that overhead in maintenance. Now i don't even have to worry about that besides 4 lines of dependency in my maven project. So I'd personally like it if we just generated the stubs ourself and then we can move VMware plugin out of redist. I guess it would be helpful if you could illustrate some of the benefits of vijava. I know you wanted to get it working first so we could test the merits of it, I'm just having a hard time seeing why we would even attempt it, if we can just stick basically with what we have today, but make it all open source and distributable. Stay tuned and follow the commits :-) Darren Cheers, Hugo
Re: VmWare SDK to vijava
there are some changes. A nice example is on the vijava website where 100 lines of regular vmware sdk is replaced by 20-something lines of vijava. I'd say dig a bit deeper and i could use the help with the conversion process. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. I would seriously consider that overhead in maintenance. Now i don't even have to worry about that besides 4 lines of dependency in my maven project. So I'd personally like it if we just generated the stubs ourself and then we can move VMware plugin out of redist. I guess it would be helpful if you could illustrate some of the benefits of vijava. I know you wanted to get it working first so we could test the merits of it, I'm just having a hard time seeing why we would even attempt it, if we can just stick basically with what we have today, but make it all open source and distributable. Stay tuned and follow the commits :-) Darren Cheers, Hugo
Re: VmWare SDK to vijava
and instead of lists vijava uses arrays. Those items are pretty quick to adapt. The real interesting things are in the serviceInstance etc. That's where there are some changes. A nice example is on the vijava website where 100 lines of regular vmware sdk is replaced by 20-something lines of vijava. I'd say dig a bit deeper and i could use the help with the conversion process. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. I would seriously consider that overhead in maintenance. Now i don't even have to worry about that besides 4 lines of dependency in my maven project. So I'd personally like it if we just generated the stubs ourself and then we can move VMware plugin out of redist. I guess it would be helpful if you could illustrate some of the benefits of vijava. I know you wanted to get it working first so we could test the merits of it, I'm just having a hard time seeing why we would even attempt it, if we can just stick basically with what we have today, but make it all open source and distributable. Stay tuned and follow the commits :-) Darren Cheers, Hugo
RE: VmWare SDK to vijava
Wow good guess...Hugo had me scratching my head on that oneIs Prussian some code name for Apache legalShould I askWould it make me look stupid if I askedall sorts of doubts going through my mind. --Alex -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, September 24, 2013 7:01 PM To: dev@cloudstack.apache.org Subject: Re: VmWare SDK to vijava Ha! Prussians == Prasanna? Godawful autocorrect. On 9/24/13 6:47 PM, Hugo Trippaers trip...@gmail.com wrote: Darren, you can probably work with Prussians to get it through the bvt suite. That would be a nice start. Cheers, Hugo Sent from my iPhone On 25 sep. 2013, at 09:06, Darren Shepherd darren.s.sheph...@gmail.com wrote: My extensive testing consisted of it compiles! So somebody needs to validate it, I don't have a vmware setup handy. The wsdl generation route is not feasible unless legal says it's okay. Somebody want to email legal@? Darren On Sep 24, 2013, at 5:27 PM, Hugo Trippaers h...@trippaers.nl wrote: So at this moment we have the following tally, Darren, Alex, Kelven opt for the wsdl route Hugo opts for the vijava route I'm perfectly ok with ditching my work on the vijava in favour of the wsdl route. The arguments presented in the last few mails make a lot of sense. So i say the wsdl route is the way to go. I do think however that we need to revisit the vmware code anyway. There is dead code in there, formatting issues and a general duplication of code. Parts of my plan to switch to vijava was to simplify the code as well, but i can still do that with the WSDL layer. Darren, did you run your wsdl branch through the BVT test suite? If you did we can merge it on short notice and get on with it. If you didn't can you take care of that and give an overview of the testing done on that branch besides the BVT? Cheers, Hugo On Sep 25, 2013, at 2:58 AM, Kelven Yang kelven.y...@citrix.com wrote: We have commercial releases on top of existing code base and there are lots of testing efforts behind it, dramatic switch means $ cost, the major concern for me is not about how beautiful vijava is or how bad a direct wsdl approach would be. it is about to get things move smoothly. It looks like that we should have VMware layer on its own to have a plugin structure so that we can replace underlying binding easier, it should solve the balance between developer's tho motivation and carrying on the legacy with minimal impacts to the rest of others. Kelven On 9/23/13 6:01 PM, Hugo Trippaers h...@trippaers.nl wrote: Heya, This biggest advantage i see in using vijava is that a lot of the functionality that we now have in the vmware-base project is already supplied with vijava. There is a lot of code that facilitates calling tasks and other stuff in our MO classes. These classes are available in vijava and could be used instead of our classes. Basically when using vijava correctly you hardly have to work with the ManagedObjectReferences anymore. For me this would be a big benefit as it makes programming against vmware a lot easier. We also have a lot of duplicate code currently in the vmware class and i wouldn't mind getting rid of it, which i think is easier with the vijava libraries. That said, the main driver is getting it into the main build so any other efforts towards that goal are ok with me. I would propose that somebody else puts up a branch with our own wdsl wrapper and we open a discussion thread when both branches are ready to see which we want to merge in master. Anybody who wants to pick that up? I'm stubbornly going to continue with converting to vijava, I put some effort into it and i want at least to see it running once ;-) And the more i work with it the more i'm seeing to benefits of the library so i might be able to be more convincing in the end :-) Cheers, Hugo On Sep 24, 2013, at 2:18 AM, Kelven Yang kelven.y...@citrix.com wrote: Prior to 5.1, VMware provides java binding in its SDK and this is where CloudStack VMware integration began with. Starting from 5.1, VMware no longer provides the java binding in binary form and recommends its customers to generate directly from its WS WSDL. Since we are not sure if we can distribute VMware wsdl legally or not, therefore, we ended up to generate and distribute the java binding in binary form. If we can get this cleared in lebal, as Darren pointed, we can solve our non-dist issue easily in matter of adding couple of lines in maven. As of vijava, yes, I think it may add some value from developer's point of view, but on the other hand, I don't see immediate benefits to having another layer on top of VMware official WS API, vijava is an open source project for providing convenient java binding to vmware WS API, maybe I'm
Re: VmWare SDK to vijava
On Sep 23, 2013, at 1:39 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Yeah, I'll dig into it more. I think I understand a bit that vmware api is just a bunch of generics objects, so another library on top to create types on top of it helps. So I'll look at it more. In the end I'm still going to probably have reservations about 1) a custom XML/soap framework 2) a third party maintained later between us and vmware (sorta like libvirt-java always behind and incomplete with native libvirt). So it just depends on if the nicer api is worth the risk of the other things. I don't think vmwares api changes much, and you can always get to the generic objects so maybe my concerns are moot. Thanks, i could actually use a second pair of eyes if we want to get this into master. It would be nice to have a few people test this. I don't really share the concern on the XML/soap framework one is a good or bad as the other usually, i've seen interesting things with the axes framework as well. But thats besides the point for now. My main objective now it to get vijava working with as little changes as possible. Later we can do some refactoring and see if vijava really benefits us as much as i think/hope it will do. Your second concern is one i share, we will have to see how it goes. Vmware doesn't really change its api that often and if it does we are generally not the early adopters of new versions of libraries. So for now we should be ok. Hopefully we will get the vmware stuff in the redistributable build which is the primary objective here. All benefits are nice to have for future developments. Cheers, Hugo Darren On Sep 22, 2013, at 10:14 PM, Hugo Trippaers h...@trippaers.nl wrote: On Sep 23, 2013, at 1:01 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Oh, I thought the primary motivation was just to get to fully open source and out of noredist. I don't know enough about VMware and vijava so my comments may be off base (everything I know about vmware client is based off about 2 hours of googling), but my gut reaction is that its better to stick with mainstream than use vijava. I understand the VMware wsdl is a complicated and weird API. But the fact that you could drop vijava in real quick and it mostly matches the existing illustrates that its not a big departure from from the vmware bindings so doesn't seem to make consuming it much easier. It seems that vijava was better than vmware sdk 2.5 because you didn't need Apache Axis. But vSphere 5.1 sdk is based off of JAXWS and thus doesn't need axis anymore. If I'm going to put my trust in something at runtime I'd rather use the sun/oracle jaxws or apache CXF and not some custom xml/soap framework one guy wrote. The drop in real quick bit is just for starters. Some of the enums have changes names and instead of lists vijava uses arrays. Those items are pretty quick to adapt. The real interesting things are in the serviceInstance etc. That's where there are some changes. A nice example is on the vijava website where 100 lines of regular vmware sdk is replaced by 20-something lines of vijava. I'd say dig a bit deeper and i could use the help with the conversion process. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. I would seriously consider that overhead in maintenance. Now i
Re: VmWare SDK to vijava
the help with the conversion process. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. I would seriously consider that overhead in maintenance. Now i don't even have to worry about that besides 4 lines of dependency in my maven project. So I'd personally like it if we just generated the stubs ourself and then we can move VMware plugin out of redist. I guess it would be helpful if you could illustrate some of the benefits of vijava. I know you wanted to get it working first so we could test the merits of it, I'm just having a hard time seeing why we would even attempt it, if we can just stick basically with what we have today, but make it all open source and distributable. Stay tuned and follow the commits :-) Darren Cheers, Hugo
Re: VmWare SDK to vijava
When I upgraded vmware sdk from 4.x to 5.1 before, I looked into the build script used by Vmware published SDK. It seems that besides normal jawxs generated client stubs from wsdl, Vmware sdk published build script has another post processing done on VimService.java class generated. The post processing class has no source code, only binary bundled with Vmware SDK. If we want to generate client stubs ourselves from WSDL, we may need to delve in to see why that post processing is needed for VimService.java. Thanks -min On 9/22/13 7:59 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: I was looking at the vmware jar and realized it's just a jaxws generated client stubs. I'm sure this has been discussed before, so I'm curious why we can't just download the wsdl and generate the stubs ourselves? I assume we can't distribute the wsdl's, so we can just check in the java code minus the wsdl. That should work fine at runtime. I downloaded the sdk and generated the client with the below command and its 100% compatible with the vim25.jar ~/Downloads/apache-cxf-2.7.6/bin/wsdl2java -frontend jaxws21 -p com.vmware.vim25 vim25/vimService.wsdl Darren On Sun, Sep 22, 2013 at 4:09 AM, Hugo Trippaers h...@trippaers.nl wrote: Hey all, This is something we wanted to do for a long time, but never got started as far as i know. With some time on my hands i've made some progress on this. I just pushed the branch vmwaresdk-to-vijava to git. In this branch i've changed the poms to use the vijava library (version 5.1) and i've started fixing all resulting compile errors. It is not a complete drop in replacement, but apparently just enough to make it work with a few changes. The major issues i've encountered so far by working my way through VmwareResource.java are * changes to enums, slightly different naming convention for the values * vijava used arrays where vmware sdk uses lists * changes names of exceptions. I've fixed all compile issues in VmwareResource.java at the moment and i will keep at it. If somebody want to pitch in, feel free. Just pick a file with compile errors and fix it :-) So far i've not focussed on the potential benefits of the vijava library, let's get it compiling first so we can do some testing with the new library. Is anybody planning some major work on the vmware stuff in CS? If you do, please let me know, so we can coordinate otherwise this will be a bother to merge into master eventually. ;-) Cheers, Hugo
Re: VmWare SDK to vijava
How'd you know about the post processing? I generated the stubs and it compile perfectly and ACS compile against the stubs too. I have no clue if it work as I never ran it though. One thing I ran into was that you had to generate for jaxws 2.1. Darren On Sep 23, 2013, at 11:25 AM, Min Chen min.c...@citrix.com wrote: When I upgraded vmware sdk from 4.x to 5.1 before, I looked into the build script used by Vmware published SDK. It seems that besides normal jawxs generated client stubs from wsdl, Vmware sdk published build script has another post processing done on VimService.java class generated. The post processing class has no source code, only binary bundled with Vmware SDK. If we want to generate client stubs ourselves from WSDL, we may need to delve in to see why that post processing is needed for VimService.java. Thanks -min On 9/22/13 7:59 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: I was looking at the vmware jar and realized it's just a jaxws generated client stubs. I'm sure this has been discussed before, so I'm curious why we can't just download the wsdl and generate the stubs ourselves? I assume we can't distribute the wsdl's, so we can just check in the java code minus the wsdl. That should work fine at runtime. I downloaded the sdk and generated the client with the below command and its 100% compatible with the vim25.jar ~/Downloads/apache-cxf-2.7.6/bin/wsdl2java -frontend jaxws21 -p com.vmware.vim25 vim25/vimService.wsdl Darren On Sun, Sep 22, 2013 at 4:09 AM, Hugo Trippaers h...@trippaers.nl wrote: Hey all, This is something we wanted to do for a long time, but never got started as far as i know. With some time on my hands i've made some progress on this. I just pushed the branch vmwaresdk-to-vijava to git. In this branch i've changed the poms to use the vijava library (version 5.1) and i've started fixing all resulting compile errors. It is not a complete drop in replacement, but apparently just enough to make it work with a few changes. The major issues i've encountered so far by working my way through VmwareResource.java are * changes to enums, slightly different naming convention for the values * vijava used arrays where vmware sdk uses lists * changes names of exceptions. I've fixed all compile issues in VmwareResource.java at the moment and i will keep at it. If somebody want to pitch in, feel free. Just pick a file with compile errors and fix it :-) So far i've not focussed on the potential benefits of the vijava library, let's get it compiling first so we can do some testing with the new library. Is anybody planning some major work on the vmware stuff in CS? If you do, please let me know, so we can coordinate otherwise this will be a bother to merge into master eventually. ;-) Cheers, Hugo
Re: VmWare SDK to vijava
This is the code snippet from the build.sh bundled with Vmware SDK:
if [ x${1} != x-w ]
then
echo Generating vim25 stubs from wsdl
if [ -d com/vmware/vim25 ]
then
rm -rf com/vmware/vim25
fi
mkdir -p com/vmware/vim25
cp -f ../../../wsdl/vim25/*.* com/vmware/vim25/
${JAVAHOME}/bin/wsimport -wsdllocation ${WSDLLOCATION25} -p
com.vmware.vim25 -s . ${WSDLFILE25}
## fix VimService class to get the wsdl from the vim25.jar
${JAVAHOME}/bin/java -classpath ${CLASSPATH}:${SAMPLEJARDIR}
FixJaxWsWsdlResource ./com/vmware/vim25/VimService.java
find ./com/vmware/vim25 -depth -name '*.java' -print vim25_src.txt
echo Done generating vim25 stubs. Compiling vim25 stubs.
${JAVAHOME}/bin/javac -J-Xms1024M -J-Xmx1024M -classpath
${CLASSPATH}:${SAMPLEJARDIR} @vim25_src.txt
find ./com/vmware/vim25 -depth -name '*.class' -print vim25_class.txt
${JAVAHOME}/bin/jar cf ${SAMPLEJARDIR}/vim25.jar @vim25_class.txt
com/vmware/vim25/*.wsdl com/vmware/vim25/*.xsd
rm -f com/vmware/vim25/*.wsdl com/vmware/vim25/*.xsd
rm -f vim25_src.txt vim25_class.txt
echo Done compiling vim25 stubs.
fi
Look for the line with FixJaxWsWsdlResource.
Thanks
-min
On 9/23/13 1:08 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote:
How'd you know about the post processing? I generated the stubs and it
compile perfectly and ACS compile against the stubs too. I have no clue
if it work as I never ran it though. One thing I ran into was that you
had to generate for jaxws 2.1.
Darren
On Sep 23, 2013, at 11:25 AM, Min Chen min.c...@citrix.com wrote:
When I upgraded vmware sdk from 4.x to 5.1 before, I looked into the
build
script used by Vmware published SDK. It seems that besides normal jawxs
generated client stubs from wsdl, Vmware sdk published build script has
another post processing done on VimService.java class generated. The
post
processing class has no source code, only binary bundled with Vmware
SDK.
If we want to generate client stubs ourselves from WSDL, we may need to
delve in to see why that post processing is needed for VimService.java.
Thanks
-min
On 9/22/13 7:59 PM, Darren Shepherd darren.s.sheph...@gmail.com
wrote:
I was looking at the vmware jar and realized it's just a jaxws
generated
client stubs. I'm sure this has been discussed before, so I'm curious
why
we can't just download the wsdl and generate the stubs ourselves? I
assume
we can't distribute the wsdl's, so we can just check in the java code
minus
the wsdl. That should work fine at runtime. I downloaded the sdk and
generated the client with the below command and its 100% compatible
with
the vim25.jar
~/Downloads/apache-cxf-2.7.6/bin/wsdl2java -frontend jaxws21 -p
com.vmware.vim25 vim25/vimService.wsdl
Darren
On Sun, Sep 22, 2013 at 4:09 AM, Hugo Trippaers h...@trippaers.nl
wrote:
Hey all,
This is something we wanted to do for a long time, but never got
started
as far as i know. With some time on my hands i've made some progress
on
this. I just pushed the branch vmwaresdk-to-vijava to git. In this
branch
i've changed the poms to use the vijava library (version 5.1) and i've
started fixing all resulting compile errors.
It is not a complete drop in replacement, but apparently just enough
to
make it work with a few changes. The major issues i've encountered so
far
by working my way through VmwareResource.java are
* changes to enums, slightly different naming convention for the
values
* vijava used arrays where vmware sdk uses lists
* changes names of exceptions.
I've fixed all compile issues in VmwareResource.java at the moment
and i
will keep at it. If somebody want to pitch in, feel free. Just pick a
file
with compile errors and fix it :-)
So far i've not focussed on the potential benefits of the vijava
library,
let's get it compiling first so we can do some testing with the new
library.
Is anybody planning some major work on the vmware stuff in CS? If you
do,
please let me know, so we can coordinate otherwise this will be a
bother to
merge into master eventually. ;-)
Cheers,
Hugo
Re: VmWare SDK to vijava
on if the nicer api is worth the risk of the other things. I don't think vmwares api changes much, and you can always get to the generic objects so maybe my concerns are moot. Thanks, i could actually use a second pair of eyes if we want to get this into master. It would be nice to have a few people test this. I don't really share the concern on the XML/soap framework one is a good or bad as the other usually, i've seen interesting things with the axes framework as well. But thats besides the point for now. My main objective now it to get vijava working with as little changes as possible. Later we can do some refactoring and see if vijava really benefits us as much as i think/hope it will do. Your second concern is one i share, we will have to see how it goes. Vmware doesn't really change its api that often and if it does we are generally not the early adopters of new versions of libraries. So for now we should be ok. Hopefully we will get the vmware stuff in the redistributable build which is the primary objective here. All benefits are nice to have for future developments. Cheers, Hugo Darren On Sep 22, 2013, at 10:14 PM, Hugo Trippaers h...@trippaers.nl wrote: On Sep 23, 2013, at 1:01 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Oh, I thought the primary motivation was just to get to fully open source and out of noredist. I don't know enough about VMware and vijava so my comments may be off base (everything I know about vmware client is based off about 2 hours of googling), but my gut reaction is that its better to stick with mainstream than use vijava. I understand the VMware wsdl is a complicated and weird API. But the fact that you could drop vijava in real quick and it mostly matches the existing illustrates that its not a big departure from from the vmware bindings so doesn't seem to make consuming it much easier. It seems that vijava was better than vmware sdk 2.5 because you didn't need Apache Axis. But vSphere 5.1 sdk is based off of JAXWS and thus doesn't need axis anymore. If I'm going to put my trust in something at runtime I'd rather use the sun/oracle jaxws or apache CXF and not some custom xml/soap framework one guy wrote. The drop in real quick bit is just for starters. Some of the enums have changes names and instead of lists vijava uses arrays. Those items are pretty quick to adapt. The real interesting things are in the serviceInstance etc. That's where there are some changes. A nice example is on the vijava website where 100 lines of regular vmware sdk is replaced by 20-something lines of vijava. I'd say dig a bit deeper and i could use the help with the conversion process. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. I would seriously consider that overhead in maintenance. Now i don't even have to worry about that besides 4 lines of dependency in my maven project. So I'd personally like it if we just generated the stubs ourself and then we can move VMware plugin out of redist. I guess it would be helpful if you could illustrate some of the benefits of vijava. I know you wanted to get it working first so we could test the merits of it, I'm just having a hard time seeing why we would even attempt it, if we can just stick basically with what we have today, but make it all open source
Re: VmWare SDK to vijava
look at it more. In the end I'm still going to probably have reservations about 1) a custom XML/soap framework 2) a third party maintained later between us and vmware (sorta like libvirt-java always behind and incomplete with native libvirt). So it just depends on if the nicer api is worth the risk of the other things. I don't think vmwares api changes much, and you can always get to the generic objects so maybe my concerns are moot. Thanks, i could actually use a second pair of eyes if we want to get this into master. It would be nice to have a few people test this. I don't really share the concern on the XML/soap framework one is a good or bad as the other usually, i've seen interesting things with the axes framework as well. But thats besides the point for now. My main objective now it to get vijava working with as little changes as possible. Later we can do some refactoring and see if vijava really benefits us as much as i think/hope it will do. Your second concern is one i share, we will have to see how it goes. Vmware doesn't really change its api that often and if it does we are generally not the early adopters of new versions of libraries. So for now we should be ok. Hopefully we will get the vmware stuff in the redistributable build which is the primary objective here. All benefits are nice to have for future developments. Cheers, Hugo Darren On Sep 22, 2013, at 10:14 PM, Hugo Trippaers h...@trippaers.nl wrote: On Sep 23, 2013, at 1:01 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Oh, I thought the primary motivation was just to get to fully open source and out of noredist. I don't know enough about VMware and vijava so my comments may be off base (everything I know about vmware client is based off about 2 hours of googling), but my gut reaction is that its better to stick with mainstream than use vijava. I understand the VMware wsdl is a complicated and weird API. But the fact that you could drop vijava in real quick and it mostly matches the existing illustrates that its not a big departure from from the vmware bindings so doesn't seem to make consuming it much easier. It seems that vijava was better than vmware sdk 2.5 because you didn't need Apache Axis. But vSphere 5.1 sdk is based off of JAXWS and thus doesn't need axis anymore. If I'm going to put my trust in something at runtime I'd rather use the sun/oracle jaxws or apache CXF and not some custom xml/soap framework one guy wrote. The drop in real quick bit is just for starters. Some of the enums have changes names and instead of lists vijava uses arrays. Those items are pretty quick to adapt. The real interesting things are in the serviceInstance etc. That's where there are some changes. A nice example is on the vijava website where 100 lines of regular vmware sdk is replaced by 20-something lines of vijava. I'd say dig a bit deeper and i could use the help with the conversion process. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. I would seriously consider that overhead in maintenance. Now i don't even have to worry about that besides 4 lines of dependency in my maven project. So I'd personally like it if we just generated the stubs ourself and then we can move VMware plugin out of redist. I guess it would be helpful if you could illustrate some
Re: VmWare SDK to vijava
I was looking at the vmware jar and realized it's just a jaxws generated client stubs. I'm sure this has been discussed before, so I'm curious why we can't just download the wsdl and generate the stubs ourselves? I assume we can't distribute the wsdl's, so we can just check in the java code minus the wsdl. That should work fine at runtime. I downloaded the sdk and generated the client with the below command and its 100% compatible with the vim25.jar ~/Downloads/apache-cxf-2.7.6/bin/wsdl2java -frontend jaxws21 -p com.vmware.vim25 vim25/vimService.wsdl Darren On Sun, Sep 22, 2013 at 4:09 AM, Hugo Trippaers h...@trippaers.nl wrote: Hey all, This is something we wanted to do for a long time, but never got started as far as i know. With some time on my hands i've made some progress on this. I just pushed the branch vmwaresdk-to-vijava to git. In this branch i've changed the poms to use the vijava library (version 5.1) and i've started fixing all resulting compile errors. It is not a complete drop in replacement, but apparently just enough to make it work with a few changes. The major issues i've encountered so far by working my way through VmwareResource.java are * changes to enums, slightly different naming convention for the values * vijava used arrays where vmware sdk uses lists * changes names of exceptions. I've fixed all compile issues in VmwareResource.java at the moment and i will keep at it. If somebody want to pitch in, feel free. Just pick a file with compile errors and fix it :-) So far i've not focussed on the potential benefits of the vijava library, let's get it compiling first so we can do some testing with the new library. Is anybody planning some major work on the vmware stuff in CS? If you do, please let me know, so we can coordinate otherwise this will be a bother to merge into master eventually. ;-) Cheers, Hugo
Re: VmWare SDK to vijava
Hey Darren, There is actually just a bit more to the vijava library than just processing the wsdl. It simplifies some of the weirder parts of the vmware sdk. And in general it seems a well maintained piece of code. I'd rather use that that have to keep another set of bindings in sync with the outside world. We already have custom versions our own bindings for xapi and i would prefer the get rid of those too. With some work we could simplify parts of our vmware code, which would make it more easy to understand for the people working on it. Cheers, Hugo On Sep 23, 2013, at 10:59 AM, Darren Shepherd darren.s.sheph...@gmail.com wrote: I was looking at the vmware jar and realized it's just a jaxws generated client stubs. I'm sure this has been discussed before, so I'm curious why we can't just download the wsdl and generate the stubs ourselves? I assume we can't distribute the wsdl's, so we can just check in the java code minus the wsdl. That should work fine at runtime. I downloaded the sdk and generated the client with the below command and its 100% compatible with the vim25.jar ~/Downloads/apache-cxf-2.7.6/bin/wsdl2java -frontend jaxws21 -p com.vmware.vim25 vim25/vimService.wsdl Darren On Sun, Sep 22, 2013 at 4:09 AM, Hugo Trippaers h...@trippaers.nl wrote: Hey all, This is something we wanted to do for a long time, but never got started as far as i know. With some time on my hands i've made some progress on this. I just pushed the branch vmwaresdk-to-vijava to git. In this branch i've changed the poms to use the vijava library (version 5.1) and i've started fixing all resulting compile errors. It is not a complete drop in replacement, but apparently just enough to make it work with a few changes. The major issues i've encountered so far by working my way through VmwareResource.java are * changes to enums, slightly different naming convention for the values * vijava used arrays where vmware sdk uses lists * changes names of exceptions. I've fixed all compile issues in VmwareResource.java at the moment and i will keep at it. If somebody want to pitch in, feel free. Just pick a file with compile errors and fix it :-) So far i've not focussed on the potential benefits of the vijava library, let's get it compiling first so we can do some testing with the new library. Is anybody planning some major work on the vmware stuff in CS? If you do, please let me know, so we can coordinate otherwise this will be a bother to merge into master eventually. ;-) Cheers, Hugo
Re: VmWare SDK to vijava
Oh, I thought the primary motivation was just to get to fully open source and out of noredist. I don't know enough about VMware and vijava so my comments may be off base (everything I know about vmware client is based off about 2 hours of googling), but my gut reaction is that its better to stick with mainstream than use vijava. I understand the VMware wsdl is a complicated and weird API. But the fact that you could drop vijava in real quick and it mostly matches the existing illustrates that its not a big departure from from the vmware bindings so doesn't seem to make consuming it much easier. It seems that vijava was better than vmware sdk 2.5 because you didn't need Apache Axis. But vSphere 5.1 sdk is based off of JAXWS and thus doesn't need axis anymore. If I'm going to put my trust in something at runtime I'd rather use the sun/oracle jaxws or apache CXF and not some custom xml/soap framework one guy wrote. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. So I'd personally like it if we just generated the stubs ourself and then we can move VMware plugin out of redist. I guess it would be helpful if you could illustrate some of the benefits of vijava. I know you wanted to get it working first so we could test the merits of it, I'm just having a hard time seeing why we would even attempt it, if we can just stick basically with what we have today, but make it all open source and distributable. Darren
Re: VmWare SDK to vijava
On Sep 23, 2013, at 1:01 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Oh, I thought the primary motivation was just to get to fully open source and out of noredist. I don't know enough about VMware and vijava so my comments may be off base (everything I know about vmware client is based off about 2 hours of googling), but my gut reaction is that its better to stick with mainstream than use vijava. I understand the VMware wsdl is a complicated and weird API. But the fact that you could drop vijava in real quick and it mostly matches the existing illustrates that its not a big departure from from the vmware bindings so doesn't seem to make consuming it much easier. It seems that vijava was better than vmware sdk 2.5 because you didn't need Apache Axis. But vSphere 5.1 sdk is based off of JAXWS and thus doesn't need axis anymore. If I'm going to put my trust in something at runtime I'd rather use the sun/oracle jaxws or apache CXF and not some custom xml/soap framework one guy wrote. The drop in real quick bit is just for starters. Some of the enums have changes names and instead of lists vijava uses arrays. Those items are pretty quick to adapt. The real interesting things are in the serviceInstance etc. That's where there are some changes. A nice example is on the vijava website where 100 lines of regular vmware sdk is replaced by 20-something lines of vijava. I'd say dig a bit deeper and i could use the help with the conversion process. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. I would seriously consider that overhead in maintenance. Now i don't even have to worry about that besides 4 lines of dependency in my maven project. So I'd personally like it if we just generated the stubs ourself and then we can move VMware plugin out of redist. I guess it would be helpful if you could illustrate some of the benefits of vijava. I know you wanted to get it working first so we could test the merits of it, I'm just having a hard time seeing why we would even attempt it, if we can just stick basically with what we have today, but make it all open source and distributable. Stay tuned and follow the commits :-) Darren Cheers, Hugo
Re: VmWare SDK to vijava
Yeah, I'll dig into it more. I think I understand a bit that vmware api is just a bunch of generics objects, so another library on top to create types on top of it helps. So I'll look at it more. In the end I'm still going to probably have reservations about 1) a custom XML/soap framework 2) a third party maintained later between us and vmware (sorta like libvirt-java always behind and incomplete with native libvirt). So it just depends on if the nicer api is worth the risk of the other things. I don't think vmwares api changes much, and you can always get to the generic objects so maybe my concerns are moot. Darren On Sep 22, 2013, at 10:14 PM, Hugo Trippaers h...@trippaers.nl wrote: On Sep 23, 2013, at 1:01 PM, Darren Shepherd darren.s.sheph...@gmail.com wrote: Oh, I thought the primary motivation was just to get to fully open source and out of noredist. I don't know enough about VMware and vijava so my comments may be off base (everything I know about vmware client is based off about 2 hours of googling), but my gut reaction is that its better to stick with mainstream than use vijava. I understand the VMware wsdl is a complicated and weird API. But the fact that you could drop vijava in real quick and it mostly matches the existing illustrates that its not a big departure from from the vmware bindings so doesn't seem to make consuming it much easier. It seems that vijava was better than vmware sdk 2.5 because you didn't need Apache Axis. But vSphere 5.1 sdk is based off of JAXWS and thus doesn't need axis anymore. If I'm going to put my trust in something at runtime I'd rather use the sun/oracle jaxws or apache CXF and not some custom xml/soap framework one guy wrote. The drop in real quick bit is just for starters. Some of the enums have changes names and instead of lists vijava uses arrays. Those items are pretty quick to adapt. The real interesting things are in the serviceInstance etc. That's where there are some changes. A nice example is on the vijava website where 100 lines of regular vmware sdk is replaced by 20-something lines of vijava. I'd say dig a bit deeper and i could use the help with the conversion process. Additionally, if somebody wants to know how to do something with VMware or why something isn't working, I'd rather point them to the VMware SDK documentation than vijava. I would assume that there is going to be more information about the VMware library then there would be for vijava on stackoverflow and google in general. Google it, so far you are right, but java projects are switching. Don't forget that vijava is sort of an official vmware project. It is being maintained by one of their engineers and actually published in the com.vmware namespace. Finally, I wouldn't consider us generating and checking in the JAXWS bindings as being overhead in maintenance. The xapi bindings are not the same thing. VMware API is first and foremost a SOAP service. The java bindings they provide are just a convenience in that they already generated the client stubs for you. But if I was to consume any other SOAP service in the world, I would be generating my client stubs for it. So this is just the normal approach you take to consume a webservice. Typically you generate the stubs as part of the build and never check-in the generated code to git, but I don't think we can check the vmware wsdl into git (if we could, that would be ideal). But basically, if I'm generating stubs or I'm using a java jar, its about the same overhead. If the webservice moves from version X, I generate new stubs against version X of the wsdl. If the jar changes to version X, I update the pom dependency to version X. In both cases, you still have to regression test for compatibility, so testing effort trumps all other concerns. I would seriously consider that overhead in maintenance. Now i don't even have to worry about that besides 4 lines of dependency in my maven project. So I'd personally like it if we just generated the stubs ourself and then we can move VMware plugin out of redist. I guess it would be helpful if you could illustrate some of the benefits of vijava. I know you wanted to get it working first so we could test the merits of it, I'm just having a hard time seeing why we would even attempt it, if we can just stick basically with what we have today, but make it all open source and distributable. Stay tuned and follow the commits :-) Darren Cheers, Hugo
