Ceylon - Android compatibility plugin

[Festal David]

Hi all,

The Ceylon-Android compatibility plugin is now pushed to the development eclipse update site.

You will need to :
- Add the Ceylon nature to an Android project
- A Java Build Path error will appear, which is expected : follow the instructions given in the error text (-> moving down the Android-related build path entries)
- Import the Android platform jar (android.jar) into the ceylon repository : beware to keep the name 'android' for the Ceylon module
- Add a module.ceylon file and import the android module available since previous step,
- Write Ceylon code : it should be run without any problem.

Sources also have been pushed to the IDE master branch.

Thanks to Stéphane Gallès and Diego Coronel for testing it so quickly !

Please continue reporting any unexpected behavior.

David.

--

Regards,

David Festal

SERLI
Avenue Thomas Edison,
BP 20160,
86960 FUTUROSCOPE Cedex
Tél.: +33 6.22.54.08.19

[Gavin King]

David, is all the code for this now pushed to master?

> --
> You received this message because you are subscribed to the Google Groups
> "ceylon-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ceylon-dev+...@googlegroups.com.
> To post to this group, send email to ceylo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ceylon-dev.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Gavin King
ga...@ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

[David Festal]

Yes, it is.

Gavin King <gavin...@gmail.com> a écrit :

[Gavin King]

Great!

[Stephane Gallès]

Yes ! Thanks David, it works ! This is very nice.

With this new version of the IDE this is really the first time that I feel that I want to go beyond the simple Android+Ceylon POC. Next step : to try to
write something usefull with Ceylon+Android :)

Misc. remarks :

• The 'invisible R' problem seems to be solved, that's great news.
• Maybe you could remove the carriage return that's in the error text for the classpath modification. At first glance I thought that it was truncated (and I had to go to the 'properties' of the error message to see it in full)
  
• I think I've found a minor bug related to the filtering of the android.jar in the 'libs' dir. Actually, my imported jar module was indeed named 'android' with version 19 (because it is the android.jar of Android SDK 19). This breaks the filtering, and I ended up with a ceylonGenerated-android-19.jar  in the 'libs' directory. The filtering works if I use an imported module named 'android' with version 1.0.0.

BTW  to get the new compatibility feature it is not enough to simply update the IDE, one should also go to the Eclipse 'Install New Software' menu and check the new Android feature in the Ceylon install site. This is obvious, but I was bitten by this.

[Gavin King]

Good news :)

Sent from my iPhone

--

[Stephane Epardaud]

Can't we bring up a dialog to ask the user to import an android jar in the Ceylon repo if it's not there? That would make it even easier. Same for fixing the builder order.

--

[Diego Coronel]

with this new update everything worked like a charm, really easy to start working with ceylon and android, i want to implement an example of an API that i like  a lot: https://github.com/octo-online/RoboSpice-samples/blob/release/robospice-sample-spring-android/ but im stuck and i will post it at ceylon dev channel, for now i must say that you did an excellent work david.

2014/1/13 Stephane Epardaud <stephane...@gmail.com>

[Diego Coronel]

Ahh, now i remember that i had a bug, i have imported robospice and it have an exception: SpiceException and my module.ceylon has this error:

[Backend error] Error while loading the robospice_cache/1.4.9 module:

Error while resolving extended type of com.octo.android.robospice.persistence.exception::SpiceException:

Failed to find declaration for java.lang.Exception

so i didnt try to import java.base because i have so many compiler errors migrating the code that i believe im not going to know until run it.. so, does it should work if i import java.base?

2014/1/13 Diego Coronel <diego....@gmail.com>

[Tomáš Hradec]

Sound great, it would deserve blog article ;-)

2014/1/14 Diego Coronel <diego....@gmail.com>

[Festal David]

Le 13/01/2014 22:56, Stephane Epardaud a écrit :

Can't we bring up a dialog to ask the user to import an android jar in the Ceylon repo if it's not there? That would make it even easier. Same for fixing the builder order.

