libcloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <>
Subject Re: [libcloud] Java Skeleton Available
Date Mon, 17 May 2010 05:43:07 GMT
I'd ask the same question, and also ask how this gets reconciled with the
incubator proposal of libcloud itself.  The original charter clearly stated
this was a project for the python community, and that it seems to have
served well.  Based on this behavior, it seems that all you need to do to
make sweeping changes in a project is to submit a single patch supporting
your company's cloud.  When exactly did libcloud turn into a multi-language
project?  I don't recall or see a "single" request from the java community
apart from IBM (eric's ) after they submitted a patch to support their
cloud.  On the other hand, "the" java library for cloud computing has had
continuous increase in committers, activity, and adoption, not to mention
proven ability to convert community's requests into code.  Where's the
transparent need?

Founder jclouds

On Sat, May 15, 2010 at 10:00 PM, Jerry Chen <> wrote:

> On May 14, 2010, at 3:46 PM, Eric Woods wrote:
> > As noted earlier, we've targeted a very strong mapping between the
> existing
> > Python design and the Java implementation. Aside from Python's design
> being
> > minimal and extensible, this will make it easy to port existing adapters
> to
> > Java since it's the same structure and model. This will also provide the
> > same look and usage to the user of libcloud adapters for faster adoption.
> >
> > Feedback is welcome and appreciated.
> How do we reconcile the fact that for all intents and purposes, the
> Libcloud community is geared towards Python developers?
> I'm not opposed to a Java port of Libcloud at all, but merely questioning
> its placement within the same repository. From a committer's standpoint, I
> have far less of an ability to review, to test and to sign off on Java code
> than I do for Python.
> What does everyone think?
> Cheers,
> Jerry

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message