On 05/18/2012 10:20 AM, Mike McClurg wrote:
On Fri, May 18, 2012 at 2:55 PM, Robert Schweikert<rjsch...@suse.com> wrote:
On 05/18/2012 06:49 AM, Mike McClurg wrote:
These bindings are autogenerated, which is why there is no source
repository for them. The license on the API bindings generation code
is GPLv2, so I don't see any reason why we couldn't publish the source
repo for these bindings.
But shouldn't the binding generation code then be part of the xen-server
source base?
I am a bit confused here. It sounds to me that CS depends on Java bindings
to Xen-server, yet the bindings are maintained separately from the server
code, do I understand this correctly? If this is the case then this is
rather strange, I think. For almost every code base that generates language
bindings the generation code/templates/setup is part of the cde base in
question, why would this be any different for xen-server?
Hi Robert,
Perhaps I should have said that there is no externally visible
repository for the api binding generation code.
Yes, that much I understood. My contention still is that this binding
generation code should be part of the XenServer source tree. Then when
the XenServer code is built in a distribution the maintainer can simply
enable the generation of the bindings as well. Having the generation
code in a separate repository (than in this case is not public either)
complicates things for distributions.
Every XenServer (and
XCP) release will have a corresponding sources ISO, which contains a
tarball of each of our internal repositories.
We have opened up a few of our development repositories (see
http://github.com/xen-org/), and I would like to see us open them all
up. But perhaps this is a conversation best left for a separate
thread, and perhaps on the xen-api mailing list instead of
cloudstack-dev.
Well, yes and no. If I cannot stand up a CloudStack cloud without
xenserver-java and I cannot build xenserver-java, as package from source
then CS is for all intends and purposes a closed system and
distributions will not package CS, as the packages they would create
will be useless.
I know David mentioned he maintains a Fedora package, but this didn't
sound like a straight forward undertaking.
Later,
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjsch...@suse.com
rschw...@ca.ibm.com
781-464-8147