It seems to me that prompting with unexpected dialogs is usually not the best solution. Maybe we should simply add the various android jars to Herd, no ? Then the module name would be well-known, and it would be simpler to setup, in the compatibility plugin, some automatic way to check that the imported android ceylon module is coherent with the SDK target platform set on the project.

As for the build order, it should be possible to fix it silently.

--

Cordialement,

David Festal

[Festal David]

I'll try to write one

--

Cordialement,

David Festal

[Festal David]

Le 14/01/2014 09:42, Festal David a écrit :

Le 13/01/2014 22:56, Stephane Epardaud a écrit :

Can't we bring up a dialog to ask the user to import an android jar in the Ceylon repo if it's not there? That would make it even easier. Same for fixing the builder order.

It seems to me that prompting with unexpected dialogs is usually not the best solution. Maybe we should simply add the various android jars to Herd, no ? Then the module name would be well-known, and it would be simpler to setup, in the compatibility plugin, some automatic way to check that the imported android ceylon module is coherent with the SDK target platform set on the project.

As for the build order, it should be possible to fix it silently.

Indeed we could add a build path error for both cases, but provide a quick fix for each one. Maybe this would be the more eclipse-compliant way...

[Stephane Epardaud]

We can add them to Herd if we're allowed to redistribute them yes.

Stéphane Épardaud

[Festal David]

In fact it seems that Android SDK license doesn't allow redistributing it (cf : http://code.paulk.fr/article0008/what-s-up-with-the-android-sdk )
Finally I think the best way is to provide a specific CMR repository that directly exposes the archives available in the available Android SDK packages available locally (just as it is done for the JDK)

[Stephane Epardaud]

So if we can't redistribute it, we have another problem. This is another case of dependency like the JDK which Maven calls "provided" which means "if you have it then good, if you don't then you're screwed because we're not going to give it to you".

I suppose that given the popularity of Android we could make another such special case like we do for JDK modules, and support it in the CMR and Herd and if you don't have it then it will just break. But there's more than that, because I guess that if you do depend on Android you can't use the Java modules, and the opposite.

The other question is how this works on the CLI. I assume the IDE can use the one from the ADT distrib/classpath, but from the CLI it's not clear.

[Festal David]

Le 14/01/2014 14:31, Stephane Epardaud a écrit :

So if we can't redistribute it, we have another problem. This is another case of dependency like the JDK which Maven calls "provided" which means "if you have it then good, if you don't then you're screwed because we're not going to give it to you".

I suppose that given the popularity of Android we could make another such special case like we do for JDK modules, and support it in the CMR and Herd and if you don't have it then it will just break. But there's more than that, because I guess that if you do depend on Android you can't use the Java modules, and the opposite.

The other question is how this works on the CLI. I assume the IDE can use the one from the ADT distrib/classpath, but from the CLI it's not clear.

Can you add some additional CMR repository implementation to the Ceylon CLI (in the form of a plugin?) ? Then you might just add a CMR repository URI that points to the right SDK place, no ?

[Stephane Epardaud]

We can add a new CMR repo like for Java, but we also need custom rules that prevent someone using both Java modules and Android modules, I guess.

As for pointing to the right place, I suppose we could do this via configuration/command-line flags

[Festal David]

Le 14/01/2014 14:42, Stephane Epardaud a écrit :

We can add a new CMR repo like for Java, but we also need custom rules that prevent someone using both Java modules and Android modules, I guess.

Are you sure about that ? In a first approach can't we let the user do it if necessary : anyway if some unauthorized Java classes are used, they sould be filtered by the Android SDK tools, with an error, no ?

[Stephane Epardaud]

Perhaps, but I'm pretty sure that if someone tries to import both the JDK and Android, bad things will happen, as IIRC Android provides the JDK (or parts of it), and the parts it doesn't provide won't be there anyways.