Hi,
Is there any way to add OpenStack Hypervisor Api in JCloud.Which class i
need to modify in order to implement OS-hypervisor Api??What are the steps
to implement a new Api in JCloud?
Any help is appreciated.
Thanks,
Regards,
AB
Checkstyle has now been re-enabled on master and will run
automatically in the validate phase of the Maven build.
TL;DR: If you want to run Checkstyle automatically as part of your
build, please run *at least* up to the 'verify' phase. 'mvn clean
compile' will *not* run Checkstyle!
A quic
Is there any high/low level design document available for jclouds project
so that I can understand how it works deeply and what it does for supported
providers? or I should dig into the code as it is the only way?
Thanks
On Tue, Oct 7, 2014 at 5:54 AM, Jasdeep Hundal <
jasdeep.singh.hun...@gmail.
Not a dev here, but is there some specific Helion feature that you'd like
to add that is outside the ComputeService/BlobStore/standard OpenStack
APIs? AFAIK, Helion is already a supported provider, and should work as
well as any other OpenStack based cloud (though there is plenty of work to
do eve
Hello Devs,
I'm interested to provide support of HP Helion in jclouds. Is it really
practically needed?
Also, how can I contribute in terms of this provider? Are there any
knowledge prerequisites? Are there any special environment needed to
develop and test against HP Helion?
Thanks
PS for folks not on irc, one potential gain we can do is to make
transparent who is owning testing the cloud and supporting the api.
This covers use cases needed when we used to run live tests on each
major release
http://jclouds.apache.org/releasenotes/1.5-tests/
For example, tester field could h
Makes sense for providers especially, but also for api groups where
there's a clear owner for all. For example, we aren't with the same
luxury on aws or azure yet.
On Mon, Oct 6, 2014 at 1:57 PM, Everett Toews
wrote:
> Any objections to using wildcards for brevity’s sake where it makes sense?
>
>
Thanks, especially for the TL;DR; :)
On Mon, Oct 6, 2014 at 3:32 PM, Andrew Phillips wrote:
> TL;DR: Checkstyle has now been re-enabled on master and will run
> automatically in the validate phase of the Maven build. [1]
>
> For those with 5min to spare, here some more details on what the problem
TL;DR: Checkstyle has now been re-enabled on master and will run
automatically in the validate phase of the Maven build. [1]
For those with 5min to spare, here some more details on what the
problem was here and how the PR addresses it:
As you probably all know, the project POM [2] is the ul
If this works for others, I'll merge [1] and revert it again once
we can merge [2] (which depends on SMX4-1859 [3]).
I’m okay with this approach.
I've committed the change to master and 1.8.x [1, 2] and updated the
follow-up PR to revert [3] once we can.
ap
[1]
https://git-wip-us.apac
On Oct 6, 2014, at 4:17 PM, Andrew Phillips wrote:
> If this works for others, I'll merge [1] and revert it again once we can
> merge [2] (which depends on SMX4-1859 [3]).
I’m okay with this approach.
Everett
The approach has already been tested and worked, and even it is not
the ideal solution, IMHO it's not a big deal.
Fine with me. Note that this is likely to leave karaf support for
agentproxy broken (I don't know if anyone ever used it, or even if it
works now!) since the necessary inclusion
Regarding the ssh agent thing, there are two options:
* Exclude the conflicting transitive dependency.
* Upgrading the version to a newer one with a compatible license.
For the latter we need to wait for a karat fix, and the former has
already been tested and it works as expected. I propose to me
Any objections to using wildcards for brevity’s sake where it makes sense?
e.g.
openstack-*
elastichosts-*
rackspace-*
hpcloud-*
cloudsigma2-*
Probably doesn’t make sense for aws providers/apis as stewardship of them isn’t
uniform.
Everett
On Oct 6, 2014, at 2:03 PM, Andrew Gaul wrote:
> F
It would be great if someone with better knowledge could give some
light on this, and if LGPL dependencies can be used.
That would be great, indeed. What I've been able to gather is the same
as you: as jclouds, we shouldn't have any problem releasing this.
The point Alex was originally tryin
I can also take the release, so if you're too busy Andrew just ping me
and I'll step in.
Regarding the LGPL thing, I have some doubts. Reading the ASF legal
FAQ [1] it seems that we can't include LGPL licenses, but the point
here is that we are *not* distributing the LGPL licensed software. A
jclo
Is there a volunteer for doing the release tomorrow?
I can pick this up - week doesn't look too full so far for me, and I'm
not on the road.
But I would rather not release with the LGPL dependency issue [1]
caused by JSch's agentproxy still open. Can we make a decision on [2]
first?
ap
Okay. Code cutoff EOD then.
Is there a volunteer for doing the release tomorrow?
If not, I’ll do it using AP’s Google Doc [1]. If I do wind up doing the
release, you’ll be able to find me on #jclouds in an emotionally distressed
state.
Everett
[1]
https://docs.google.com/document/d/10LkAD8W
Following on to the steward discussion[1], I created a wiki of all the
jclouds modules on our wiki:
https://wiki.apache.org/jclouds/Stewards
I would like to assign stewards for all modules; please add yourself to
the ones which interest you. This process may identify some orphan
providers and ho
I've now re-enabled parallel builds on the jclouds-java-8 job [1]. If
that goes well
Unfortunately, the java-8 job has become pretty unstable recently. I'm
not sure if that's caused by the parallelism, but I've disabled it
again to see if that makes a difference.
ap
Let's bump this to a jira and the dev list. There's grey area here.
https://issues.apache.org/jira/browse/JCLOUDS-747
-A
On Mon, Oct 6, 2014 at 10:20 AM, Andrew Gaul wrote:
> Modern Android supports modern Java language features:
>
> http://stackoverflow.com/questions/20480090/does-android-supp
Modern Android supports modern Java language features:
http://stackoverflow.com/questions/20480090/does-android-support-jdk-6-or-7
If someone in the community contributes well-scoped patches to allow
jclouds 1.8.x to work better on older Android we can merge those but
otherwise jclouds 2.0 should
Actually, it seems the 2.0 branch has started to use java 7 constructs
internally, which will make jclouds definitely incompatible with android.
For example, it is ok for code to expose alternate paths that use java 7 or
even 8 (ex how okio still works is that these methods are not called in
andro
Ps this reminds me of 2 repos I didn't check.. karaf and cli!
+1
Outsider, but thing change seems completely sensible and follows how we try
to treat dependency and plugin versions. It other words, let's merge this
so we can focus on work, not debuggint lib differences!
25 matches
Mail list logo
