xmlvm-users

[xmlvm-users] XMLVM android-compat.jar vs. android.target.classpath

[Panayotis K. <pan...@pa...>]

Hello all!

I am in the process of automating the integration of XMLVM into an Android project.
But I found a problem and I would like to discuss with you the possible solutions.

The problem is with the android libraries, which come from two sources: one from the XMLVM project (which will emulate Android on an iPhone) and second, the actual bootstrap libraries of a genuine Android device.  
Although they are more or less the same, they are not "exactly" the same.

The source code of a project could be compiled perfectly with both libraries. The produced class files though will (probably) be a bit different. This can be demonstrated even in the case of the "aFireworks" project.
So, in order to work perfectly with both environments, I can see these scenarios and I'd like you to say your opinion, on what to implement:

a) Use only android bootstrap libraries. That means that the xmlvm android library should be API-perfect, or else compilation on the ObjC part will fail.

b) Compile with XMLVM libraries and use these classes for both ObjC project *and* Android emulation. As long as the XMLVM library is more or less compatible with the official android bootstrap, this will work. But, in the case that something is binary incompatible, the application on the Android device will crash for no obvious reason.

c) Compile the ObjC code with the xmlvm libraries, and the Android emulator project with the Android bootstrap files. So every time the project is rebuilt, the produced classes should be cleaned and re-generated.


I am more in favor of the third approach, although it is not the most optimized, but because it is the safest. There will be a penalty for compilation, but I think it is not so important, compared with the benefits.


Before implementing anything though, I'd love to hear your thoughts...

Re: [xmlvm-users] XMLVM android-compat.jar vs. android.target.classpath

[Wolfgang K. <wol...@xm...>]

I go for the third option - because it is the safest one.

-- Wolfgang

Am 19.09.2010 17:56 schrieb "Panayotis Katsaloulis" <pan...@pa...
>:
> Hello all!
>
> I am in the process of automating the integration of XMLVM into an Android
project.
> But I found a problem and I would like to discuss with you the possible
solutions.
>
> The problem is with the android libraries, which come from two sources:
one from the XMLVM project (which will emulate Android on an iPhone) and
second, the actual bootstrap libraries of a genuine Android device.
> Although they are more or less the same, they are not "exactly" the same.
>
> The source code of a project could be compiled perfectly with both
libraries. The produced class files though will (probably) be a bit
different. This can be demonstrated even in the case of the "aFireworks"
project.
> So, in order to work perfectly with both environments, I can see these
scenarios and I'd like you to say your opinion, on what to implement:
>
> a) Use only android bootstrap libraries. That means that the xmlvm android
library should be API-perfect, or else compilation on the ObjC part will
fail.
>
> b) Compile with XMLVM libraries and use these classes for both ObjC
project *and* Android emulation. As long as the XMLVM library is more or
less compatible with the official android bootstrap, this will work. But, in
the case that something is binary incompatible, the application on the
Android device will crash for no obvious reason.
>
> c) Compile the ObjC code with the xmlvm libraries, and the Android
emulator project with the Android bootstrap files. So every time the project
is rebuilt, the produced classes should be cleaned and re-generated.
>
>
> I am more in favor of the third approach, although it is not the most
optimized, but because it is the safest. There will be a penalty for
compilation, but I think it is not so important, compared with the benefits.
>
>
> Before implementing anything though, I'd love to hear your thoughts...
>
------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] XMLVM android-compat.jar vs. android.target.classpath

[Arno P. <ar...@pu...>]

+1 from my side as well.

Arno


