Re: notifications for jclouds-labs-aws

How can we enable notifications for jclouds-labs-aws? I did not see an email for https://github.com/jclouds/jclouds-labs-aws/pull/3 You're listed as an owner, so you should be able to subscribe to the repo if desired? I also see a bunch here:

Re: PRs with copyrights in the license header?

Unfortunately I could not configure Checkstyle with anything other than an absolute path to the license file. Our multi-module configuration works properly but not across repositories like jclouds-labs. Any ideas on how to make this work An obvious, if slightly annoying one: duplicate the

Re: Speed up jclouds builds

I submitted a possible fix to the underlying plexus-resources: http://jira.codehaus.org/browse/PLXCOMP-237 I can reliably trigger these symptoms so until both projects incorporate a workaround we may need to run the checkstyle phase without parallelism. Thanks, Gaul! Would it make sense to

Re: Speed up jclouds builds

let's work with the upstream projects and disable parallelism for the checkstyle goal for now. How do you envisage this? Take the checkstyle:checkstyle goal out of the build and add it as a post-build step? We have mainly Maven (rather than freestyle) builds, so unfortunately we can't add

Re: Speed up jclouds builds

Otherwise we can disable parallelism for now. Do we have any benchmarks which demonstrate the benefits of this? Well, those are precisely the benchmarks we were trying to gather in order to decide whether to enable parallelism ;-) What I'm going to do for now is take checkstyle:checkstyle

Javadoc page empty in Firefox?

Does anyone else also simply see an empty page when browsing to https://jclouds.apache.org/reference/javadoc/1.7.2/ in Firefox? Works for me in Chrome and IE, but Firefox (my configuration, at least?) simply displays an empty page. ap

Re: JENKINS-23049

I've just seen JENKINS-23049 [1], and I recall some changes in jclouds to fix this. By the looks of it, this behaviour would be expected? Trying to upload a blob with a payload but no content length seems to be supposed to fail [1]. See JCLOUDS-508 [2] for a related comment, and an answer

Re: Speed up jclouds builds

I can't see any immediately obvious way this is related to parallel builds, but seeing as the other PR builder (which is not parallel) didn't barf on these, I guess that must be the cause?

Re: Release 1.7.3

Sure I'll be available to help. Don't worry about time, I'm pretty sure it will be a smooth release and we'll make it with little trouble :) I'd really like to include the fix for JCLOUDS-517, as all ElasticStack based providers might be broken without it (all ElasticHosts ones are broken right

Re: Release 1.7.3

Step 2 requires belief in a power greater than ourselves and it is Maven. And, in my case at least, the ability to type or copy-paste 1.7.3 and 1.7.4-SNAPSHOT about 37 times in succession, with a couple of tricky breaks thrown in [*] ;-) Have a good Memorial Day weekend! ap [*] during

Re: Release 1.7.3

I’ll be starting the release in 10-15 minutes. Please consider the repos locked starting now. Thanks for the heads-up, Everett. Hope things are going smoothly! ap

Re: Release 1.7.3

Yourself and abayer kind of specialize in doing builds right? What do we need to do to make jclouds a one command release? Well, with things like the vote etc. I don't see how it could ever be *fully* automated. But I take it you're referring to automating everything *up until* the vote?

Re: Release 1.7.3

