Jenkins build is back to normal : jclouds-labs-openstack #82

[Apache Jenkins Server]

See 

Build failed in Jenkins: jclouds-labs-aws #82

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 66.48 KB...]
[WARNING] import static com.google.common.base.Objects.toStringHelper;
[WARNING] ^
[WARNING] symbol:   static toStringHelper
[WARNING] location: class
[WARNING] 
:70:
 warning - Tag @see: can't find getMarker() in 
org.jclouds.elb.options.ListLoadBalancersOptions
[WARNING] 
:77:
 warning - Tag @see: can't find getNames() in 
org.jclouds.elb.options.ListLoadBalancersOptions
[WARNING] 
:84:
 warning - Tag @see: can't find getNames() in 
org.jclouds.elb.options.ListLoadBalancersOptions
[WARNING] 
:62:
 warning - @return tag has no arguments.
[WARNING] 
:45:
 warning - Tag @see: can't find getCidrIp() in org.jclouds.rds.domain.IPRange
[WARNING] 
:128:
 warning - Tag @see: reference not found: SecurityGroupGroup#getVpcId()
[WARNING] 
:85:
 warning - Tag @see: can't find getSubnets() in org.jclouds.rds.domain.Instance
[WARNING] 
:93:
 warning - Tag @see: can't find getSubnets() in org.jclouds.rds.domain.Instance
[WARNING] 
:70:
 warning - Tag @see: can't find getMarker() in 
org.jclouds.rds.options.ListInstancesOptions
[WARNING] 
:77:
 warning - Tag @see: can't find getNames() in 
org.jclouds.rds.options.ListInstancesOptions
[WARNING] 
:84:
 warning - Tag @see: can't find getNames() in 
org.jclouds.rds.options.ListInstancesOptions
[WARNING] 
:50:
 warning - Tag @see: can't find getMarker() in 
org.jclouds.rds.options.ListSecurityGroupsOptions
[WARNING] 
:50:
 warning - Tag @see: can't find getMarker() in 
org.jclouds.rds.options.ListSubnetGroupsOptions
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-javadoc-plugin:2.9:jar (javadoc) @ jclouds-labs-aws ---
[INFO] Not executing Javadoc as the project is not a Java classpath-capable 
package
[INFO] 
[INFO] --- maven-source-plugin:2.2:jar-no-fork (attach-sources) @ 
jclouds-labs-aws ---
[INFO] 
[INFO] --- maven-source-plugin:2.2:test-jar-no-fork (attach-sources) @ 
jclouds-labs-aws ---
[INFO] 
[INFO] --- maven-surefire-plugin:2.17:test (integration) @ jclouds-labs-aws ---
[INFO] Toolchain in surefire-plugin: JDK[/home/jenkins/tools/java/latest1.8/]
[INFO] No tests to run.
[JENKINS] Recording test results[INFO] 

[INFO] --- duplicate-finder-maven-plugin:1.1.2:check (default) @ 
jclouds-labs-aws ---
[INFO] Ignoring POM project!
[INFO] 
[INFO] --- maven-checkstyle-plugin:3.0.0:check (default) @ jclouds-labs-aws ---
[INFO] Downloading from Nexus: 
http://repository.apache.org/snapshots/org/apache/jclouds/jclouds-resources/2.3.0-SNAPSHOT/maven-metadata.xml
[INFO] Downloading from apache-snapshots: 
https://repository.apache.org/content/repositories/snapshots/org/apache/jclouds/jclouds-resources/2.3.0-SNAPSHOT/maven-metadata.xml
[INFO] Downloaded from apache-snapshots: 
https://repository.apache.org/content/repositories/snapshots/org/apache/jclouds/jclouds-resources/2.3.0-SNAPSHOT/maven-metadata.xml
 (1.4 kB at 4.1 kB/s)
[INFO] Downloaded from Nexus: 
http://repository.apache.org/snapshots/org/apache/jclouds/jclouds-resources/2.3.0-SNAPSHOT/maven-metadata.xml
 (1.4 kB at 4.1 kB/s)
[INFO] Downloading from apache-snapshots: 
https://repository.apache.org/content/repositories/snapshots/org/apache/jclouds/jclouds-resources/2.3.0-SNAPSHOT/jclouds-resources-2.3.0-20200625.011728-27.pom
[INFO] Downloaded from apache-snapshots: 

