You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Ignasi Barrera (JIRA)" <ji...@apache.org> on 2014/11/27 18:11:12 UTC

[jira] [Commented] (JCLOUDS-747) Determine level of android support and how to ensure we keep it.

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

Ignasi Barrera commented on JCLOUDS-747:
----------------------------------------

This PR introduces the Animal Sniffer plugin to check runtime compatibility: https://github.com/jclouds/jclouds/pull/617

> Determine level of android support and how to ensure we keep it.
> ----------------------------------------------------------------
>
>                 Key: JCLOUDS-747
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-747
>             Project: jclouds
>          Issue Type: Improvement
>          Components: jclouds-core
>            Reporter: Adrian Cole
>
> One of the knock-on effects of moving on is tracking how we deal with android. One way is to establish a floor android level we aim to support (even if it is best efforts). That's due to the fact that android != java and only a subset of features are present, on each version. Here's a handy link that begins to discuss this complexity.
> http://stackoverflow.com/questions/20480090/does-android-support-jdk-6-or-7
> Modern android libraries typically use a combination of plugins and integration tests to ensure android isn't accidentally broken. Some projects just rely on folks to remember the rules.
> Here's an example of a signature-checking plugin
> {code}
>       <plugin>
>         <groupId>org.codehaus.mojo</groupId>
>         <artifactId>animal-sniffer-maven-plugin</artifactId>
>         <version>${animal.sniffer.version}</version>
>         <executions>
>           <execution>
>             <phase>test</phase>
>             <goals>
>               <goal>check</goal>
>             </goals>
>           </execution>
>         </executions>
>         <configuration>
>           <signature>
>             <groupId>org.codehaus.mojo.signature</groupId>
>             <artifactId>java16</artifactId>
>             <version>1.1</version>
>           </signature>
>         </configuration>
>       </plugin>
> {code}
> In short, I think we should be careful and consciously decide whether certain features that break some level of android support are worthwhile. We should also note that entrypoints that aren't used by android callers will not affect compatibility. In other words, we are most concerned with the common paths.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)