11 hours later and I’m actually uploading artifacts to the ASF Nexus. I might be able to get the vote email out tonight or tomorrow morning. Ffff...thanks for sticking with it, Everett! Sorry to hear it was exceptionally nasty even by jclouds release standards :-( ap

Re: Javadoc page empty in Firefox?

Replacing the HTTPS link with HTTP displays correctly on both browsers. Ahhh...so probably the HTTPS everywhere plugin that caused this. Care to submit a PR or simply a commit for this, Gaul? ap

Re: Release 1.7.3

I’ve been babysitting this upload all night and still can’t get the main jclouds repo to upload without erroring out at some point. Jeeez. ASF repo hanging up on you? Is it possible to upload a module at a time? Not that I am aware of :-( I've never tried running the release:perform

Re: remove jclouds cache

i am working with a number of jclouds conexts and the problem is i see that each one is using cache (about 8mb if i am not mistaken) Do you have any more details about these caches, e.g. which ones are large? jclouds has a number of caches which are used to speed up some of the reflection

Re: Release 1.7.3

We’re trying to work out a way to resume the upload. Sorry, stuck in meetings for a few more hours :-( What happens if we run release:perform with -rf :project-that-failed as part of the goals argument? ap

Re: Release 1.7.3

It gets ignored and the release starts from the beginning anyway. *sucks* ap

Re: Speed up jclouds builds

Just a note to say that I've removed the parallel stuff from the jclouds-java-7 PR builder for now. With Checkstyle no longer in the parallel bit it doesn't barf, but still fails reliably with the test failures seen in [1]. Bizarrely, it also doesn't appear to be faster? 58min [2] vs.

Re: jclouds cache size

Hi Inbar The thing is that you are probably using the cache without being aware of it. Without further details as to the exact objects on the heap I can only guess, but if you look at e.g. Reflection2 [1], you will see that jclouds caches a lot of calls using reflection to improve

Re: Javadoc page empty in Firefox?

Replacing the HTTPS link with HTTP displays correctly on both browsers. See https://github.com/jclouds/jclouds-site/pull/102 ap

Re: Release scripts

https://dist.apache.org/repos/dist/dev/jclouds/ I propose this is where we put all of the scripts that we use to automate our release process as we don’t have a great place for them in the current git repos. Thanks, Everett. I'm wondering whether under /dist is the right place for this

Re: Jekyll 1.5.1 for now, moving to 2+ later

To fix our doc build for the time being, I’ve set the Jekyll version to be 1.5.1. We can upgrade to 2+ when they’ve removed the dependency. At that point, I’d like to set it to a particular version of 2.x.x so our doc build is a bit more stable and not just always grabbing the latest

Re: [DISCUSS] Release Apache jclouds 1.7.3 RC1

Please find also the results of the live tests I've run against SoftLayer CCI provider: Tests run: 151, Failures: 22, Errors: 0, Skipped: 11 Thanks, Andrea! Do we know if these failures are expected..? ap

Re: Fwd: ApacheCon EU call for papers

I've just submitted an Introduction to Apache jclouds and I am thinking about submitting one about jclouds-chef (some expressed interest in the IRC channel). Interesting! New material, or based on some existing deck. Do we keep a reference to e.g. slide decks, presentation recordings etc.

Re: Multipart Upload

Hi Josh The Question is, does the MultipartForm class still works and where is the mistake? Thanks for the details on what you're looking to achieve. What is going wrong? Could you post an error or the (incorrectly?) generated request to a Gist or Pastie, or otherwise describe what is

Re: Fwd: Delivery Status Notification (Failure)

my problem is, i don't know how to use this class correctly. The error i got from Google, bad content: parse error. Do you have a example for me, how to use it correctly or a documentation? Could you enable wire and header logging [1] and put what is actually being sent and received (minus

[VOTE] Release Apache jclouds 1.7.3 RC1

Apologies for only getting round to this now - been a busy week :-( === Apache ID: andrewp --- [X] +1 Release. [ ] -1 Don't release (see notes).

Re: Delivery Status Notification (Failure)

thanks andrew I will try to move to jclouds 1.7 and take it from there... on that note is there a jclouds repo with the openstack labs project merged into latest (or one of the latest) jclouds 1.7? Labs projects are promoted one-by-one as we feel they are sufficiently mature. I am not aware

Re: Looking to customize ImageToOperatingSystem

To add to what Ignasi has said: if you think the use case you're working with is likely to be a general issue, and not just specific to your environment, could you briefly describe what you need on the user list? It could well be something we would want to include in jclouds! Thanks ap

Next board report: July?

From what I recall, we last reported in April [1], which would mean that we're up again in July. Is that correct? If so, I can get started on a draft... Regards ap [1] http://www.apache.org/foundation/records/minutes/2014/board_minutes_2014_04_16.txt

Re: [DISCUSS] Whether or not to require an apache.org email address for committers

This change was premature as it did not get consensus from the jclouds’ committers. The issue needs to be discussed before this change can be considered a requirement. Reverted the change in anticipation of this discussion: https://wiki.apache.org/jclouds/Committers%20Guide?action=info

Re: [DISCUSS] Whether or not to require an apache.org email address for committers

I've read nothing on [1] and [2] that requires a committer to use their @apache.org address. We should be putting our time and energy into finding ways to lower the barriers to joining our community and not raising them. I certainly agree with the aim of encouraging people to become

Re: Releasing Javadoc and jclouds

For the 1.7.4 release in mid-July, I propose that we have at least 2 people release jclouds. It should be released from a completely fresh environment, e.g. a newly created VM, that both people have access to. These 2 people work together in the VM and over IRC to create a script(s) to

Re: Releasing Javadoc and jclouds

IRC, etc, to follow the process and give a hand when needed. I already suffered the release pain, and look forward to having the process improved! :) What is this, Team Sufferers? ;-)) ap

Re: Contribute to jclouds

Hi Corey I've read the How to Contribute guide and Core Concepts. I understand usually one project is copied, but I don't know if I should start from the vcloud or vcloud-director projects. Also I don't know if it would be better to create a new provider or modify one of the existing vcloud

Re: [DISCUSS] Whether or not to require an apache.org email address for committers

Would it make sense to add something like the following to the Committers Guide [1]? Now: Ensure your name and email address are there as the committer prior to pushing it to the Apache repositories. Suggestion: Ensure your name and email address are there as the committer prior to

Next board report: July?

I've created a page for the draft, with some TODOs: https://wiki.apache.org/jclouds/July2014BoardReportProposal ap

Re: git commit: Upgrade to OkHttp 1.6.0

I think this is the one you are looking for: https://github.com/jclouds/jclouds/pull/413 That PR proposes a different change which, from what I understand, is dependent on the updated OkHttp version. I think Everett is referring to this commit [1], for which there doesn't seem to have

Re: git commit: Upgrade to OkHttp 1.6.0

Also, committing directly to the ASF git repo circumvents the CI jobs when a pull request is made in GitHub. Those jobs could catch any obvious problems and provide a layer of protection from breaking the build. What's unfortunate in this case is that we *also* have CI infrastructure

Re: git commit: Upgrade to OkHttp 1.6.0

I am struggling to stay on top on my GSoC review queue; can someone else investigate these racy tests and flaky infrastructure? I recall seeing a test PR from abayer with comments coming from the Apache Jenkins (I think). Unfortunately, I'm not sure that would have helped in this case

Re: major release cadence

What are some thoughts or questions on all of the above? * deprecation policy Requiring an @deprecated on a minor with removal on (at the earliest) the subsequent major sounds good to me. I think that's what we've been largely trying to do, but stating and communicating this clearly would

Re: Next board report: July?

I've created a page for the draft, with some TODOs: https://wiki.apache.org/jclouds/July2014BoardReportProposal Updated the goals and priorities to reflect some recent discussions on dev@. ap

Re: jclouds-labs 1.7.4-SNAPSHOT builds

While testing a jclouds-karaf patch[1] I noticed that repository.apache.org lacks 1.7.4-SNAPSHOT builds for jclouds-labs. Should be OK now, e.g. [1]. ap [1] https://repository.apache.org/content/repositories/snapshots/org/apache/jclouds/labs/abiquo/1.7.4-SNAPSHOT/

Re: Binary vs. source-level backwards compatibility?

https://github.com/jclouds/jclouds/pull/403 (which is still open in case anyone has time to merge it). Merged to master. Looks like we need to do a bit of work to backport this, though :-( [1] ap [1] https://github.com/jclouds/jclouds/pull/403#issuecomment-47428075

Re: [DISCUSS] The next version of jclouds

So how about this? My preference would be for 1.8.0 with the latest Guava version, branching off master, being the next release, and the last to support Java 6. 2.0, coming in Sept, would be the first version to support Java 7 and up only. ap

Re: major release cadence

1. Better use of semver +1. Minors should be X.Y.0 and X.Y.Z should indeed be used only for patch versions. 2. Deprecation of code and removal of deprecated code will only happen on major releases (e.g. MAJOR.0) Whilst I can see how this might be easier for us to formulate as a rule,

Re: major release cadence

Some projects never break client code. I think that’s one extreme that won’t serve us or our users well. To ease any pain associated with breaking code, we do need to make it very predictable. And making breaking changes at major release boundaries only achieves that goal. I think

Re: Next board report: July?

We're getting close to the submission guideline. If you'd like to add something to the current draft, please do so before the end of the week. https://wiki.apache.org/jclouds/July2014BoardReportProposal Thanks! ap

Re: major release cadence

Basically I’m looking for a guaranteed *minimum* amount of time for users to be able to react to breaking changes. Considering the long release cycles in place at many organizations, I think 6 months is the absolute minimum. Fully agree that 6 months as a minimum makes sense. Perhaps we

Re: major release cadence

Strong promises of compatibility will discourage many (breaking) improvements, big and small. I worry about this a lot given the existing quirky jclouds API and the large about of suboptimal API use I observe in Stack Overflow questions and jclouds-user mails. Thanks a lot for this, Gaul - I

Re: major release cadence

Most of our users won't know our deprecation policy further than these annotations so doing more seems pointless. I agree that annotations are likely the primary communication channel for deprecations. I don't think the intention of the proposal is to change that, just to make some notes

Re: major release cadence

Thank you for picking up and summarizing this thread, Andrew G! Perhaps we did not communicate this clearly, but jclouds has had a predictable deprecation policy for at least the last three years. Users can upgrade from an earlier 1.7.x release to a later 1.7 release and breaking changes were

Re: Primitive types in APIs?

We need the APIs to be consistent. Any particular technical reason for this? Personally, I would be tempted to say boolean when it can't be null, and @Nullable Boolean otherwise, but that's just a somewhat context-free style preference. ap

RE: Primitive types in APIs?

Also, while 3 valued logic is great, it isn't supported that well in Java (until Some/None/Option in Java 8, which helps some). jclouds is quite fond of Guava's Optional, but at the API level we mainly use it to allow access to extension APIs that are, well, optional. I'd agree that we

Re: [DISCUSS] The next version of jclouds

1. Week of July 14. I’m totally unavailable on the 14th but available the rest of the week. 2. Week of July 21. I’m at OSCON this week and totally unavailable to help. 3. Week of July 28. I’m free. I should be able to help in the weeks of the 21st and 28th... ap

Re: jsch driver?

There may be reasons for keeping it around that I am not aware of, but I thought I would bring it to everyone’s attention. Thanks! Now that we have the OkHttp driver, I'm not sure if there are any specific reasons for keeping it around. On the other hand, I don't recall any maintenance or

Re: jsch driver?

Now that we have the OkHttp driver, I'm not sure if there are any specific reasons for keeping it around. Erm...doh...OkHttp is of course an HTTP driver, not an SSH driver. Thanks for pointing that out, Ignasi ;-) Given the fact that we thus don't have any SSH alternatives and that it

Re: JIRA versions cleanup

We still have there 1.5.11, 1.6.4 and 1.7.4, and IMO that only causes the expectation that those releases are planned. I think we should remove them to avoid confusion and move all issues that were marked to be fixed in those versions to 1.8.0 or 2.0.0. Thoughts? Sounds like a good idea. An

Re: TestNG groups and exclusions

I will open a PR with my code later today but I just wanted to throw this out there for comments. +1! I don't think there's any particular reason for us to stick with the filename-based approach if this works now... Thanks! ap

Master frozen for all jclouds repos for 1.8.0

While we work on getting the 1.8.0 release out, please consider the master branches of all jclouds repositories frozen. Regards ap

Drop support for 'deleteContainer' on Glacier?

... Thoughts? ap [1] https://github.com/jclouds/jclouds-labs-aws/commit/7ca9836a44c22ba38bda41075e31d7636a0a8d09 [2] https://github.com/jclouds/jclouds-labs-aws/blob/master/glacier/src/main/java/org/jclouds/glacier/blobstore/GlacierBlobStore.java#L94-95 -- Andrew Phillips qrmedia Unless expressly

Re: Labs repos rejoining the main repo

Cons: * Longer build times What have I missed? One of the main cons, certainly w.r.t. labs, was: * code of vastly different degrees of maturity/up-to-dateness in the same repo I certainly wouldn't want to include a whole bunch of the current labs providers in core, since they're either

Re: OpenStack Swift Roadmap

1.8 - Removal of @Beta openstack-swift APIs - Ensure that all providers use the new API (hpcloud-objectstorage) - Address any potential BlobStore changes - Address outstanding JIRA issues I'm guessing some or all of this would make a good addition to the 1.8.0 release notes PR [1]? ap [1]

1.8.0 release status update

Just a quick status update on the progress of 1.8.0: 1.8.x branches and tags have been pushed, and the binaries are available for (pre-)testing in: https://repository.apache.org/content/repositories/orgapachejclouds-1019 I'll be preparing the dist and sending out the vote email tomorrow

Please check JIRA release notes for 1.8.0

We're about send out the [VOTE] email for the first RC for 1.8.0. Here are the current release notes as reported by JIRA:

[DISCUSS] Release Apache jclouds 1.8.0 RC1

This thread is for discussion of the first release candidate for Apache jclouds 1.8.0. Please use this thread for discussion of issues uncovered in the RC, questions you may have about the RC, etc. Thank you. Regards ap

[VOTE] Release Apache jclouds 1.8.0 RC1

This is the first release candidate for Apache jclouds 1.8.0. Please use the separate [DISCUSS] thread for anything but votes. It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12325587styleName=HtmlprojectId=12314430 *** Please download, test and

Re: 1.8.0 release status update

Here is the 1.8.0 release log...all glorious 81 steps of it: https://docs.google.com/document/d/10LkAD8Wk5Kcj38nQghTW-bQdCOXaxZad5W5Chu6HUCA/edit?usp=sharing Looking through it, the immediate things we need to address to make this easier, as far as I can see, are: 1. Ensure the Maven

Re: 1.8.0 release status update

1. Ensure the Maven release plugin stops prompting. This basically means getting rid of ${project.parent.version}-type versions in POMs Where you able to address this at all with the maven batch mode? To be honest, I didn't try. But I'd guess you need to answer the questions in a

Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1

Is there anything I can do to help validate the release?  Obviously I can run the live tests for familiar providers such as HP and GCE, etc. Live tests are best - if you could run those, that would be great. Otherwise, if you could check that all the JIRA issues you expect to be in

Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1

I notice we now have a dockerFile in the root of jclouds-labs [1]. I'm pretty sure that doesn't belong there? I don't think it should block the release, but it would be good to move it to the right place or get rid of it. @Andrea: or does it need to be there? Regards ap [1]

Re: Is there any difference between jclouds swift client and phython swiftclient?

Hi Naga You may want to have a look at and perhaps pick up this thread [1], which touches pretty much the same topic. Regards ap [1] http://markmail.org/thread/jizyq43naajigjt7

Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1

We'll keep this thread posted about the progress. For specifics about the bug feel free to watch bug 645 [1]. Thanks for the update, Shri! Just to clarify: we're still considering this a blocker at this point. ap

Re: Labs repos rejoining the main repo

I ask about this because we need to be able to provide value to our users quickly in actual releases. The users we work with don’t care to take snapshot releases and many will outright refuse snapshot releases. These are the same users who appreciate the predictability of things like

Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1

I can remedy this tonight if there is a consensus on what should happen here. Shri, thoughts on this? Given Chris' comments, I'm inclined not to consider this a blocker, but am also happy to respin if we feel this is sufficiently bad. ap

Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1

Alright, we need not consider bug 645 as a blocker. We should definitely release note the new requirement that jclouds.region has to be set to the appropriate value for HPCloud Object Storage. Considering you and Chris understand this issue best, I think, could either of you suggest an

Java 7 PR builder now going unstable on Checkstyle violations

Based on recent comments by Andrew G and now Jeremy [1], I've set up the Java 7 PR builder to go unstable on 0 Checkstyle violations (I wish there were an option to make it fail only on *new* violations!). The Java 6 PR builder configuration stays as-is: sunny 10, stormy 20, unstable 998.

Re: [VOTE] Release Apache jclouds 1.8.0 RC1

=== Apache ID: andrewp --- [X] +1 Release. [ ] -1 Don't release (see notes). --- Checklist

Re: [ANNOUNCE] Welcome new committer Andrea Turli

Please, join us in congratulating Andrea! Welcome, Andrea! Glad to have you on board! ap

Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1

We did not unhook google-cloud-storage from the release; not a release blocker but this could confuse users. Just to clarify: you mean we should probably *not* have released this? HP should either have a default region for all language bindings @Chris: Would that work? If so, which region

Re: [ANNOUNCE] Welcome new committer Chris Custine

Please welcome Chris Custine as our newest committer to jclouds! Welcome, Chris!! ap

Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1

I will unhook it from 1.8.x branch after release; is there any way to remove this single artifact from the release? Well, we can delete it from the staging repo, but that it'll be a little out of sync with the root POM [1] *and* the src and dist bundles, so I'm not sure if that's advisable.

Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1

We could close the vote now but I'd rather wait until tomorrow morning to see if there's any further discussion around the issues uncovered today, or if anyone else is able to review (we only have 3 votes so far). I'm in CET so won't be able to follow the discussion today, but will

Re: Please check JIRA release notes for 1.8.0

If you could kindly go through issues you're working that are still open and update the Fix Versions accordingly that would be great. To follow up on this one: there are currently 36 issues with Fix Version 1.8.0 that are Open, In Progress or Reopened:

Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1

If this is a lone blocker, I also take ownership and volunteer to cut the next RC if it is necessary. :-) I personally don't see this as a blocker right now, but of course thanks for stepping up! I understand Andrew G's point about minimizing disruption for users, but if I get this

