Re: jgir enhancement

[Farkas Levente <lfarkas lfarkas org>]

On 07/11/2014 08:18 PM, Colin Walters wrote:
> However, I had (and still have) a fundamental disagreement with the
> java-gnome people in that they want to manually expose and redocument
> APIs to tweak them to be more Java-like, whereas with JGIR I was
> attempting automated bindings which are better for people who know the
> platform.

we also like to follow this second approach and even go further to
generate bindings for glib itself.

> > - first of all jgir use "GLib/GObject interface layer adapted from
> > gstreamer-java". our question is why? it seems repository and glib2
> > itself already has gobject-introspection ie:
> > so why we can't use it fir itself also?
>
> Because GObject and below are special and need custom bindings.

can you explain it a bit more detail? why? if we have introspection for
glib and girepository itself?

> > - as we can see jgir only can create jar file ie only class and not java
> > source files. wouldn't it be more clear way to create java file from the
> > xml (not the typelib) in this case we can generate docs and java code
> > too and simple compile the java codes? 
>
> From a packaging perspective then you need to rebuild all of the
> bindings using a full JDK whenever one of the C libraries changes.  My
> original thought was that we could just have a post-install trigger that
> regenerated the .class files from the .typelib, whenever they changed.

i think i'd be happy if we even be able to generate a wrapper for a
given version totally automatically:-)

> Maybe that was never realistic though.  The compilation route then you'd
> probably end up with some sort of "java-gobject-introspection-classes"
> package that would need to rebuilt every time any package containing a
> .gir changed, and would contain class files for all packages.  (Or
> alternatively, create a -java-gir package per bound package, e.g.
> libgstreamer1-java-gir).

imho there are only a few dependencies. so if there will be a
glib-java-gir and a gstreamer1-java-gir then i only need to rebuild one
of them i something changed in the underlying public api ie some new
function added or a function's argument list changed etc. which means if
i don't update system glib or at least the public api (.gir files) not
changed (which is the case in enterprise of for a few years) then i
don't need to regenerate glib-java-gir.

-- 
  Levente                               "Si vis pacem para bellum!"