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)
