jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ignasi Barrera (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-747) Determine level of android support and how to ensure we keep it.
Date Thu, 27 Nov 2014 17:11:12 GMT

    [ 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

View raw message