On 2/18/14, 2:43 PM, "Chiradeep Vittal"
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
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
wrote:
> If vim25.jar source is BSD then why are we including it in noredist?
>
> mvn install:install-file -Dfile=vim25_51.jar
> -D
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
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" 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
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 nam
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" wrote:
>That's still licensed as BSD (the license he
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
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" wrote:
>
>>Option 1
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" 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 a
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/2
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
#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 copyrightab
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
Chiradeep,
Whats the progress on this?
Cheers,
Hugo
On 22 jan. 2014, at 23:35, Chiradeep Vittal wrote:
> Reached out to @strikesme and @danwendlandt
>
> On 1/21/14 10:14 PM, "Hugo Trippaers"
> wrote:
>
>> We are now again at the exact same point as where Darren was.
>>
>> This is the leg
Reached out to @strikesme and @danwendlandt
On 1/21/14 10:14 PM, "Hugo Trippaers"
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 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 goin
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 wrote:
>
> Q. Can I redistribute the VI SDK libraries and sample cod
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 serv
Apparently we can
https://communities.vmware.com/docs/DOC-7983
http://markmail.org/thread/ttamcfb4d6azzbw7
On 1/21/14 2:46 PM, "Hugo Trippaers" 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
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
> wrote:
>
> Suboptimal for?
> Wouldn't the ACS user want th
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
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" wrote:
>On Tue, Jan 21, 2014 at 9:46 AM, Chip Chil
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" wrote:
>Heya,
>
>Does anyone know about the current status the legal discussions around
>including the
On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers 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
prod
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 wrote:
> Heya,
>
> Does anyone know about the current status the legal discussions around
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
I created https://issues.apache.org/jira/browse/LEGAL-180 for this.
Darren
On Wed, Oct 2, 2013 at 4:23 PM, Darren Shepherd
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
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 toda
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 wrote:
> On Tue, Sep 24, 2013 at 8:01 PM, Alex Huang wrote:
>> Wow good guess...Hugo had me scratching my
On Tue, Sep 24, 2013 at 8:01 PM, Alex Huang 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 Prasa
ep.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" wrote:
>
> >Darre
That clears up a lot, I didn't know how to get in touch with Prussia.
Darren
> On Sep 24, 2013, at 7:09 PM, Hugo Trippaers wrote:
>
> Hahah,
>
> Yeah indeed, awful autocorrect.
>
> Sent from my iPhone
>
>> On 25 sep. 2013, at 10:01, Chiradeep Vittal
>> wrote:
>>
>> Ha! Prussians == Pras
Hahah,
Yeah indeed, awful autocorrect.
Sent from my iPhone
> On 25 sep. 2013, at 10:01, Chiradeep Vittal
> wrote:
>
> Ha! Prussians == Prasanna?
> Godawful autocorrect.
>
>> On 9/24/13 6:47 PM, "Hugo Trippaers" wrote:
>>
>> Darren, you can probably work with Prussians to get it through the
Ha! Prussians == Prasanna?
Godawful autocorrect.
On 9/24/13 6:47 PM, "Hugo Trippaers" 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
>> wr
ren.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
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
> wrote:
>
> My extensive testing consisted of "it compiles!" So somebody needs to
> validate it, I don't
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 wrote:
>
> So at
On 9/24/13 5:27 PM, "Hugo Trippaers" 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 fe
On 9/24/13 4:54 PM, "Alex Huang" 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
>&g
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
> -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
;> -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 V
commodate 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 VMwar
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 interf
;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]
> >
;
>> -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
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 co
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 t
I created a branch vmwware-wsdl at
https://github.com/ibuildthecloud/cloudstack.git, and yes I did spell
vmware wrong in the branch name. I also created
https://reviews.apache.org/r/14304/
Darren
On Mon, Sep 23, 2013 at 6:01 PM, Hugo Trippaers wrote:
> Heya,
>
> This biggest advantage i see in
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 c
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/
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 C
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
proces
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 distrib
> Do you know if legally we can add the vmware wsdl to git?
If I recall correctly when we discussed it before it seems we were
instructed to ask legal@ for blessing.
That said - shipping or not shipping in a binary isn't really an issue
as a project our official releases are always source.
--Davi
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 vmw
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 buil
On Sep 23, 2013, at 1:39 PM, Darren Shepherd
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
> pro
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)
On Sep 23, 2013, at 1:01 PM, Darren Shepherd
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 hour
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
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 o
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
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
64 matches
Mail list logo
