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.
The previous site plugin utilizes several plugins. In about half of the cases, the respective version of a plugin as described in the outside plugin section. The following list enumerates those plugins and my reasoning to remove them safely from the section plugins.
- maven-project-info-reports-plugin (remove - because no reports get generated)
- maven-javadoc-plugin (stays - even when a profile doc exists, which provides a dedicated setup.) We have to discuss the removal to avoid any side effects.
- emma-maven-plugin (stays - my impression is that it is a duplicated declaration)
- maven-jxr-plugin (remove - only version declaration, with no further config, not utilized anywhere)
- maven-surefire-report-plugin (remove - only version declaration, with no further config, not utilized anywhere)
- apache-rat-plugin (stays - decision is straightforward. We have to discuss a restructure because the plugin gets mentioned three times; I guess one can get removed.
- maven-pmd-plugin (remove - only version declaration, with no further config, not utilized anywhere)
- spotbugs-maven-plugin (stays - beacuse of its extended configuration section - discuss a removal)
The maven site-plugin uses the declaration "site" in the section "distribution management," which points to a git repository named "jclouds-maven-site." This git repository got never relocated during the apache migration; also, it is ancient. My impression is that the site deployment is outdated and got used in the early days of JClouds.
Andrew Gaul
Andrew Gaul
dependabot[bot]
Hervé Boutemy
Juan Cabrerizo
Jean-Noël Rouvignac
gurkerl83
korlov42