On 9/19/10 9:01 AM, Wolfgang Korn wrote:
> I go for the third option - because it is the safest one.
>
> -- Wolfgang
>
> Am 19.09.2010 17:56 schrieb "Panayotis Katsaloulis"
> <pan...@pa... <mailto:pan...@pa...>>:
>  > Hello all!
>  >
>  > I am in the process of automating the integration of XMLVM into an
> Android project.
>  > But I found a problem and I would like to discuss with you the
> possible solutions.
>  >
>  > The problem is with the android libraries, which come from two
> sources: one from the XMLVM project (which will emulate Android on an
> iPhone) and second, the actual bootstrap libraries of a genuine Android
> device.
>  > Although they are more or less the same, they are not "exactly" the same.
>  >
>  > The source code of a project could be compiled perfectly with both
> libraries. The produced class files though will (probably) be a bit
> different. This can be demonstrated even in the case of the "aFireworks"
> project.
>  > So, in order to work perfectly with both environments, I can see
> these scenarios and I'd like you to say your opinion, on what to implement:
>  >
>  > a) Use only android bootstrap libraries. That means that the xmlvm
> android library should be API-perfect, or else compilation on the ObjC
> part will fail.
>  >
>  > b) Compile with XMLVM libraries and use these classes for both ObjC
> project *and* Android emulation. As long as the XMLVM library is more or
> less compatible with the official android bootstrap, this will work.
> But, in the case that something is binary incompatible, the application
> on the Android device will crash for no obvious reason.
>  >
>  > c) Compile the ObjC code with the xmlvm libraries, and the Android
> emulator project with the Android bootstrap files. So every time the
> project is rebuilt, the produced classes should be cleaned and re-generated.
>  >
>  >
>  > I am more in favor of the third approach, although it is not the most
> optimized, but because it is the safest. There will be a penalty for
> compilation, but I think it is not so important, compared with the benefits.
>  >
>  >
>  > Before implementing anything though, I'd love to hear your thoughts...
>  >
> ------------------------------------------------------------------------------
>  > Start uncovering the many advantages of virtual appliances
>  > and start using them to simplify application deployment and
>  > accelerate your shift to cloud computing.
>  > http://p.sf.net/sfu/novell-sfdev2dev
>  > _______________________________________________
>  > xmlvm-users mailing list
>  > xml...@li...
> <mailto:xml...@li...>
>  > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

[xmlvm-users] Problem with demo Android projects

[Panayotis K. <pan...@pa...>]

MOTIVATION
Since I am creating a patch which makes demo iPhone projects self-contained (and easy to be copied and manipulated), I was thinking to do the same with Android projects. Thus everybody could have a real "demo" case, and not only a "proof of concept", with difficult assumptions on how to migrate an existing project to Android. 


STATUS OF THE ART
The currently demo projects of XMLVM are not "full" android projects, i.e. not being created by the "android create project" command.
They can only be used from inside Eclipse and not with Google tools which handle Android projects.
For this reason you have written special ant tasks in the base build.xml file, to overcome this problem.


THE PROBLEM
... is that an Android project should specifically define an Android SDK location for the Google-provided build scripts to work.
But this can change from system to system, and specifically be defined in a local.properties file, which should not be committed to the SVN

MY PROPOSAL
... is, like in the case of OpenJDK, to include the absolute minimum requirements from the Android project to the XMLVM project. Thus the demo Android projects will be "full", self-contained and "ready to be copied" Android projects.
And it will be dead-easy to run these tests in the Android Emulator itself.

What do you think?

Re: [xmlvm-users] Problem with demo Android projects

[Arno P. <ar...@pu...>]

you will have to explain that a little more in detail. The demos that 
are shipped with XMLVM are proper Android projects. They were created 
with the Android plugin for Eclipse (which is officially released by 
Google). In Eclipse, you can import xmlvm/demo/android/xokoban and you 
will see a proper Android project in your workspace. The location of the 
Android SDK is configured with the Eclipse plugin.

XMLVM needs to compile .class files (not .dex files) to do its thing. 
So, the build.xml for that can be independent of the Android SDK.

What exactly is the problem?

Arno


On 9/22/10 12:51 AM, Panayotis Katsaloulis wrote:
> MOTIVATION
> Since I am creating a patch which makes demo iPhone projects self-contained (and easy to be copied and manipulated), I was thinking to do the same with Android projects. Thus everybody could have a real "demo" case, and not only a "proof of concept", with difficult assumptions on how to migrate an existing project to Android.
>
>
> STATUS OF THE ART
> The currently demo projects of XMLVM are not "full" android projects, i.e. not being created by the "android create project" command.
> They can only be used from inside Eclipse and not with Google tools which handle Android projects.
> For this reason you have written special ant tasks in the base build.xml file, to overcome this problem.
>
>
> THE PROBLEM
> ... is that an Android project should specifically define an Android SDK location for the Google-provided build scripts to work.
> But this can change from system to system, and specifically be defined in a local.properties file, which should not be committed to the SVN
>
> MY PROPOSAL
> ... is, like in the case of OpenJDK, to include the absolute minimum requirements from the Android project to the XMLVM project. Thus the demo Android projects will be "full", self-contained and "ready to be copied" Android projects.
> And it will be dead-easy to run these tests in the Android Emulator itself.
>
> What do you think?
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Problem with demo Android projects

[Panayotis K. <pan...@pa...>]

On 23 Σεπ 2010, at 4:22 π.μ., Arno Puder wrote:

> 
> you will have to explain that a little more in detail. The demos that 
> are shipped with XMLVM are proper Android projects. They were created 
> with the Android plugin for Eclipse (which is officially released by 
> Google). In Eclipse, you can import xmlvm/demo/android/xokoban and you 
> will see a proper Android project in your workspace. The location of the 
> Android SDK is configured with the Eclipse plugin.
> 
> XMLVM needs to compile .class files (not .dex files) to do its thing. 
> So, the build.xml for that can be independent of the Android SDK.
> 
> What exactly is the problem?
> 
> Arno


