Previously s3 always used v2 and aws-s3 always used v4. Now s3
defaults to v2 and can override to v4. Note that this does not change
BlobRequestSigner.
Implements the Azure AD authentication for Azure Blob, using the OAuth
module. Added more parameters to the AzureBlob provider:
- azureblob.auth
- azureblob.account
- azureblob.tenantId
The "auth" parameter is used to specify whether Key/SAS auth or Active
Directory is used. When using Active Directory auth, the identity no
longer maps to the storage account, which has to be specified
explicitly. The tenant ID also needs to be supplied to construct the
auth URL to obtain the token correctly.
JCLOUDS-1582: fixes a bug in the transient blobstore where after
uploading a multipart upload, GET/HEAD returns the hash of the content,
rather than the MPU ETag.
This has an incompatibility with JAXB motivating this removal.
jclouds GAE has not seen any development or issues in recent years and
uses a very old appengine-api-1.0-sdk dependency. Further it appears
to have modern Guava incompatibilities as seen in JCLOUDS-836.
The issue happens if a cloud provider returns lowercase metadata headers, for example: "x-object-meta-apiversion" instead of "X-Object-Meta-ApiVersion"
In that case, BlobStore.blobMetadata(CONTAINER, PATH).getUserMetadata()
incorrectly returns an empty map.
This happens because the code is looking for the exact String "-Meta-" (case-sensitive).
This checkin allows to handle metadata headers of any case, and also adds a unit test for that situation.
Currently, jclouds assumes that the ListBuckets response follows a
specific order: the <Owner> tag, followed by the <Buckets> tag. Within
the <Owner> tag, jclouds further assumes that the <ID> must occur before
the <DisplayName> tag. If the XML body does not adhere to this order,
the parser throws a NullPointerException.
DigitalOcean spaces does not adhere to this order and returns the
<DisplayName> tag before the <ID> tag. The patch changes the parser to
not depend on the order of the tags.
XMLBuilder is a very nice fluent API for building XML documents.
However, it is only used by a tiny portion of jclouds: the s3 api. The
use of the XMLBuilder class requires a dependency to
com.jamesmurty.utils:java-xmlbuilder jar and a transitive
dependency to the net.iharder:base64 jar (superseded by
java.util.Base64 in java 8). They are 18kb each approximately and they
not OSGi compatible. They are not huge, but they represent more API
surface and more things to change when trying to use jclouds in an OSGi
context (they need to be replaced by OSGi compatible bundles like
org.apache.servicemix.bundles.java-xmlbuilder).
This commit replaces the use of XMLBuilder by a direct use of the
javax.xml and org.w3c.dom APIs.
I hope retesting will be minimal, and most of this code is covered by
unit tests.
Previously, the plugin "emma" was integrated/used for maven site deployment. The following commits removed site deployment entirely.
For reference
- e02503e1cb
- 9158ab0b0e
The project requires at least JDK version 8. The specification to disable the liniting process in the JavaDoc process as of JDK version 8 is thus doubly specified and fulfilled by default; an explicit specification is no longer required. Version 3 of the JavaDoc plugin removes the "additional param" configuration attribute. The "doclint=false" configuration attribute disables the lint operation of the plugin.
Summary:
- Remove the profile "disable-doclint"
- Bump version of JavaDoc plugin to the latest > 3
- Remove the JavaDoc plugin's declaration from the build plugins used for default builds (building without a profile)
- Bump version of source plugin to latest > 3
- Remove unnecessary profile "doc" from the jclouds pom artifact
Remove distribution profiles from the JClouds parent, main, and core modules. Each profile defines assembly descriptors, but none of those files are provided by the project anymore.
The maven assembly plugin relies on those descriptors to dictate its execution.
The estimation is that individual maven artifacts, one per module, get deployed instead of a compressed deployment unit.
In that case, it is enough to use mavens deploy command in combination with distribution management configuration pushing individual jars to the artifact repositories.
According to the Jenkins configuration, only the maven profiles src and doc are necessary to execute in the build process. This commit removes the dedicated jenkins profile.
The site profile defines various enforcer execution rules, banned-dependencies, java (java and maven version). Those declarations in combination with the standard maven properties for the JDK version seem misleading and duplicated. Also, there is no indicator that the site profile is ever defined for a maven build.
In the last three commits, the site reporting feature got gradually decommissioned. This commit removes any remaining fragments in this regard. Remove the section distribution management from the profile clouds-project. The comment about incorrect links generated might have resulted from multiple invocations of the check style plugin. Previously the check style plugin got utilized at multiple sections (reporting section and profiles) and probably overlapping maven lifecycles.
In the last two commits, the site reporting feature got gradually decommissioned. The maven plugin project-info-reports got removed in the previous commit, which gets controlled by the reporting section. Because this workflow is out of use, this commit removes the reporting section.
Andrew Gaul
ramahin
SATYANAN-ANAND
SATYANAN-ANAND
Andrew Gaul
Juan Cabrerizo
Rajani-cloud
Timur Alperovich
Simone Locci
didixith
Miroslav Novak
i831992
Jean-Noël Rouvignac
gurkerl83