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

["Adrian Cole (JIRA)" <ji...@apache.org>]

Adrian Cole created JCLOUDS-747:
-----------------------------------

             Summary: 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)