Build failed in Jenkins: jclouds-labs-openstack #81

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 514.98 KB...]
[INFO] Exclude: **/modernizer_exclusions.txt
[INFO] Exclude: **/.factorypath
[INFO] Exclude: **/.apt_generated/**
[INFO] Exclude: **/.apt_generated_tests/**
[INFO] Exclude: **/.checkstyle
[INFO] Exclude: nb-configuration.xml
[INFO] Exclude: nbactions.xml
[INFO] Exclude: dependency-reduced-pom.xml
[INFO] Exclude: .repository/**
[INFO] Exclude: gc.log
[INFO] 1 resources included (use -debug for more details)
[INFO] Rat check: Summary over all files. Unapproved: 0, unknown: 0, generated: 
0, approved: 1 licenses.
[INFO] 
[INFO] --- maven-jar-plugin:2.4:test-jar (default) @ jclouds-labs-openstack ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-javadoc-plugin:2.9:aggregate-jar (javadoc) @ 
jclouds-labs-openstack ---
[INFO] Toolchain in javadoc-plugin: JDK[/home/jenkins/tools/java/latest1.8/]
[INFO] 
40 warnings
[WARNING] Javadoc Warnings
[WARNING] 
:49:
 warning - @param argument "name" is not a parameter name.
[WARNING] 
:48:
 warning - @param argument "name" is not a parameter name.
[WARNING] 
:51:
 warning - Tag @see:illegal character: "60" in "Builder#parameters(Map)"
[WARNING] 
:51:
 warning - Tag @see:illegal character: "62" in "Builder#parameters(Map)"
[WARNING] 
:51:
 warning - Tag @see: can't find parameters(Map) in 
org.jclouds.openstack.heat.v1.options.CreateStack.Builder
[WARNING] 
:61:
 warning - Tag @see:illegal character: "60" in "Builder#files(Map)"
[WARNING] 
:61:
 warning - Tag @see:illegal character: "62" in "Builder#files(Map)"
[WARNING] 
:61:
 warning - Tag @see: can't find files(Map) in 
org.jclouds.openstack.heat.v1.options.CreateStack.Builder
[WARNING] 
:218:
 warning - Tag @see: can't find status(String) in 
org.jclouds.openstack.heat.v1.options.ListStackOptions
[WARNING] 
:232:
 warning - Tag @see: can't find sortKey(String) in 
org.jclouds.openstack.heat.v1.options.ListStackOptions
[WARNING] 
:239:
 warning - Tag @see: can't find sortDirection(String) in 
org.jclouds.openstack.heat.v1.options.ListStackOptions
[WARNING] 
:57:
 warning - @param argument "name" is not a parameter name.
[WARNING] 
:98:
 warning - @param argument "name" is not a parameter name.
[WARNING] 
:112:
 warning - Tag @see cannot be used in inline documentation.  It can only be 
used in the following types of documentation: overview, package, 
class/interface, constructor, field, method.
[WARNING] 
:112:
 warning - Tag @see: reference not found: StremOptions
[WARNING] 

Build failed in Jenkins: jclouds-labs-aws #81

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 68.72 KB...]
[WARNING] import static com.google.common.base.Objects.toStringHelper;
[WARNING] ^
[WARNING] symbol:   static toStringHelper
[WARNING] location: class
[WARNING] 
:70:
 warning - Tag @see: can't find getMarker() in 
org.jclouds.elb.options.ListLoadBalancersOptions
[WARNING] 
:77:
 warning - Tag @see: can't find getNames() in 
org.jclouds.elb.options.ListLoadBalancersOptions
[WARNING] 
:84:
 warning - Tag @see: can't find getNames() in 
org.jclouds.elb.options.ListLoadBalancersOptions
[WARNING] 
:62:
 warning - @return tag has no arguments.
[WARNING] 
:45:
 warning - Tag @see: can't find getCidrIp() in org.jclouds.rds.domain.IPRange
[WARNING] 
:128:
 warning - Tag @see: reference not found: SecurityGroupGroup#getVpcId()
[WARNING] 
:85:
 warning - Tag @see: can't find getSubnets() in org.jclouds.rds.domain.Instance
[WARNING] 
:93:
 warning - Tag @see: can't find getSubnets() in org.jclouds.rds.domain.Instance
[WARNING] 
:70:
 warning - Tag @see: can't find getMarker() in 
org.jclouds.rds.options.ListInstancesOptions
[WARNING] 
:77:
 warning - Tag @see: can't find getNames() in 
org.jclouds.rds.options.ListInstancesOptions
[WARNING] 
:84:
 warning - Tag @see: can't find getNames() in 
org.jclouds.rds.options.ListInstancesOptions
[WARNING] 
:50:
 warning - Tag @see: can't find getMarker() in 
org.jclouds.rds.options.ListSecurityGroupsOptions
[WARNING] 
:50:
 warning - Tag @see: can't find getMarker() in 
org.jclouds.rds.options.ListSubnetGroupsOptions
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-javadoc-plugin:2.9:jar (javadoc) @ jclouds-labs-aws ---
[INFO] Not executing Javadoc as the project is not a Java classpath-capable 
package
[INFO] 
[INFO] --- maven-source-plugin:2.2:jar-no-fork (attach-sources) @ 
jclouds-labs-aws ---
[INFO] 
[INFO] --- maven-source-plugin:2.2:test-jar-no-fork (attach-sources) @ 
jclouds-labs-aws ---
[INFO] 
[INFO] --- maven-surefire-plugin:2.17:test (integration) @ jclouds-labs-aws ---
[INFO] Toolchain in surefire-plugin: JDK[/home/jenkins/tools/java/latest1.8/]
[INFO] No tests to run.
[JENKINS] Recording test results
[INFO] 
[INFO] --- duplicate-finder-maven-plugin:1.1.2:check (default) @ 
jclouds-labs-aws ---
[INFO] Ignoring POM project!
[INFO] 
[INFO] --- maven-checkstyle-plugin:3.0.0:check (default) @ jclouds-labs-aws ---
[INFO] Downloading from apache-snapshots: 
https://repository.apache.org/content/repositories/snapshots/org/apache/jclouds/jclouds-resources/2.3.0-SNAPSHOT/maven-metadata.xml
[INFO] Downloading from Nexus: 
http://repository.apache.org/snapshots/org/apache/jclouds/jclouds-resources/2.3.0-SNAPSHOT/maven-metadata.xml
[INFO] Downloaded from apache-snapshots: 
https://repository.apache.org/content/repositories/snapshots/org/apache/jclouds/jclouds-resources/2.3.0-SNAPSHOT/maven-metadata.xml
 (1.4 kB at 4.1 kB/s)
[INFO] Downloaded from Nexus: 
http://repository.apache.org/snapshots/org/apache/jclouds/jclouds-resources/2.3.0-SNAPSHOT/maven-metadata.xml
 (1.4 kB at 2.8 kB/s)
[INFO] Downloading from apache-snapshots: 
https://repository.apache.org/content/repositories/snapshots/org/apache/jclouds/jclouds-resources/2.3.0-SNAPSHOT/jclouds-resources-2.3.0-20200624.234013-26.pom
[INFO] Downloaded from apache-snapshots: 

Jenkins build is back to normal : jclouds #110

[Apache Jenkins Server]

See 

[GitHub] [jclouds] gaul commented on pull request #71: JCLOUDS-1545: Upgrade to OkHttp 2.7.5

[GitBox]

gaul commented on pull request #71:
URL: https://github.com/apache/jclouds/pull/71#issuecomment-649156109


   Never mind -- I was using an older version of OkHttp, 2.7.5.  Let me work 
forward...



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [jclouds] gaul commented on pull request #71: JCLOUDS-1545: Upgrade to OkHttp 2.7.5

[GitBox]

gaul commented on pull request #71:
URL: https://github.com/apache/jclouds/pull/71#issuecomment-649148516


   I looked into this a little further.  OkHttp uses bcprov-jdk15on 1.65 but 
aligning our version doesn't resolve the symptoms.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [jclouds/jclouds] JCLOUDS-1333: Require JDK 1.8 (#1197)

[Andrew Gaul]

Closed #1197.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1197#event-3479849597

Re: [jclouds/jclouds] JCLOUDS-1333: Require JDK 1.8 (#1197)

[Andrew Gaul]

Superseded by apache/jclouds#75.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1197#issuecomment-649141949

Re: [jclouds/jclouds] JCLOUDS-1473 add INTELLIGENT_TIERING enum (#1286)

[Andrew Gaul]

Superseded by apache/jclouds#77.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1286#issuecomment-649139605

Re: [jclouds/jclouds] JCLOUDS-1473 add INTELLIGENT_TIERING enum (#1286)

[Andrew Gaul]

Closed #1286.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1286#event-3479834367

[jira] [Resolved] (JCLOUDS-1473) S3 intelligent tiering

[Andrew Gaul (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul resolved JCLOUDS-1473.
--
Fix Version/s: 2.3.0
 Assignee: Andrew Gaul
   Resolution: Fixed

> S3 intelligent tiering
> --
>
> Key: JCLOUDS-1473
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1473
> Project: jclouds
>  Issue Type: New Feature
>  Components: jclouds-blobstore
>Affects Versions: 2.1.1
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
>Priority: Minor
>  Labels: s3
> Fix For: 2.3.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Recently announced:
>  
> https://aws.amazon.com/blogs/aws/new-automatic-cost-optimization-for-amazon-s3-via-intelligent-tiering/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JCLOUDS-1473) S3 intelligent tiering

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144547#comment-17144547
 ] 

ASF subversion and git services commented on JCLOUDS-1473:
--

Commit 8762fbaf8efca5568c32b8e74b0dac1297b3f59b in jclouds's branch 
refs/heads/master from Sam Ottenhoff
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=8762fba ]

JCLOUDS-1473 add INTELLIGENT_TIERING enum


> S3 intelligent tiering
> --
>
> Key: JCLOUDS-1473
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1473
> Project: jclouds
>  Issue Type: New Feature
>  Components: jclouds-blobstore
>Affects Versions: 2.1.1
>Reporter: Andrew Gaul
>Priority: Minor
>  Labels: s3
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Recently announced:
>  
> https://aws.amazon.com/blogs/aws/new-automatic-cost-optimization-for-amazon-s3-via-intelligent-tiering/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [jclouds] gaul merged pull request #77: JCLOUDS-1473 add INTELLIGENT_TIERING enum

[GitBox]

gaul merged pull request #77:
URL: https://github.com/apache/jclouds/pull/77


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Build failed in Jenkins: jclouds #109

[Apache Jenkins Server]

See 

Changes:

[andrew] JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22


--
[...truncated 762.02 KB...]
:140:
 error: self-closing element not allowed
 * 
   ^
:48:
 error: unknown tag: NovaApi
* ApiContext backendApi = computeContext.unwrap(new 
TypeToken>(){});
^
:48:
 error: malformed HTML
* ApiContext backendApi = computeContext.unwrap(new 
TypeToken>(){});
  ^
:48:
 error: unknown tag: NovaApi
* ApiContext backendApi = computeContext.unwrap(new 
TypeToken>(){});

 ^
:48:
 error: bad use of '>'
* ApiContext backendApi = computeContext.unwrap(new 
TypeToken>(){});

  ^
:27:
 error: self-closing element not allowed
 * 
   ^
:38:
 error: self-closing element not allowed
 * @see http://en.wikipedia.org/wiki/Basic_access_authentication; />
^
:45:
 error: reference not found
* @see org.jclouds.Constants.PROPERTY_MAX_RETRIES
   ^
:86:
 error: reference not found
* @see org.jclouds.Constants.PROPERTY_MAX_REDIRECTS
   ^
:20:
 error: bad use of '>'
 * Indicate whether a request should be retried after a server error response 
(HTTP status code >=

^
:157:
 error: exception not thrown: java.io.IOException
* @throws IOException
  ^
:81:
 error: @param name not found
* @param in
 ^
:55:
 error: header used out of sequence: 
 * Reminder
   ^
:111:
 error: @param name not found
   * @param scheme
^
:43:
 error: reference not found
 * 50 * ({@link TransformingHttpCommand#getFailureCount()} ^ 
2). For example:
 ^
:69:
 error: no summary or caption for table
 * 
   ^
:72:
 error: reference not found
 * {@link TransformingHttpCommand#incrementFailureCount()}, because this 
failure count value is used
  ^
:26:
 error: reference not found
 * designates the the module configures a {@link HttpCommandExecutorService}
 ^
:94:
 error: self-closing element not allowed
* 
  ^
:104:
 error: self-closing element not allowed
* 
  ^
:117:
 error: self-closing element not allowed
* 
  ^
:129:
 error: self-closing element not allowed
* 
  ^
:142:
 error: self-closing element not allowed
* 
  ^

[jira] [Resolved] (JCLOUDS-1470) Vulnarable Guava dependency dragged from jclouds-driver

[Andrew Gaul (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul resolved JCLOUDS-1470.
--
Fix Version/s: 2.3.0
 Assignee: Andrew Gaul
   Resolution: Fixed

> Vulnarable Guava dependency dragged from jclouds-driver
> ---
>
> Key: JCLOUDS-1470
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1470
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-core
>Affects Versions: 2.1.1
>Reporter: Blagoi Anastasov
>Assignee: Andrew Gaul
>Priority: Major
>  Labels: guava
> Fix For: 2.3.0
>
>
> It looks like jclouds-driver drags old(from 2014) and vulnerable guava 
> dependency - 18.0.
> [https://nvd.nist.gov/view/vuln/search-results?adv_search=true=on_version=cpe%3A%2Fa%3Agoogle%3Aguava%3A18.0]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JCLOUDS-1333) Cannot compile jclouds with Guava 21+

[Andrew Gaul (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul resolved JCLOUDS-1333.
--
Fix Version/s: 2.3.0
 Assignee: Andrew Gaul
   Resolution: Fixed

> Cannot compile jclouds with Guava 21+
> -
>
> Key: JCLOUDS-1333
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1333
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-core
>Affects Versions: 2.1.0
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
>Priority: Major
>  Labels: guava
> Fix For: 2.3.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> jclouds has compatibility with Guava 18-22 but we cannot compile using 21+ 
> due to some kind of Guava vs Java 8 Function class type error:
> {noformat}
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/rest/internal/TransformerForRequest.java:102:
>  error: method compose in interface java.util.function.Function cannot 
> be applied to given types;
>  transformer = compose(Function.class.cast(wrappingTransformer), 
> transformer);
>^
>   required: java.util.function.Function
>   found:
> com.google.common.base.Function,com.google.common.base.Function
>   reason: cannot infer type-variable(s) V
> (actual and formal argument lists differ in length)
>   where V,T,R are type-variables:
> V extends Object declared in method 
> compose(java.util.function.Function)
> T extends Object declared in interface java.util.function.Function
> R extends Object declared in interface java.util.function.Function
>   where CAP#1 is a fresh type-variable:
> CAP#1 extends Object from capture of ?
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/rest/internal/TransformerForRequest.java:189:
>  error: method compose in interface java.util.function.Function cannot 
> be applied to given types;
> transformer = compose(new OnlyElementOrNull(), transformer);
>   ^
>   required: java.util.function.Function
>   found:
> OnlyElementOrNull,com.google.common.base.Function
>   reason: cannot infer type-variable(s) V
> (actual and formal argument lists differ in length)
>   where V,T,R are type-variables:
> V extends Object declared in method 
> compose(java.util.function.Function)
> T extends Object declared in interface java.util.function.Function
> R extends Object declared in interface java.util.function.Function
>   where CAP#1 is a fresh type-variable:
> CAP#1 extends Object from capture of ?
> {noformat}
> This does not affect applications from using Guava 21-22 but does impact our 
> compatibility testing.  Note that you need to set {{maven.compile.source}} to 
> 1.8 to test Guava 21+.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [jclouds] gaul merged pull request #75: JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22

[GitBox]

gaul merged pull request #75:
URL: https://github.com/apache/jclouds/pull/75


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (JCLOUDS-1334) Guava 23.0 incompatibility: missing SimpleTimeLimiter constructor

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144476#comment-17144476
 ] 

ASF subversion and git services commented on JCLOUDS-1334:
--

Commit 62767a14610fc1c97c440dbd5ee0f02b276a1069 in jclouds's branch 
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=62767a1 ]

JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22

This allows compatibility with Guava 29.  Also unwind some older
workarounds.


> Guava 23.0 incompatibility: missing SimpleTimeLimiter constructor
> -
>
> Key: JCLOUDS-1334
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1334
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-core
>Reporter: Tim Peierls
>Assignee: Andrew Gaul
>Priority: Minor
>  Labels: guava
> Fix For: 2.1.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> With Guava 23, the public constructor for SimpleTimeLimiter, which was 
> deprecated in Guava 22.0, has been removed. This constructor is used by 
> JClouds' ExecutorServiceModule and by some tests.
> Tests won't be compiled under Guava 23, so that's not a concern, but anyone 
> running JClouds with Guava 23 will get a runtime error when 
> ExecutorServiceModule is loaded.
> Easiest fix is to use reflection to call SimpleTimeLimiter.create (introduced 
> in Guava 22.0) if possible, and fall back to the constructor otherwise.
> This was noticed after the resolution of JCLOUDS-1225, which brought 
> compatibility to Guava 22.0.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JCLOUDS-1470) Vulnarable Guava dependency dragged from jclouds-driver

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144477#comment-17144477
 ] 

ASF subversion and git services commented on JCLOUDS-1470:
--

Commit 62767a14610fc1c97c440dbd5ee0f02b276a1069 in jclouds's branch 
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=62767a1 ]

JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22

This allows compatibility with Guava 29.  Also unwind some older
workarounds.


> Vulnarable Guava dependency dragged from jclouds-driver
> ---
>
> Key: JCLOUDS-1470
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1470
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-core
>Affects Versions: 2.1.1
>Reporter: Blagoi Anastasov
>Priority: Major
>  Labels: guava
>
> It looks like jclouds-driver drags old(from 2014) and vulnerable guava 
> dependency - 18.0.
> [https://nvd.nist.gov/view/vuln/search-results?adv_search=true=on_version=cpe%3A%2Fa%3Agoogle%3Aguava%3A18.0]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JCLOUDS-1333) Cannot compile jclouds with Guava 21+

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144475#comment-17144475
 ] 

ASF subversion and git services commented on JCLOUDS-1333:
--

Commit 62767a14610fc1c97c440dbd5ee0f02b276a1069 in jclouds's branch 
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=62767a1 ]

JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22

This allows compatibility with Guava 29.  Also unwind some older
workarounds.


> Cannot compile jclouds with Guava 21+
> -
>
> Key: JCLOUDS-1333
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1333
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-core
>Affects Versions: 2.1.0
>Reporter: Andrew Gaul
>Priority: Major
>  Labels: guava
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> jclouds has compatibility with Guava 18-22 but we cannot compile using 21+ 
> due to some kind of Guava vs Java 8 Function class type error:
> {noformat}
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/rest/internal/TransformerForRequest.java:102:
>  error: method compose in interface java.util.function.Function cannot 
> be applied to given types;
>  transformer = compose(Function.class.cast(wrappingTransformer), 
> transformer);
>^
>   required: java.util.function.Function
>   found:
> com.google.common.base.Function,com.google.common.base.Function
>   reason: cannot infer type-variable(s) V
> (actual and formal argument lists differ in length)
>   where V,T,R are type-variables:
> V extends Object declared in method 
> compose(java.util.function.Function)
> T extends Object declared in interface java.util.function.Function
> R extends Object declared in interface java.util.function.Function
>   where CAP#1 is a fresh type-variable:
> CAP#1 extends Object from capture of ?
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/rest/internal/TransformerForRequest.java:189:
>  error: method compose in interface java.util.function.Function cannot 
> be applied to given types;
> transformer = compose(new OnlyElementOrNull(), transformer);
>   ^
>   required: java.util.function.Function
>   found:
> OnlyElementOrNull,com.google.common.base.Function
>   reason: cannot infer type-variable(s) V
> (actual and formal argument lists differ in length)
>   where V,T,R are type-variables:
> V extends Object declared in method 
> compose(java.util.function.Function)
> T extends Object declared in interface java.util.function.Function
> R extends Object declared in interface java.util.function.Function
>   where CAP#1 is a fresh type-variable:
> CAP#1 extends Object from capture of ?
> {noformat}
> This does not affect applications from using Guava 21-22 but does impact our 
> compatibility testing.  Note that you need to set {{maven.compile.source}} to 
> 1.8 to test Guava 21+.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [jclouds] ottenhoff opened a new pull request #77: JCLOUDS-1473 add INTELLIGENT_TIERING enum

[GitBox]

ottenhoff opened a new pull request #77:
URL: https://github.com/apache/jclouds/pull/77


   To solve the following stacktrace:
   
   `java.lang.IllegalArgumentException: No enum constant 
org.jclouds.s3.domain.ObjectMetadata.StorageClass.INTELLIGENT_TIERING
   at java.lang.Enum.valueOf(Enum.java:238)
   at 
org.jclouds.s3.domain.ObjectMetadata$StorageClass.valueOf(ObjectMetadata.java:36)
   at 
org.jclouds.s3.functions.ParseObjectMetadataFromHeaders.apply(ParseObjectMetadataFromHeaders.java:81)
   at 
org.jclouds.s3.functions.ParseObjectFromHeadersAndHttpContent.apply(ParseObjectFromHeadersAndHttpContent.java:48)
   at 
org.jclouds.s3.functions.ParseObjectFromHeadersAndHttpContent.apply(ParseObjectFromHeadersAndHttpContent.java:34)
   at 
org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:91)
   at 
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:74)
   at 
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:45)
   at 
org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
   at 
org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
   at com.sun.proxy.$Proxy150.getObject(Unknown Source)
   at org.jclouds.s3.blobstore.S3BlobStore.getBlob(S3BlobStore.java:235)
   at 
org.jclouds.blobstore.internal.BaseBlobStore.getBlob(BaseBlobStore.java:217)`



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [jclouds/jclouds] JCLOUDS-1473 add INTELLIGENT_TIERING enum (#1286)

[Andrew Phillips]

Thanks for submitting this, @ottenhoff! This repository is archived, could you 
kindly reopen this over at [apache/jclouds](https://github.com/apache/jclouds)?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1286#issuecomment-649087937

[GitHub] [jclouds] nacx commented on pull request #75: JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22

[GitBox]

nacx commented on pull request #75:
URL: https://github.com/apache/jclouds/pull/75#issuecomment-649026516


   Nope, LGTM. Thanks!



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jclouds/jclouds] JCLOUDS-1473 add INTELLIGENT_TIERING enum (#1286)

[Sam Ottenhoff]

Solves the following stacktrace:

 java.lang.IllegalArgumentException: No enum constant 
org.jclouds.s3.domain.ObjectMetadata.StorageClass.INTELLIGENT_TIERING
at java.lang.Enum.valueOf(Enum.java:238)
at 
org.jclouds.s3.domain.ObjectMetadata$StorageClass.valueOf(ObjectMetadata.java:36)
at 
org.jclouds.s3.functions.ParseObjectMetadataFromHeaders.apply(ParseObjectMetadataFromHeaders.java:81)
at 
org.jclouds.s3.functions.ParseObjectFromHeadersAndHttpContent.apply(ParseObjectFromHeadersAndHttpContent.java:48)
at 
org.jclouds.s3.functions.ParseObjectFromHeadersAndHttpContent.apply(ParseObjectFromHeadersAndHttpContent.java:34)
at 
org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:91)
at 
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:74)
at 
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:45)
at 
org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
at 
org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
at com.sun.proxy.$Proxy150.getObject(Unknown Source)
at org.jclouds.s3.blobstore.S3BlobStore.getBlob(S3BlobStore.java:235)
at 
org.jclouds.blobstore.internal.BaseBlobStore.getBlob(BaseBlobStore.java:217)
at 
coza.opencollab.sakai.cloudcontent.BlobStoreFileSystemHandler.getInputStream(BlobStoreFileSystemHandler.java:250)
You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/1286

-- Commit Summary --

  * JCLOUDS-1473 add INTELLIGENT_TIERING enum

-- File Changes --

M apis/s3/src/main/java/org/jclouds/s3/domain/ObjectMetadata.java (1)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/1286.patch
https://github.com/jclouds/jclouds/pull/1286.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1286

[GitHub] [jclouds] gaul commented on pull request #75: JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22

[GitBox]

gaul commented on pull request #75:
URL: https://github.com/apache/jclouds/pull/75#issuecomment-648842815


   @nacx Any further comments?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (JCLOUDS-1548) GSON Cleanup, GSON replacement through Jackson

[Andrew Gaul (Jira)]

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143739#comment-17143739
 ] 

Andrew Gaul commented on JCLOUDS-1548:
--

[~gurkerl83] Thanks for raising this!  We are aware how jclouds usage of the 
gson library challenges users and I raised this as one of the dependencies to 
fix in 2.3.0:

https://lists.apache.org/thread.html/rab068ec72653993b5336ebf9325ba1e357b2eba96d5fb87c0de1f091%40%3Cuser.jclouds.apache.org%3E

However, our team lacks the background in OSGi and time to fix this properly.  
We would gladly consider an alternate approach if you can suggest a pull 
request.

> GSON Cleanup, GSON replacement through Jackson
> --
>
> Key: JCLOUDS-1548
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1548
> Project: jclouds
>  Issue Type: New Feature
>  Components: jclouds-core
>Affects Versions: 2.2.1
>Reporter: Markus Gritsch
>Priority: Major
> Fix For: 2.3.0
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> *The issues listed in the following proposal must be seen as an approach to a 
> difficult problem and should by no means be understood as criticism of the 
> developer.*
> In the discussion leading up to the following merge request, GSON as a 
> library in use was classified as problematic. In the discussion GSON was 
> considered in the context of OSGi-based runtime environments and an 
> incompatibility regarding GSON was found.
> In short, the vendor of the GSON library refuses to include further OSGI 
> meta-information to mark any packages of the library as public.
> In order to achieve compatibility between GSON and OSGi the way was taken to 
> substitute package names.
> At first sight a substitution of this kind (GSON is included in a separate 
> module) is relatively simple, which is then consumed by the actual JCLOUDS 
> code base (estimated complexity level 3 of 10).
> However, a closer look at the JCLOUDS code base reveals that there is more 
> than just a pure substitution of the package name.
> *Why is it necessary to access package names declared as private?*
> CLOUDS extends GSON with features not provided by the original GSON library. 
> This leads to the following critical problems with regard to maintainability 
> over a long time frame.
>  - Corresponding GSON enhancing functions were long ago included in the 
> source code of JCLOUD.
>  - Even if you take a closer look at them, it is very difficult to understand 
> their function. Those responsible may have stopped further development of the 
> project.
> Simple updates of dependencies are not possible because side effects have to 
> be estimated directly from the additional functions and fixed in case of 
> incompatibility (estimated level of complexity 8 out of 10).
>  The actual, to the question independent of the discussion OSGi or not, we 
> should clarify largely the effect of the introduced additional function 
> really is or whether it can not be removed.
> *Here are a few examples*
>  - JsonBall and NullHackJsonLiteralAdapter
>  - Structure and classification of type adaptors in general
> Further questions deal with the way GSON handles certain constellations of 
> data, for example the de-serialization in GSON from number to double type.
> In the long run, when using a library, the quality and community of the 
> library used must be taken into account. Google's projects in the areas of 
> handling JSON-based data structures (GSON) and dependency injection (Guice) 
> have lost a lot of development speed and willingness to take feedback from 
> the community. This is my personal opinion from past projects.
> *Attempted solution approach*
>  After the first step, the introduction into the JCLOUDS library (status: 
> completed) I will now work on the replacement of GSON by Jackson (status: 
> started). If this step should be too advanced or unconsidered I would like to 
> ask for feedback from other developers in the community.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JCLOUDS-1548) GSON Cleanup, GSON replacement through Jackson

[Markus Gritsch (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Gritsch updated JCLOUDS-1548:

Description: 
The issues listed in the following proposal must be seen as an approach to a 
difficult problem and should by no means be understood as criticism of the 
developer.

In the discussion leading up to the following merge request, GSON as a library 
in use was classified as problematic. In the discussion GSON was considered in 
the context of OSGi-based runtime environments and an incompatibility regarding 
GSON was found.

In short, the vendor of the GSON library refuses to include further OSGI 
meta-information to mark any packages of the library as public.

In order to achieve compatibility between GSON and OSGi the way was taken to 
substitute package names.

At first sight a substitution of this kind (GSON is included in a separate 
module) is relatively simple, which is then consumed by the actual JCLOUDS code 
base (estimated complexity level 3 of 10).

However, a closer look at the JCLOUDS code base reveals that there is more than 
just a pure substitution of the package name.

*Why is it necessary to access package names declared as private?*

CLOUDS extends GSON with features not provided by the original GSON library. 
This leads to the following critical problems with regard to maintainability 
over a long time frame.
 - Corresponding GSON enhancing functions were long ago included in the source 
code of JCLOUD.
 - Even if you take a closer look at them, it is very difficult to understand 
their function. Those responsible may have stopped further development of the 
project.

Simple updates of dependencies are not possible because side effects have to be 
estimated directly from the additional functions and fixed in case of 
incompatibility (estimated level of complexity 8 out of 10).
 The actual, to the question independent of the discussion OSGi or not, we 
should clarify largely the effect of the introduced additional function really 
is or whether it can not be removed.

*Here are a few examples*
 - JsonBall and NullHackJsonLiteralAdapter
 - Structure and classification of type adaptors in general

Further questions deal with the way GSON handles certain constellations of 
data, for example the de-serialization in GSON from number to double type.

In the long run, when using a library, the quality and community of the library 
used must be taken into account. Google's projects in the areas of handling 
JSON-based data structures (GSON) and dependency injection (Guice) have lost a 
lot of development speed and willingness to take feedback from the community. 
This is my personal opinion from past projects.

*Attempted solution approach*
 After the first step, the introduction into the JCLOUDS library (status: 
completed) I will now work on the replacement of GSON by Jackson (status: 
started). If this step should be too advanced or unconsidered I would like to 
ask for feedback from other developers in the community.

  was:
The issues listed in the following proposal must be seen as an approach to a 
difficult problem and should by no means be understood as criticism of the 
developer.

In the discussion leading up to the following merge request, GSON as a library 
in use was classified as problematic. In the discussion GSON was considered in 
the context of OSGi-based runtime environments and an incompatibility regarding 
GSON was found.

In short, the vendor of the GSON library refuses to include further OSGI 
meta-information to mark any packages of the library as public.

In order to achieve compatibility between GSON and OSGi the way was taken to 
substitute package names.

At first sight a substitution of this kind (GSON is included in a separate 
module) is relatively simple, which is then consumed by the actual JCLOUDS code 
base (estimated complexity level 3 of 10).

However, a closer look at the JCLOUDS code base reveals that there is more than 
just a pure substitution of the package name.

Why is it necessary to access package names declared as private?

CLOUDS extends GSON with features not provided by the original GSON library. 
This leads to the following critical problems with regard to maintainability 
over a long time frame.
 - Corresponding GSON enhancing functions were long ago included in the source 
code of JCLOUD.
 - Even if you take a closer look at them, it is very difficult to understand 
their function. Those responsible may have stopped further development of the 
project.

Simple updates of dependencies are not possible because side effects have to be 
estimated directly from the additional functions and fixed in case of 
incompatibility (estimated level of complexity 8 out of 10).
 The actual, to the question independent of the discussion OSGi or not, we 
should clarify largely the effect of the introduced additional function really 
is or 

[jira] [Updated] (JCLOUDS-1548) GSON Cleanup, GSON replacement through Jackson

[Markus Gritsch (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Gritsch updated JCLOUDS-1548:

Description: 
*The issues listed in the following proposal must be seen as an approach to a 
difficult problem and should by no means be understood as criticism of the 
developer.*

In the discussion leading up to the following merge request, GSON as a library 
in use was classified as problematic. In the discussion GSON was considered in 
the context of OSGi-based runtime environments and an incompatibility regarding 
GSON was found.

In short, the vendor of the GSON library refuses to include further OSGI 
meta-information to mark any packages of the library as public.

In order to achieve compatibility between GSON and OSGi the way was taken to 
substitute package names.

At first sight a substitution of this kind (GSON is included in a separate 
module) is relatively simple, which is then consumed by the actual JCLOUDS code 
base (estimated complexity level 3 of 10).

However, a closer look at the JCLOUDS code base reveals that there is more than 
just a pure substitution of the package name.

*Why is it necessary to access package names declared as private?*

CLOUDS extends GSON with features not provided by the original GSON library. 
This leads to the following critical problems with regard to maintainability 
over a long time frame.
 - Corresponding GSON enhancing functions were long ago included in the source 
code of JCLOUD.
 - Even if you take a closer look at them, it is very difficult to understand 
their function. Those responsible may have stopped further development of the 
project.

Simple updates of dependencies are not possible because side effects have to be 
estimated directly from the additional functions and fixed in case of 
incompatibility (estimated level of complexity 8 out of 10).
 The actual, to the question independent of the discussion OSGi or not, we 
should clarify largely the effect of the introduced additional function really 
is or whether it can not be removed.

*Here are a few examples*
 - JsonBall and NullHackJsonLiteralAdapter
 - Structure and classification of type adaptors in general

Further questions deal with the way GSON handles certain constellations of 
data, for example the de-serialization in GSON from number to double type.

In the long run, when using a library, the quality and community of the library 
used must be taken into account. Google's projects in the areas of handling 
JSON-based data structures (GSON) and dependency injection (Guice) have lost a 
lot of development speed and willingness to take feedback from the community. 
This is my personal opinion from past projects.

*Attempted solution approach*
 After the first step, the introduction into the JCLOUDS library (status: 
completed) I will now work on the replacement of GSON by Jackson (status: 
started). If this step should be too advanced or unconsidered I would like to 
ask for feedback from other developers in the community.

  was:
The issues listed in the following proposal must be seen as an approach to a 
difficult problem and should by no means be understood as criticism of the 
developer.

In the discussion leading up to the following merge request, GSON as a library 
in use was classified as problematic. In the discussion GSON was considered in 
the context of OSGi-based runtime environments and an incompatibility regarding 
GSON was found.

In short, the vendor of the GSON library refuses to include further OSGI 
meta-information to mark any packages of the library as public.

In order to achieve compatibility between GSON and OSGi the way was taken to 
substitute package names.

At first sight a substitution of this kind (GSON is included in a separate 
module) is relatively simple, which is then consumed by the actual JCLOUDS code 
base (estimated complexity level 3 of 10).

However, a closer look at the JCLOUDS code base reveals that there is more than 
just a pure substitution of the package name.

*Why is it necessary to access package names declared as private?*

CLOUDS extends GSON with features not provided by the original GSON library. 
This leads to the following critical problems with regard to maintainability 
over a long time frame.
 - Corresponding GSON enhancing functions were long ago included in the source 
code of JCLOUD.
 - Even if you take a closer look at them, it is very difficult to understand 
their function. Those responsible may have stopped further development of the 
project.

Simple updates of dependencies are not possible because side effects have to be 
estimated directly from the additional functions and fixed in case of 
incompatibility (estimated level of complexity 8 out of 10).
 The actual, to the question independent of the discussion OSGi or not, we 
should clarify largely the effect of the introduced additional function really 
is or 

[jira] [Updated] (JCLOUDS-1548) GSON Cleanup, GSON replacement through Jackson

[Markus Gritsch (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Gritsch updated JCLOUDS-1548:

Description: 
The issues listed in the following proposal must be seen as an approach to a 
difficult problem and should by no means be understood as criticism of the 
developer.

In the discussion leading up to the following merge request, GSON as a library 
in use was classified as problematic. In the discussion GSON was considered in 
the context of OSGi-based runtime environments and an incompatibility regarding 
GSON was found.

In short, the vendor of the GSON library refuses to include further OSGI 
meta-information to mark any packages of the library as public.

In order to achieve compatibility between GSON and OSGi the way was taken to 
substitute package names.

At first sight a substitution of this kind (GSON is included in a separate 
module) is relatively simple, which is then consumed by the actual JCLOUDS code 
base (estimated complexity level 3 of 10).

However, a closer look at the JCLOUDS code base reveals that there is more than 
just a pure substitution of the package name.

Why is it necessary to access package names declared as private?

CLOUDS extends GSON with features not provided by the original GSON library. 
This leads to the following critical problems with regard to maintainability 
over a long time frame.
 - Corresponding GSON enhancing functions were long ago included in the source 
code of JCLOUD.
 - Even if you take a closer look at them, it is very difficult to understand 
their function. Those responsible may have stopped further development of the 
project.

Simple updates of dependencies are not possible because side effects have to be 
estimated directly from the additional functions and fixed in case of 
incompatibility (estimated level of complexity 8 out of 10).
 The actual, to the question independent of the discussion OSGi or not, we 
should clarify largely the effect of the introduced additional function really 
is or whether it can not be removed.

Here are a few examples
 - JsonBall and NullHackJsonLiteralAdapter
 - Structure and classification of type adaptors in general

Further questions deal with the way GSON handles certain constellations of 
data, for example the de-serialization in GSON from number to double type.

In the long run, when using a library, the quality and community of the library 
used must be taken into account. Google's projects in the areas of handling 
JSON-based data structures (GSON) and dependency injection (Guice) have lost a 
lot of development speed and willingness to take feedback from the community. 
This is my personal opinion from past projects.

Attempted solution approach
 After the first step, the introduction into the JCLOUDS library (status: 
completed) I will now work on the replacement of GSON by Jackson (status: 
started). If this step should be too advanced or unconsidered I would like to 
ask for feedback from other developers in the community.

  was:
The issues listed in the following proposal must be seen as an approach to a 
difficult problem and should by no means be understood as criticism of the 
developer.

In the discussion leading up to the following merge request, GSON as a library 
in use was classified as problematic. In the discussion GSON was considered in 
the context of OSGi-based runtime environments and an incompatibility regarding 
GSON was found.

In short, the vendor of the GSON library refuses to include further OSGI 
meta-information to mark any packages of the library as public.

In order to achieve compatibility between GSON and OSGi the way was taken to 
substitute package names.

At first sight a substitution of this kind (GSON is included in a separate 
module) is relatively simple, which is then consumed by the actual JCLOUDS code 
base (estimated complexity level 3 of 10).

However, a closer look at the JCLOUDS code base reveals that there is more than 
just a pure substitution of the package name.

Why is it necessary to access package names declared as private?

CLOUDS extends GSON with features not provided by the original GSON library. 
This leads to the following critical problems with regard to maintainability 
over a long time frame.

- Corresponding GSON enhancing functions were long ago included in the source 
code of JCLOUD.
- Even if you take a closer look at them, it is very difficult to understand 
their function. Those responsible may have stopped further development of the 
project.

Simple updates of dependencies are not possible because side effects have to be 
estimated directly from the additional functions and fixed in case of 
incompatibility (estimated level of complexity 8 out of 10).
The actual, to the question independent of the discussion OSGi or not, we 
should clarify largely the effect of the introduced additional function really 
is or whether it 

[jira] [Created] (JCLOUDS-1548) GSON Cleanup, GSON replacement through Jackson

[Markus Gritsch (Jira)]

Markus Gritsch created JCLOUDS-1548:
---

 Summary: GSON Cleanup, GSON replacement through Jackson
 Key: JCLOUDS-1548
 URL: https://issues.apache.org/jira/browse/JCLOUDS-1548
 Project: jclouds
  Issue Type: New Feature
  Components: jclouds-core
Affects Versions: 2.2.1
Reporter: Markus Gritsch
 Fix For: 2.3.0


The issues listed in the following proposal must be seen as an approach to a 
difficult problem and should by no means be understood as criticism of the 
developer.

In the discussion leading up to the following merge request, GSON as a library 
in use was classified as problematic. In the discussion GSON was considered in 
the context of OSGi-based runtime environments and an incompatibility regarding 
GSON was found.

In short, the vendor of the GSON library refuses to include further OSGI 
meta-information to mark any packages of the library as public.

In order to achieve compatibility between GSON and OSGi the way was taken to 
substitute package names.

At first sight a substitution of this kind (GSON is included in a separate 
module) is relatively simple, which is then consumed by the actual JCLOUDS code 
base (estimated complexity level 3 of 10).

However, a closer look at the JCLOUDS code base reveals that there is more than 
just a pure substitution of the package name.

Why is it necessary to access package names declared as private?

CLOUDS extends GSON with features not provided by the original GSON library. 
This leads to the following critical problems with regard to maintainability 
over a long time frame.

- Corresponding GSON enhancing functions were long ago included in the source 
code of JCLOUD.
- Even if you take a closer look at them, it is very difficult to understand 
their function. Those responsible may have stopped further development of the 
project.

Simple updates of dependencies are not possible because side effects have to be 
estimated directly from the additional functions and fixed in case of 
incompatibility (estimated level of complexity 8 out of 10).
The actual, to the question independent of the discussion OSGi or not, we 
should clarify largely the effect of the introduced additional function really 
is or whether it can not be removed.


Here are a few examples
- JsonBall and NullHackJsonLiteralAdapter
- Structure and classification of type adaptors in general

Further questions deal with the way GSON handles certain constellations of 
data, for example the de-serialization in GSON from number to double type.

In the long run, when using a library, the quality and community of the library 
used must be taken into account. Google's projects in the areas of handling 
JSON-based data structures (GSON) and dependency injection (Guice) have lost a 
lot of development speed and willingness to take feedback from the community. 
This is my personal opinion from past projects.

Attempted solution approach
After the first step, the introduction into the JCLOUDS library (status: 
completed) I will now work on the replacement of GSON by Jackson (status: 
started). If this step should be too advanced or unconsidered I would like to 
ask for feedback from other developers in the community.

Translated with www.DeepL.com/Translator (free version)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)