[
https://issues.apache.org/jira/browse/JCLOUDS-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168895#comment-14168895
]
Adrian Cole commented on JCLOUDS-652:
-------------------------------------
As evident in mailing list discussion and also JCLOUDS-747 I suggest we roll
this back.
We would document that those who are trying to use the default jclouds http
service and try to send or receive >2GB in one chunk will fail. They should
either use multipart upload, or another http driver that can accept a long.
Since we've never released a version that supports larger than that out of the
box, this is more us documenting that constraint and how to work around it.
Internally, we shouldn't proliferate try-with-resources, and in fact, should
just change the language level back to 6.
Since we've done no feature work in 2.x, this is an easy rollback.
In the mean time, we can avoid the 2 branch of dev problem until we encounter
something actually worth breaking over. For example, we can regularly cut
releases from master without incompatible patch backporting.
I know that [~gaul] will highly object to this, so let's call a VOTE if that
happens.
> Transition to Java 7
> --------------------
>
> Key: JCLOUDS-652
> URL: https://issues.apache.org/jira/browse/JCLOUDS-652
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-core
> Affects Versions: 2.0.0
> Reporter: Andrew Gaul
> Assignee: Andrew Gaul
> Fix For: 2.0.0
>
>
> Moving to Java 7 allows jclouds to use more language and library features
> such as try-with-resources and HTTP client improvements. We previously
> discussed dropping Java 6 support for jclouds 2.0 on the user mailing list:
> http://mail-archives.apache.org/mod_mbox/jclouds-user/201405.mbox/%3C20140528185718.GC1036@sherlock%3E
> We need to unhook the Java 6 CloudBees builders before committing the Maven
> compile requirement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
