This method has incorrect results when run on Windows. It is expected to
generate folder names compatible with Unix-like target machines, but by
using File.getParent it will actually be influenced by the host machine
OS type. This results in baseDir being set to a style that will not work
on Unix-like targets.
Readers can confuse this with 1. Found via error-prone. Fixed via:
find -name \*.java | xargs sed -i 's/\( [0-9][0-9]*\)l/\1L/g'
find -name \*.java | xargs sed -i 's/\(([0-9][0-9]*\)l/\1L/g'
Readers can confuse this with 1. Found via error-prone. Fixed via:
find -name \*.java | xargs sed -i 's/\( [0-9][0-9]*\)l/\1L/g'
find -name \*.java | xargs sed -i 's/\(([0-9][0-9]*\)l/\1L/g'
The default network of recently created projects have a null value for rangeIPv4
And all regions as subnets, which do have values for the rangeIPv4.
Fixes JCLOUDS-1158
* dynamically call TypeToken.isSupertypeOf with Guava 19 and later and
TypeToken.isAssignableFrom with Guava 18 and earlier
* consume or ignore values from methods with CheckReturnValue
* replace usage of removed Iterators.emptyIterator
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.
Related issues: JCLOUDS-1166, JCLOUDS-1160, JCLOUDS-1169
This change reverts commit da4614e and upgrades from Gson 2.3.1 to 2.5,
which is the last version that exports the internal packages, used in
jclouds-core, in the OSGi bundle.
Today the filesystem blobstore provider use the extended attributes of the
filesystem to store metadata. This is not always desirable as some filesystems
(such as NFSv3) do not support extended metadata. The current source code does
not allow to change this easily. getUserDefinedFileAttributeView could easily
be overriden for this purpose and allow extensions that customize where the
metadata should be stored.
See also JCLOUDS-658
Zack Shoylev
Erich Duda
Ignasi Barrera
Richard Downer
Andrea Turli
Josef Cacek
Andrew Gaul
Shri Javadekar
Stuart Hendren
Arvind Nadendla
Duncan Grant
Francois Rigault
Daniel Haeser Rech