Hi Jean, Thanks for the reply :-)
- How about adding the android plugin to the Maven build? that should make it easier for all to build it, run tests etc as running the Android tools manually in Eclipse is not a very reliable and repeatable process. I can help you set up the pom.xml files if you want and give me the Android commands to run. What do you mean by android plugin? The only android plugin I know is the one for eclipse...do you mean the ant script? Yes, we definitely need to get it automated. But I think there is a logic sequence to be followed: we need to get it running first and when we get it running we can automate it. Anyway, when I talk about that we need to run it on eclipse, I'm talking about a good environment to develop, maven is good for automation, but not for developing (modifing code, debugging, etc) : ( - To work around the XML parsing limitations... well maybe for now we don't need XML in the first place. When we process an SCA contribution, instead of looking for foo.composite for example, we could look for and execute a "FooComposite" Java class, which would create the Composite model for 'foo' using the Java model APIs from tuscany-assembly (like some test cases already do). In a way that Java class would just be another representation of the composite (as Java source), just more convenient to use in an Android environment for now. Who likes to write angle brackets anyway? :) I agree with you : )...but do not mix not using XML as user and not using XML in SCA code. The first one we are already doing, because we are trying to run the calculator2 and it doesn't use XML files. The second one would be to remove every reference to stax api and xml api code in tuscany code. There are a bunch of methods, constructors and etc that requires XML classes as arguments, so we would need to redesign it. I think it's easier and safier to find a workaround for the --core-library problem than modify the tuscany sca code. What do you think?! :) Best Regards, Adriano Crestani On Thu, Oct 9, 2008 at 12:03 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > Adriano Crestani wrote: > >> Hi all, >> >> I've been testing the latest android SDK version (1.0-rc1). >> >> Android improvements: >> >> - Annotations are finally working...they finally implemented the native >> method for the emulator, on the old version we had only the native methods >> >> - Now the android is including the resources (non class files), those >> defined in the android project and in its included projects, in its package >> and not ignoring as it used to do. It's really good, because we don't need >> to adapt the way Android SCA looks for resouces anymore. >> >> - The android plugin is finally including the android included projects >> dependencies. On old versions, any dependency included in any included >> project needed to be also included in the android project. >> >> Bad news: >> >> - android sdk still doesn't contain many JDK classes, mainly the ones that >> tuscany uses a lot, like xml api, just few classes from this api is in the >> actual android sdk : ( >> >> - android .class converter is by default failing when it tries to convert >> a .class file that are JDK classes...even if this is not included in the >> android SDK. I can force the converter using the --core-library argument, >> but unfortunatelly there is no option to set this option on android builder. >> The only way I could convert was using an ant build. But debugging on the >> emulator using command line is really painful. I have tried to generate the >> .apk file (the android executable file) and place it on the eclipse android >> project and I tried to run it from eclipse, but I get an error saying that >> the .apk is not found. I think when the .apk is generated by the android >> builder, it also register the .apk on the emulator, I'm not sure, but I will >> work on that. >> >> >> The last bad issue is a problem, because I need to add a lot of xml >> classes from jdk and it's not being possible. These classes are used by stax >> api and some other tuscany classes. >> >> Oscar and me have already complained about these bad issues on android ML, >> but unfortunately android developers are not good at answering questions as >> tuscany's : ) >> >> I think that's it : ) >> >> Comments, suggestions and critics are welcome :-) >> >> Adriano Crestani >> >> > Adriano, > > Two ideas: > > - How about adding the android plugin to the Maven build? that should make > it easier for all to build it, run tests etc as running the Android tools > manually in Eclipse is not a very reliable and repeatable process. I can > help you set up the pom.xml files if you want and give me the Android > commands to run. > > - To work around the XML parsing limitations... well maybe for now we don't > need XML in the first place. When we process an SCA contribution, instead of > looking for foo.composite for example, we could look for and execute a > "FooComposite" Java class, which would create the Composite model for 'foo' > using the Java model APIs from tuscany-assembly (like some test cases > already do). In a way that Java class would just be another representation > of the composite (as Java source), just more convenient to use in an Android > environment for now. Who likes to write angle brackets anyway? :) > > Let me know what you think. > -- > Jean-Sebastien >
