[ https://issues.apache.org/jira/browse/JCLOUDS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168851#comment-14168851 ]
Chris Custine commented on JCLOUDS-747: --------------------------------------- I agree that we should at least stop the door from slamming on potential Android development even if we have nothing concrete going right now. I know several people on the project have talked about wanting to work on this for some time now, so I think we should give it a fighting chance. As I said in my email, I think this subject is fairly well documented wrt language features and sdk versions so it shouldn't be too difficult to draw up some guidelines on maintaining Android compatibility. > 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)