OSGi bundle for jclouds-okhttp should import okio package with correct
version range.
Currently, there is no version range specified, causing it to be wired
to a higher version than intended in complex environments that have more
than one bundle for okio installed.
These classes should not close the release the payload as they are not
reading it.
- fix swift
- fix openstack-swift v1 and v2
- fix RetryOnRenewTest for v1 and v2
When Class.forName is called for a class in a different bundle it will
fail as the default karaf class loader won't load classes from other
bundles.
I have fixed this by using the classloader of the original
(non-autovalue) type and assuming it will be in the same bundle as the
autovalue type (I think this is a reasonable assumtion).
So far the only place where I've actually seen this being an issue is
when using the jclouds-labs-google provider within karaf. It fails
when serialising the Firewall.Rule class within a FirewallOptions
object.
The defaults of maven-bundle-plugin set the required version range to
only match guava-16, but the actual usage of guava within jclouds allows
any version after guava-16.
This helps dependent projects mix jclouds with bundles using other guava
versions within OSGi environments.
Previously not all fields of RunScriptOptions were included in copyTo
(e.g. runAsRoot and initScript).
Also options.equals(options.clone()) failed if options.loginPassword
was originally null - in the cloned object, it would be Optional.absent.
Fixes RunScriptOptions.toString, to only say “loginPasswordPresent”
if optional.isPresent().
now just pick the best one. it matters only when we are going to log in to a machine.
the only time the problem has been observed has been with pre-existing machines set up
outwith jclouds with multiple password.
On SUSE, the “-f” force option is not available for groupadd,
so `groupadd -f wheel` returns exit code 9 if the group already
exists. To avoid this, first check if the group exists.
In normal usage, this doesn’t matter: the script continues with the
next command anyway.
However, if the statements generated by UserAdd or AdminAccess are
used outside of that context (e.g. by code external to jclouds), then
this can cause them to fail.
- Adding env_reset to the default configuration in /etc/sudoers
- Adding secure_path to the default configuration in /etc/sudoers
- secure_path value is
"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Since commit 56e687f497, Linux line endings (LF) are enforced. But on
Windows, a common practice is to set core.autocrlf to 'auto', wich mean
that the local copy of the file has Windows line endings, whereas the
remote copy has Linux line endings (cf. https://help.github.com/articles/dealing-with-line-endings/#platform-windows).
With core.autoclrf=auto, Checkstyle will throw an error because local
files will have Windows line endings.
This setting will set Linux line endings for all text files, except
.cmd files.
Get the faultCode and faultMessage to actually be parsed (though I'm
not sure they're ever used), add statusCode, statusMessage and
statusUpdateTime, and have AWSEC2TemplateOptions default to a sane 30
minute lifetime for spot instance requests, so they don't get orphaned
forever if the price is too low etc.
Andrea Turli
Guglielmo Nigri
Ignasi Barrera
Duncan Grant
Ivana Yovcheva
Arvind Nadendla
Josef Cacek
Ciprian Ciubotariu
Aled Sage
Alex Heneveld
Graeme-Miller
Zack Shoylev
Nikolay Sokolov
Stuart Hendren
Yavor Yanchev
John McDonnell
olivierlemasle
Andrew Kennedy
Irmo Manie
Andrew Bayer
Marcus Wanner