You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Ignasi Barrera <na...@apache.org> on 2016/03/09 17:26:03 UTC
Compatibility report between jclouds versions
Hi!
Pull request #934 [1] links to this interesting tool to analyze the
compatibility between versions of a library:
https://github.com/lvc/japi-compliance-checker
I found it quite interesting and run the compatibility check between
jclouds 1.9.2 and 2.0.0-SNAPSHOT. I included all jclouds jars in the
comparison and the resulting HTML file is quite big (27MB) so it will
take a while to load in the browser:
https://storage.googleapis.com/jclouds-compat/index.html
If we find this kind of reports are useful, we could considering
including them as part of the release notes.
I.
[1] https://github.com/jclouds/jclouds/pull/934
Re: Compatibility report between jclouds versions
Posted by Ignasi Barrera <na...@apache.org>.
According to the help output, we could work that out. We could find
all beta classes and generate the list of classes to exclude.
We could also exclude deprecated classes, but I wouldn't. Deprecated
methods are the most important ones to remain compatible!
-skip-deprecated
Skip analysis of deprecated methods and classes.
-skip-classes PATH
This option allows to specify a file with a list
of classes that should not be checked.
-skip-packages PATH
This option allows to specify a file with a list
of packages that should not be checked.
On 10 March 2016 at 15:51, Andrew Phillips <an...@apache.org> wrote:
>> Yes, this is just a PoC. The tool has a "skip deprecated" flag to
>> exclude deprecated methods from the report.
>
>
> Do you know if there's a way to configure it to exclude "custom" things,
> such as classes annotated with @Beta?
>
> Regards
>
> ap
Re: Compatibility report between jclouds versions
Posted by Andrew Phillips <an...@apache.org>.
> Yes, this is just a PoC. The tool has a "skip deprecated" flag to
> exclude deprecated methods from the report.
Do you know if there's a way to configure it to exclude "custom" things,
such as classes annotated with @Beta?
Regards
ap
Re: Compatibility report between jclouds versions
Posted by Ignasi Barrera <na...@apache.org>.
Yes, this is just a PoC. The tool has a "skip deprecated" flag to
exclude deprecated methods from the report.
Tests can easily be excluded. I've just launched the check against all
jars found in the ~/.m2/repository/org/apache/jclouds folder for the
analysed versions, so it has picked the "-tests" jars too.
It as also included jars from all labs repos, where we don't care that
much about backwards compatibility.
Just wanted to share the tool and an example report (which I like),
and see if it could be useful to include it as part of the release
notes.
On 9 March 2016 at 21:54, Andrew Gaul <ga...@apache.org> wrote:
> On Wed, Mar 09, 2016 at 01:50:40PM -0500, Andrew Phillips wrote:
>> package org.jclouds.azureblob
>> [+] AzureBlobClient.copyBlob ( URI p1, String p2, String p3,
>> CopyBlobOptions p4 ) [abstract] : void (1)
>
> I changed this method to return the ETag from the response. It is not
> binary compatible but is source compatible with previous releases.
>
>> package org.jclouds.blobstore.options
>> CopyOptions.Builder.contentMetadata ( ContentMetadata
>> contentMetadata ) : CopyOptions.Builder (1)
>> CopyOptions.Builder.userMetadata ( Map<String,String> userMetadata )
>> : CopyOptions.Builder (1)
>
> These method break source compatibility but CopyOptions has a @Beta
> annotation.
>
>> Are these actually "real" problems, or false positives?
>
> This report has a lot of noise due to tests. Can we exclude these?
> Many of the removal warnings have proper deprecation tags although
> others like CloudFilesBlobStore were deprecated via informal means.
>
> --
> Andrew Gaul
> http://gaul.org/
Re: Compatibility report between jclouds versions
Posted by Andrew Gaul <ga...@apache.org>.
On Wed, Mar 09, 2016 at 01:50:40PM -0500, Andrew Phillips wrote:
> package org.jclouds.azureblob
> [+] AzureBlobClient.copyBlob ( URI p1, String p2, String p3,
> CopyBlobOptions p4 ) [abstract] : void (1)
I changed this method to return the ETag from the response. It is not
binary compatible but is source compatible with previous releases.
> package org.jclouds.blobstore.options
> CopyOptions.Builder.contentMetadata ( ContentMetadata
> contentMetadata ) : CopyOptions.Builder (1)
> CopyOptions.Builder.userMetadata ( Map<String,String> userMetadata )
> : CopyOptions.Builder (1)
These method break source compatibility but CopyOptions has a @Beta
annotation.
> Are these actually "real" problems, or false positives?
This report has a lot of noise due to tests. Can we exclude these?
Many of the removal warnings have proper deprecation tags although
others like CloudFilesBlobStore were deprecated via informal means.
--
Andrew Gaul
http://gaul.org/
Re: Compatibility report between jclouds versions
Posted by Andrew Phillips <an...@apache.org>.
> https://storage.googleapis.com/jclouds-compat/index.html
Thanks for this, Ignasi! Took a while to load, indeed ;-) I notice that
the three "High Severity" problems with methods it finds are:
package org.jclouds.azureblob
[+] AzureBlobClient.copyBlob ( URI p1, String p2, String p3,
CopyBlobOptions p4 ) [abstract] : void (1)
package org.jclouds.blobstore.options
CopyOptions.Builder.contentMetadata ( ContentMetadata contentMetadata )
: CopyOptions.Builder (1)
CopyOptions.Builder.userMetadata ( Map<String,String> userMetadata ) :
CopyOptions.Builder (1)
Are these actually "real" problems, or false positives?
Regards
ap