[xmlvm-dev] Re-integrated skeleton branch

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

Hi guys,

I just re-integrated a branch that I've been working on for quite a few
weeks now. The basic feature I wanted to introduce was merging the
compat-lib wrapper on the fly. While doing this, I came across a few things
that were not so nice and needed to be fixed and cleaned-up.

One major achievement from this work is that the --gen-wrapper flag is gone.
It was used in the past to tell the stylesheet to produce a skeleton from
all classes. However, for this purpose we always had the XMLVMSkleleton
annotation for classes that should be turned into skeletons. So I made sure
that all classes that should have this annotation, have it.

In addition, the gen-c-wrappers ant target had some implicit logic in there
that ignored inner classes and classes in sub-packes of org.xmlvm.iphone.
This is very implicit and error-prone. I made sure that these classes now
have an XMLVMIgnore annotation. This also meant turning some anonymous
classes into proper inner classes, so that the annotation could be applied.

And this in one thing I ask the ones of you who work with this to be careful
about (I know Panayotis e.g. made some changes in these classes recently):
>From now on, do not use anonymous classes, if these classes should not be a
part of the cross-compiled compat-lib. In this case, make it an inner class
and attach the XMLVMIgnore annotation to it. The implicit logic always
through all all innter and anonymous classes for you. You now have to take
care of it yourself by marking it as such.
This clean-up removes quite a bit of messy code and logic we had, and it
should all be a bit clearer now.

As I said, the main motivation of this change was the on-the-fly merging of
the hand-written wrapper code. This is needed by the constant pool and is
nice in general. It saves you in some cases from regenerating these classes
all the time when changes have been made in the stylesheet or in the classes
themselves. The original skeleton class will be run through the pipeline
anyway and in the end, the hand-written code for the methods will now be
merged into them.

I hope all of this makes sense. If you discover issues with this change, let
me know on this thread.

// Sascha