[RESULT][VOTE] Release Apache jclouds 1.8.0 RC1

The vote is now closed, and with 4 binding +1s and 1 non-binding +1, we're ready to release. +1 (binding): etoews andrewp gaul ccustine +1: shrinandj Thanks to everyone for testing and verifying! ap

[ANNOUNCE] Apache jclouds 1.8.0 released

The Apache jclouds team is pleased to announce the release of jclouds 1.8.0. Apache jclouds is an open source multi-cloud toolkit for the Java platform that gives you the freedom to create applications that are portable across clouds while giving you full control to use cloud-specific

Quick post-1.8.0 update

Some FYI items after 1.8.0... CI setup changes: * swapped PR bulider Java versions: normal runs 7, -java-6 runs Java 6. * added CI builds for 1.8.x * switched the Java version for all the master builds to 7 Release doc done:

Re: Quick post-1.8.0 update

Can you unhook the java-6 builder from master? It still fails on my pull request: I'm not quite sure how to do that :-( The builder triggers for PRs opened against *all* branches (e.g. [1]), and I don't know if it can be configured to ignore PRs against a specific branch. I'll ask

Re: Quick post-1.8.0 update

Can you unhook the java-6 builder from master? It still fails on my pull request: [...] I'll ask CloudBees... ...and the answer is: no, that's currently not possible :-( ap

Re: Quick post-1.8.0 update

How can we move forward with the Java 7 transition? Do we need to configure different builders? The jclouds-pull-request builder is already on Java 7. We can just ignore the jclouds-java-6-pull-request builder for master, and look at it only for 1.8.x. ap

Re: antlr4 Annotation Processor

This would require a additional 10k dependency on antlr4-annotations-4.3.jar”. How does the community feel about using these compile time annotations for 2.0? Could you briefly describe what the processor would do and what kinds of pros and cons you see? I had a look at the links but

Hanging MWS test?

We've had a bunch of hanging CI builds in DEV@clouds of late, seemingly related to MockWebServer. Here's the most recent example [1]: Starting test testZeroLengthPutHasContentLengthHeader(org.jclouds.s3.S3ClientMockTest) Aug 08, 2014 6:44:07 PM

Re: Quick post-1.8.0 update

Sorry I do not understand -- you suggest pushing Java 7 commits to master and ignoring the error mails on every commit? Would it make more sense to disable the Java 6 builder for all branches instead? If we weren't still supporting Java 6 on 1.8.x I'd certainly agree. As a compromise, how

Re: Quick post-1.8.0 update

Sorry I do not understand -- you suggest pushing Java 7 commits to master and ignoring the error mails on every commit? PS: Which emails are you referring to here? The *commit* builder for master is on Java 7 only - there is no Java 6 builder for that. The Java PR builder shouldn't be

Re: Hanging MWS test?

This test is also hanging BuildHive: https://buildhive.cloudbees.com/job/jclouds/job/jclouds/1483/console Does anyone have any suggestions on how to fix this? Or can we disable it and try to figure out what's going on? ap

Re: Quick post-1.8.0 update

I object to the extra GitHub failure mails, but I also see some suspicious bytecode version failures mails going out over the general notifications list. Let my see if I can find one of the bytecode version failure emails. The only thing I can imagine is a comment notification email when the

Re: Quick post-1.8.0 update

but I also see some suspicious bytecode version failures mails going out over the general notifications list. Some of these (e.g. [1]) were done to master builds that weren't properly updated to Java 7 - I've just fixed labs-aws, labs-google and labs-openstack. Hopefully, that should get

Re: Quick post-1.8.0 update

Quick update on the PR builders: we now have a new Java 6 builder that uses a conditional build step to only run the Maven build if the target version is 1.6: https://github.com/jclouds/jclouds/pull/482#issuecomment-52006177

<    5   6   7   8   9   10   11   12   13   14   >