Exactly that is the problem, it is only usable under Eclipse and not on the command line.
The problem with the command line is that the Android SDK should be defined somewhere.

If we want to use the exact build options as with Android projects (as discussed in a previous email with android libraries), the Android SDK should be present.

I have thought of this problem and I think I found an alternative approach. The first time the user requests the Android based demos to be compiled - and the location of the Android SDK was not provided to the XMLVM system - an error will appear and the compilation will abort. When the user will define the location, the compilation could go on as usual.

Again, this has to do with the demo XMLVM Android projects. This will not alter in any case the regular xmlvm usage from the command line.

Re: [xmlvm-users] Problem with demo Android projects

[Sascha H. <sa...@xm...>]

Well, one of the things we will need to do for the cross-compilation of
Android projects is to add the Android SDK. We can do this two ways: Either
we put it  into a JAR, just like the OpenJDK JAR or we assume the developer
has Android installed and use an environment flag to point to the classes.

The advantage of the latter is that we don't blow up the size of our
repository and one-jar further and I guess we can assume that every dev has
Android installed.

// Sascha

On Thu, Sep 23, 2010 at 10:17 AM, Panayotis Katsaloulis <
pan...@pa...> wrote:

> On 23 Σεπ 2010, at 4:22 π.μ., Arno Puder wrote:
>
> >
> > you will have to explain that a little more in detail. The demos that
> > are shipped with XMLVM are proper Android projects. They were created
> > with the Android plugin for Eclipse (which is officially released by
> > Google). In Eclipse, you can import xmlvm/demo/android/xokoban and you
> > will see a proper Android project in your workspace. The location of the
> > Android SDK is configured with the Eclipse plugin.
> >
> > XMLVM needs to compile .class files (not .dex files) to do its thing.
> > So, the build.xml for that can be independent of the Android SDK.
> >
> > What exactly is the problem?
> >
> > Arno
>
>
> Exactly that is the problem, it is only usable under Eclipse and not on the
> command line.
> The problem with the command line is that the Android SDK should be defined
> somewhere.
>
> If we want to use the exact build options as with Android projects (as
> discussed in a previous email with android libraries), the Android SDK
> should be present.
>
> I have thought of this problem and I think I found an alternative approach.
> The first time the user requests the Android based demos to be compiled -
> and the location of the Android SDK was not provided to the XMLVM system -
> an error will appear and the compilation will abort. When the user will
> define the location, the compilation could go on as usual.
>
> Again, this has to do with the demo XMLVM Android projects. This will not
> alter in any case the regular xmlvm usage from the command line.
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Problem with demo Android projects

[Panayotis K. <pan...@pa...>]

On 23 Σεπ 2010, at 11:41 π.μ., Sascha Haeberling wrote:

> Well, one of the things we will need to do for the cross-compilation of Android projects is to add the Android SDK. We can do this two ways: Either we put it  into a JAR, just like the OpenJDK JAR or we assume the developer has Android installed and use an environment flag to point to the classes.
> 
> The advantage of the latter is that we don't blow up the size of our repository and one-jar further and I guess we can assume that every dev has Android installed.


These are my exact thoughts.
In the beginning I was towards the first solution, but now I am more in favor of the second, even if compilation of Android demos with XMLVM will not be "out of the box", and some manual tuning of XMLVM config files should be required (and will be documented).

If you agree, I can go on with the second approach :)

Re: [xmlvm-users] Problem with demo Android projects

[Sascha H. <sa...@xm...>]

Sure, try the second approach and see how it works. Switching it around in
case it's not optimal should be easy.

// Sascha

2010/9/23 Panayotis Katsaloulis <pan...@pa...>

> On 23 Σεπ 2010, at 11:41 π.μ., Sascha Haeberling wrote:
>
> > Well, one of the things we will need to do for the cross-compilation of
> Android projects is to add the Android SDK. We can do this two ways: Either
> we put it  into a JAR, just like the OpenJDK JAR or we assume the developer
> has Android installed and use an environment flag to point to the classes.
> >
> > The advantage of the latter is that we don't blow up the size of our
> repository and one-jar further and I guess we can assume that every dev has
> Android installed.
>
>
> These are my exact thoughts.
> In the beginning I was towards the first solution, but now I am more in
> favor of the second, even if compilation of Android demos with XMLVM will
> not be "out of the box", and some manual tuning of XMLVM config files should
> be required (and will be documented).
>
> If you agree, I can go on with the second approach :)
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>